Security Advisories

For each session, CiviCRM stores a private session key. This patch addresses multiple issues which could compromise the strength or security of the key.

The jQuery project released version 3.5.0, and as part of that, disclosed two security vulnerabilities that affect all prior versions. As mentioned in the jQuery blog, both are

"[...] security issues in jQuery’s DOM manipulation methods, as in .html(), .append(), and the others. Security advisories for both of these issues have been published on GitHub."

Those advisories are:

In certain screens, the Activity "Subject" field was not properly escaped to prevent cross site scripting.

In certain screens, the Profile "Description" field was not properly escaped to prevent cross site scripting.

In certain screens, the Event "Summary" field was not properly escaped to prevent cross site scripting.

CiviCRM did not provide sufficient protection on the CKEditor configuration form, which could allow user to store and execute Javascript.

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.

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.