Security Advisories

Using a carefully crafted request, a backend user could determine the API credentials of another user.

When processing a CiviCRM API request, the entity name was not properly validated. This could potentially lead to loading an arbitrary file on the server.

The AJAX end-point for APIv4 was vulnerable to a cross-site request forgery. If an administrative user visited a malicious page outside of CiviCRM, the malicious page could trick that user's browser into performing privileged actions on the CiviCRM site.

Several CiviCRM fields are stored with an unconventional "HTML-esque" encoding. Consumers which read or write these fields via APIv4 have been prone to mishandling those strings (which can lead to cross-site scripting vulnerabilities and/or quirky outputs). In APIv3, the issue was previously mitigated by automatically transcoding strings. This revision extends the same mitigation to APIv4.

Most APIv4 consumers should automatically become more secure with this update.

When loading dashboard dashlets, the system did not properly ensure that the title of the dashlets was properly escaped.

Both the "SavedSearch" and "ReportInstance" APIs accept certain inputs using "serialized" PHP notation. Accepting untrusted values in this notation leads to a "PHP Object Injection" (POI) vulnerability - which can potentially escalate to an "Arbitary Code Execution" vulnerability.

The APIs now accept a restricted subset of "serialized" notation - the APIs will only accept basic data (arrays, strings, numbers, etc). This prohibits PHP object construction and retains backward compatibility with typical API inputs.

The field "api_key" has special security rules when accessed via the API. These rules could potentially be bypassed and lead to privilege escalation.

The "dedupefind" endpoint facilitates de-duplication of contacts. The endpoint had a SQL injection vulnerability.

This SA only affects users of the CiviCase v5 extension. In versions prior to 1.1, the extension did not properly escape the "Subject" field when using the in-place editor.

When determining the installer type that is being used, the variable was not properly validated to ensure that it was ony one of a specific set of installer types.

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.