Security Advisories

When preparing the query for finding events for the Manage Events page, the event type parameter was not properly escaped.

When generating a query for finding particular checkbox values, the query was not properly being escaped before being passed onto the database.

In CiviCRM systems which accept file attachments, a malicious user could perform a cross-site scripting attack. This attack involved accessing the "civicrm/file" path with a forged value in the parameter "&mime-type=...".

The solution involved a few subtle changes in the public-facing contract for "civicrm/file". If you have a customization which relies on this route, you may want to consider the details:

In CiviCRM APIv3, a generic action ("getOptions") inappropriately propagated an advanced option ("condition") to a lower level function, which effectively allowed a caller to include arbitary SQL conditions. The "getOptions" API will now ignore the "condition" option.

PHP libraries and applications sometimes have vulnerabilities in which an attacker may inappropriately request construction of an object. The patch in this release does not deal with a specific vulnerability. Rather, it is defense in depth -- it removes an escalation vector by which hypothetical vulnerabilities (in CiviCRM or a related PHP library/application) could become more severe.

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.

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.