CiviCRM uses the Smarty template system for high-trust content (built-in template files, written by developers) and low-trust content (user-supplied templates, written by back-office users). Low-trust content is subject to sandboxing, but there were issues in how this was applied.
Security Advisories
This page lists all security advisories since June 2013. For older security advisories see this post. Security release announcements (starting with v4.2) are also listed here.
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.
Web-pages which use the "Resources" API to inject JSON data ("settings") may create vectors for XSS attacks.
Within the "View Contact" screen and its sub-pages, there were multiple cross-site scripting vulnerabilities.
CiviCRM includes the Smarty v2 templating engine. Templates are defined by core code, by third-party extensions, and by configurable content. The upstream smarty.net
project has stopped publishing security backports for Smarty v2, so civicrm.org
will do so (until a migration to a newer Smarty is complete).
As part of this, the CiviCRM security team has done a detailed audit to compare recent issues from v2/v3/v4.
CiviEvent included multiple screens with a vulnerability to cross-site scripting (XSS).
Some administrative actions for "Contact" profile-images lacked sufficient validation, making them vulnerable to a cross-site request forgery (CSRF).
In CiviCampaign, the "Survey" functionality includes a field that may be vulnerable to cross-site scripting (XSS).
The package "jquery-validation" may be vulnerable to a Denial of Service (DoS) involving its handling of regular expressions.
We have not identified an attack scenario affecting CiviCRM, but the update appears to be a safe and sensible precaution.
Select2 is an auto-complete widget. In multiple places where CiviCRM uses Select2, it was vulnerable to stored cross-site scripting (XSS) attack.
(We believe that exploiting this requires that both the attacker and the victim have a high-level of access to the same CiviCRM deployment.)
A problematic code pattern was found in ~8 places. Any of these places could be vulnerable a SQL injection (SQLI) attack. However, it is believed that most or all have mitigating factors that prevent exploits.
Users with access APIv3 or APIv4 via any medium (including web-browser) may be able to execute an SQL injection (SQL) attack.
KCFinder provides a file-management dialog for CKEditor 4. It included two vulnerabilities:
- It allowed a "reflected" cross-site scripting (XSS) attack.
- It bypassed a CiviCRM policy option which limits file-uploads. (This bypass was still subject to other restrictions. The likely impact is to allow a "stored" XSS attack. However, it is possible for there to be other impacts.)
Template authors can perform remote code execution (RCE) with a specially crafted call to the {math}
function.
(This issue was identified as part of a general audit of Smarty v2, CIVI-PSA-2023-01.)
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.