Security Advisories

Some permissions were not being checked adequately before returning results from the CiviCRM APIv4. This did not affect everyday use of CiviCRM, but an attacker could potentially exploit this to bypass security checks and read private data from the database. To date there are no known sites that have been compromised due to this bug. APIv3 was not affected.

(This is a public service announcement related to security functionality. It does not detail an exploitable vulnerability. Rather, we wish to advise administrators and developers about an on-going change to improve security.)

CiviCRM v3.1 introduced a helper "CRM_Utils_Crypt" which encrypted the SMTP password. This mechanism is being phased-out circa 5.34 in favor of a more secure mechanism. We will briefly consider the purpose of the mechanism, some of its issues, and the details of the change.

In the Joomla integration, some references to user-account records were not properly sanitized.

CiviCRM's REST API traditionally requires two keys, the "API Key" and the "Site Key". The "Site Key" could potentially be extracted by a "timing attack". In this scenario, an attacker would send many invalid requests, build a statistical profile, and infer the most likely value.

The introduction text on a Personal Campaign Page (PCP) was not properly sanitised prior to display on the Personal Campaign page.

When generating the example code in the APIv4 Explorer, the user entered data was not properly sanitised before displaying as example code within the Explorer.

The "Manage Extensions" screen provides a list of extensions published by third-party developers. If an extension had a malicious description, it could trick the user's browser into executing Javascript code.

Note: To exploit this, an attacker would need to gain control of a trusted developer account, and they would leave evidence in a public feed. At time of writing, there is no known evidence of previous attack. Resolving this issue prevents future attacks.

The development tree for CiviCRM includes a handful of utility scripts in the folders "sql/" and "tools/". These scripts may manipulate data (e.g. generating fake contact records), and they lacked guards to protect from remote/malicious use.

This issue does not affect most deployments which use the standard CiviCRM releases ("*.tar.gz" or "*.zip"). The issue primarily affects developmental/testing systems or highly-customized deployments which directly read from CiviCRM's source code-management system ("git").

When importing data from CSV, the user's browser could be tricked into executing Javascript.

This vulnerability does not escalate the permissions of the user. However, if the user imports data from another application/system, then it could be used for an attack.

In some situations, users without the permission "edit contributions" could edit recurring contributions.

In certain output media, error messages were not properly escaped.

This issue did not lead directly to cross-scripting, but it could lead to other HTML injections.

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