When conducting a "Contact" search, the groups and tags parameters were vulerable to SQL injection.
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.
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".
In previous versions of CiviCRM, this access-control mechanism was overly permissive (and only secure in an unrealistically narrow range of use-cases). In newer versions, the permission "access uploaded files" remains a pre-requisite. Additionally, when downloading a file, the URL must include a signed access token. The token is generated by the server, and it provides access to a specific file for a limited time period.
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.
Drupal Views allows an administrator to produce a screen with data from CiviCRM's custom-fields. Certain custom-fields could potentially be manipulated to inject SQL.
When viewing the CiviCRM "Mailing" report, a logged-in user could modify the URL to access the report for another mailing -- even if
they ordinarily would not have access that information.
Unfortunately, we could not obtain sufficient information about these issues to determine whether they cause actual vulnerabilities in CiviCRM.
The pingback system is an optional mechanism which reports statistical data to civicrm.org. The pingback URL specified an unencrypted protocol (HTTP), and well-positioned eavesdropper could potentially intercept statistical data. The pingback URL should specify an encrypted protocol (HTTPS) to prevent eavesdropping.
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.