Security Advisories

The "dompdf" library has a vulnerability which allows remote code execution. It may be exploited by some backend users.

The CiviCRM-WordPress module includes a "Quick Add" widget that can be used to trick another user into executing arbitrary HTML and Javascript.

(This vulnerability is similar to "stored cross-site scripting". However, exploiting it requires the backend privilege access CiviCRM, so it can only be exploited by internal users.)

CiviCRM's file-upload mechanism includes a guard to limit the range of accepted file-types. However, the guard is too relaxed - in some configurations, this enables a less-privileged data-administrator to execute arbitrary code.

Asset Builder allows CiviCRM and its extensions to generate dynamic assets. A vulnerability allowed third-parties to trick it into generating assets with unintended inputs.

Exploiting this vulnerability depends on several details (e.g. the asset data-types, input-parameters, and web-domain policies). For the specific assets and configurations that we tested, attacks were substantively constrained by the browsers' "Same Origin Policy". However, other assets and other configurations could be impacted more severely.

CiviEvent included a vector for reflected cross-site-scripting (XSS) attacks.

The "Help" subsystem did not sufficiently validate the location/origin of its source files. If combined with a web-based upload tool, this could allow a user to execute arbitrary code.

With CiviCRM's standard upload tools, exploiting this vulnerability requires permission "administer CiviCRM". However, other upload tools (such as CMS plugins) could provide other attack vectors.

A vulnerability in processing APIv3 AJAX requests could allow a malicious request to bypass permission checks.

The "dompdf" library has a vulnerability which allows remote code execution. It may be exploited by some backend users.

CKEditor had a vulnerability that could allow execution of Javascript code.

The exact degree of exploitability for CiviCRM has not been determined.

jQuery UI v1.12 included multiple cross-site scripting vulnerabilities.

It has not been demonstrated that CiviCRM specifically is exploitable. However, it is possible that third-party extensions could use jQuery UI in a vulnerable fashion.

This is not a security vulnerability. It is a mitigation to protect against misconfiguration.

CiviCRM includes a large number of configurable permissions. Administrators may assign these permissions to various users and roles. This is powerful functionality that accommodates diverse needs, but it provides the opportunity for misconfiguration.

Misconfigurations may arise for a few reasons, such as:

When importing "Participant" records for CiviEvent, some inputs were not suitably escaped.

When accessing the Contribution View page insufficient permission checking was occurring which meant that if you knew the url and had the access CiviCRM permission you would be able to view contribution information that you shouldn't have.

CiviCRM includes a rich text editing component, CKEditor, which recently released a security update (v4.16.2). This update addresses 3 security issues.

We expect that these vulnerabilities cannot be meaningfully exploited by automated bots or crawlers - but they may be exploitable with modest social-engineering. Thus, we advise upgrading (or using one of the alternative solutions below).

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.