To receive future CiviCRM security notices, subscribe to our notifications. Check here for details of our security policy and how to report a suspected security issue.
This vulnerability allowed attackers to access the content of arbitrary files (in a common configuration).
NOTE: The patch-set for this issue overlapped with the patch-set for CIVI-SA-2019-01, but the cause, exploit, and risks are distinct.
When Contact entity fields are added to forms, the display name label wasn't properly sanitised.
The "Currency" element of a new pledge was not properly validated, which could potentially lead to a cross-site scripting attack.
When conducting a "Contact" search, the groups and tags parameters were vulerable to SQL injection.
In the "Logging Details" report, some parameters were not being properly sanitised.
When populating the "PrevNext" cache, some values were not properly escaped - which enabled a SQL-injection (SQLI) vulnerability.
Most CiviCRM deployments manage access to file-attachments using a coarse-grained permission "
access uploaded files".
Most CiviCRM pages are generated with the HTML_QuickForm library. HTML_QuickForm has a vulnerability which enables a remote attacker to execute arbitrary PHP code. This is fixed in the latest version of CiviCRM.
The "context" parameter for a number of screens was not properly validated. In some screens, this was found to enable cross-site scripting attacks. To correct the known vulnerability and to guard against potential others, the validation rules have been tightened across a wide range of screens.
In the contact dedupe screen, data retrieved about the contacts was not properly sanitised.
In some scenarios where an error message incorporates user-supplied text, a malicious input could become part of the response and lead to cross-site scripting.
When generating a list of the custom groups that utilize a particular sub-type, the sub-type was not properly escaped.
When generating a report, users are able to pass filters in the URL. Some filters in contribution reports were not properly escaped. Additionally, on systems that enabled developer output for reports, the developer outputs were not properly escaped.
Extended Reports Extension:
When retrieving cases via AJAX, some parameters were not properly validated. This allowed for SQL injection.
Previously there was no validation of the passed in grp url parameter which was passed in to the grouping part of an SQL which allowed for SQL injection possibility. The SQL to list the reports has now been re-written to properly validate all variables that are used in the SQL.
There wasn't any validation on the key url parameter which allowed for some cross site scripting to potentially occur. The fix is to add in validation to ensure the key is of normal standard extension key pattern.
CiviCRM used to output the Search criteria in the description field without any escaping. Given that certain parts of the criteria in a search form can be passed through as URL parameters, there was the possibility of XSS scripting coming in and not being properly escaped when displayed.
When viewing the list of message templates, one could pass through a variable called selectedChild through the URL which would specify which of the two lists it would default to showing. This variable was not properly validated against the known two types (user and workflow). There is now proper validation on the url parameter
Administrators were able to store and have displayed through the description field on a tag cross site scripting code. This would show up when the system tried to display the description as an alt html tag. It has now been changed to properly escape the alt tag
The form processing for the dedupe rules listing page did not properly validate the contact type variable that is passed through in the URL parameters. This potentially allowed for XSS to occur. This has been fixed to allow for only known contact types to be passed in.
When creating premium product in CiviCRM, the output of the product name was not properly being escaped as the alternate text when an image was being used for the product. This had the potential on contribution pages to expose credit card information.
As part of CiviCRM's defense in depth program, we have upgraded Smarty following an announcement by them that one of the functions in the Smarty templating engine potentially allowed for shell injection.
Despite this vulnerability in the Smarty library, CiviCRM's usage of Smarty appears to prevent such shell injection vulnerabilities.
In a number of locations within the CiviCRM code base there were potentially un-escaped variables passed into html link attributes such as alt and title. One such example was in event registration pages where administrators were able to set the button text and also the title attribute to anything they chose. This fixes it by properly escaping the content of those attributes.
After successfully calling the "Contact.create" API, the caller could receive a list of all fields relating to the contact -- including a sensitive field that normally has restricted access. In some contexts, leaking the sensitive field could allow an attacker to access CiviCRM as the targeted user.