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.
CiviCRM generates *.pdf files with the assistance of a PDF engine. It is compatible with multiple engines, including the default DOMPDF and the alternative wkhtmltopdf. The latter option is now unsupported and insecure. Sites should remove it.
(Note: wkhtmltopdf is not distributed by CiviCRM. This is a public service announcement to alert people who may have installed wkhtmltopdf as an add-on.)
The helper function CRM_Utils_File::cleanDir() is used to cleanup certain data folders. In some situations, it might be tricked into deleting additional files outside of the target directory.
Multiple AJAX end-points may be vulnerable to Cross Site Request Forgery.
This release updates a large number of older end-points originating circa CiviCRM 1.x-3.x. Detailed severity ratings were not assessed for all these end-points, but several samples were assessed. The severity ranged from "Not Critical" to "Moderately Critical". Thus, the overall issue is classified as "Moderately Critical".
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.
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.
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.
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.)
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.
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.