Security Advisories

CiviCRM did not provide sufficient protection on the CKEditor configuration form, which could allow a malicious third-party to trick a CiviCRM administrator into changing the configuration.

Note: This form had another vulnerability in the same version. The risk from two overlapping vulnerabilities may be greater than the risk of each individually.

When viewing an activity, the activity details were not sufficiently filtered to prevent cross-site scripting attacks.

In CiviCRM, an Access Control List (ACL) confers limited access to contact records (based on the membership list for a "Group" of contacts). In configurations with "ACL Smart Groups", a flaw allowed limited backend users to re-define their group criteria and gain elevated access. The fix ensures that only trusted users (with permission "edit groups") may re-define the group criteria.

Two Javascript libraries (QUnit and Google Code Prettify) are used with CiviCRM. These libraries include some assets which can be used in a cross-site scripting attack and which are not required for CiviCRM at runtime.

The "Schedule Jobs" page 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 executing a job on the CiviCRM site.

When constructing contact search queries, values for certain fields were not properly escaped -- allowing for SQL injection.

When constructing the SQL queries for deleting activities or getting summary information about CiviCampaigns, there was inadequate escaping of SQL variables that were passed in from request parameters.

CiviCRM did not properly purify the content of the note fields attached to CiviCase activities when generating Case Reports or viewing the Case Activity

Backend users may be able to upload and execute a maliciously crafted "PHAR" file.

The "PharExtensionInterceptor" library from Typo3 addresses this problem. Many projects - including the current Drupal and Joomla releases - already activate this protection and are already secure. However, some environments - such as WordPress - do not have it. This update extends the protection to all CiviCRM-supported environments.

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.