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.
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.
When processing country, state, province, or county references, some values were not properly validated - which enabled a SQL-injection (SQLI) vulnerability.
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.
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.
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: