Security Advisories

In jQuery 1.x, a malicious AJAX response can pollute the content of the "Object.prototype". jQuery 1.x no longer receives security updates, but CiviCRM now includes a patched version of jQuery 1.x (1.12.4-civicrm-1) derived from https://github.com/DanielRuf/snyk-js-jquery-174006/.

TCPDF converts HTML content to PDF. The library had vulnerabilities, including cross-site scripting and remote code execution. The library has now been upgraded to a fixed version.

CiviCRM includes the PHPWord library. PHPWord v0.14 is vulnerable to an XML external entity attack - which is resolved in v0.15.

To be affected APIv4 must be installed not just exist on the filesytem.

The latest release of APIv4 addresses 2 vulnerabilities:

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.

CiviCRM includes a copy of jQuery 1.x. If a site uses jQuery 1.x or 2.x to asynchronously load third-party assets, then the third-party (or a man-in-the-middle) may trick jQuery into executing arbitrary JavaScript code (CVE-2015-9251). CiviCRM deployments should generally be safe due to low reliance on third-party assets; however, as a preventive, CiviCRM now includes the mitigation from jQuery#2432.

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".

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.

When generating a list of the custom groups that utilize a particular sub-type, the sub-type was not properly escaped.

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 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.