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 includes a number of Javascript libraries. An automated assessment indicated that some these libraries had security issues. CiviCRM v4.7.21+ upgrades or removes multiple libraries.
Unfortunately, we could not obtain sufficient information about these issues to determine whether they cause actual vulnerabilities in CiviCRM.
CiviCRM allows administrators to define custom profile-forms in which constituents enter their names, addresses, custom data, etc. CiviCRM is designed to embed all its forms within a CMS (such as Drupal, Joomla, or WordPress), but some administrators also need to embed profile-forms in an external site or custom HTML document. This has sometimes been accomplished with an "HTML Snippet" technique -- the bare, literal HTML code for a profile-form is manually copied and pasted to an external web site.
The CiviCRM log file is stored in data folder determined by the CMS. In all supported CMS's, this data folder defaults to world-readable, but CiviCRM needs to store logs confidentially. CiviCRM relies on two redundant protections to ensure that log files remain confidential:
CiviCRM includes a handful of backend scripts (bin/migrate/*.php and bin/encryptDB.php) which facilitate some special workflows (such as migrating site-configurations and obfuscating the database). These scripts include security protections, but -- depending on your organizational policies -- these protections may be inadequate. CiviCRM v4.7.11+ tightens access to these scripts.
Who is impacted?
In older versions, the security of these scripts rests on three things: a username, a password, and the site-key.
An automated security audit (based on static code analysis of the CiviCRM codebase) indicated that a dependency (PEAR CLI from the "packages" folder) could potentially reveal semi-sensitive backtrace data if an attacker could run it and provoke an error.
An exploit of this has not been identified.
As a precautionary measure, CiviCRM v4.7.11 removes PEAR CLI.
This release addresses an issue where it was possible to deliver a cross-site scripting attack through the CiviCRM backend.
To exploit this vulnerability, both the attacker and victim need permission to access the CiviCRM backend, and the victim must visit a specific screen.
Multiple SQL injections have been identified in AJAX helpers supporting backend forms. An exploit has been demonstrated. Executing an exploit requires a user account with some kind of CiviCRM permission (such as "access CiviCRM" or "view my contact").
This release addresses an issue where it was possible to deliver XSS by directing a user to a CiviCRM URL which triggered a fatal error. The issue has been addressed by correctly escaping output from CiviCRM's fatal error handler.
The CiviCRM footer may have been displayed to users without "access CiviCRM" permission under certain conditions. The footer shows limited version information and upgrade notifications, which could be used by an attacker to identify vulnerabilities based on whether the installed version is up-to-date.
There was a bug in one of CiviCRM's internal type checks which may allow inappropriate user input to be saved to the database and/or displayed.
This was a general weakness in one of CiviCRM's security layers; no specific exploits of this have been identified. This type of vulnerability could potentially allow attackers to save malicious content to the database or display it to site users.
The backend CiviMail composition screen includes an input field which is passed to a SQL query without proper escaping.
An exploit of this vulnerability in CiviCRM has not been identified. Additional filters apply to the field which block a number of SQL control characters. Never-the-less, it could potentially be combined with other vulnerabilities, and we're issuing a patch as a precaution.
The Smarty templating engine includes a defect in which a specially named Smarty template could be used to execute PHP code.
An exploit of this vulnerability in CiviCRM has not been identified. Exploiting it requires that an attacker have permission to set the name and content of a template file; in CiviCRM deployments, this permission is generally only available to system administrators. Never-the-less, it could potentially be combined with other vulnerabilities, and we're issuing a patch as a precaution.
By default, CiviCRM records log entries in a flat text file. Optionally, log entries may be directed to Drupal's watchdog() service. If this option is enabled, and if a log entry includes user-supplied data, the user-supplied data may not be correctly encoded. When an administrator browses the log entries, they may be exposed to a cross-site scripting attack.
Cross-Site Scripting (XSS) is a technique used to embed malicious content into the resulting web page. As such, it is pertinent to note that this class of attack targets end-users rather than the web application itself. When this attack is considered “reflected”, a user requests a web page with a payload which is embedded within a crafted hyperlink or a malicious page.
Certain AJAX callbacks in CiviCRM did not properly encode their outputs - making them vulnerable to cross-site scripting attacks.
CiviCRM includes the dompdf library for generating PDF documents. The dompdf library includes a standalone utility script, "dompdf.php"; old versions of the script are vulnerable to an arbitrary file access issue when the system is configured with option "DOMPDF_ENABLE_REMOTE".
CiviCase functionality includes several urls which allow a user to view and edit a limited amount of case info. Some of these urls were not adequately checking permissions and could be used by any user with "Access CiviCRM" permission.
This problem only affects sites using the CiviCase component. It is mitigated by the fact that the user must have "Access CiviCRM," a permission not normally granted to untrusted users.
CiviCRM Access Control Lists (ACLs) allow site administrators to grant or revoke access to specifics groups/contacts. In CiviCRM 4.4.x, any staff user with access to the "Export" functionality could bypass the ACLs.
CiviCRM uses AJAX callbacks to provide advisory details while completing certain forms. For example, when registering a new user through a profile form, CiviCRM issues an AJAX request to determine whether the username is available.
Some AJAX callbacks did not test for authorization, enabling untrusted parties to:
Determine whether a username was in-use
Determine the primary email address for a given contact ID
Determine the list of available options in certain custom-field
The CiviCRM Profile subsystem allows administrators to design customized forms. The subsystem includes some advanced workflow settings which are not securely handled. By submitting a custom-crafted form to the Profile subsystem, an attacker may manipulate these settings. This vulnerability can be leveraged to acquire escalated privileges and (possibly) to issue open redirects.
A small number of CiviCRM entry points had faulty permission checks. This could allow hackers, under certain circumstances, to view basic contact information such as name, email, phone, or address for contacts in the database.
The risk is limited to viewing basic contact information - it does not include contributions, memberships, passwords or other data. It does not give hackers the ability to login or make changes to the database.
All sites are advised to upgrade immediately to avoid the potential risk.
html2text is a library which converts HTML documents to plain-text documents. CiviMail uses html2text to convert HTML email messages to plain-text email messages. A bug in the processing of certain HTML tags causes html2text to evaluate PHP code from the HTML document. Any authenticated staff user with permission to send email (e.g. permission "access CiviMail") can therefore execute PHP code.
This vulnerability is mitigated by the following factors:
Smarty is a template library responsible for composing web-page output in CiviCRM. If Smarty encounters an internal processing error (such as an unknown template-file or unknown template-function), then it outputs an error message. In Smarty 2.6.26 and earlier, the error message is not properly escaped and (in combination with other, unidentified flaws) may provide a vector for a cross-site scripting attack. The issue is resolved in Smarty 2.6.27 and CiviCRM 4.3.4.