After successfully calling the "Contact.create" API, the caller could receive a list of all fields relating to the contact -- including a sensitive field that normally has restricted access. In some contexts, leaking the sensitive field could allow an attacker to access CiviCRM as the targeted user.

This issue affects your site if it is hosted on WordPress, and you use ACLs to restrict access to contact data.

It was identified that CiviCRM on WordPress CMS did not correctly trigger ACL checks when viewing CiviCRM profile URLs via checksum. This might lead sites to disclose some contact data via profile pages.

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.

CiviCRM allows users to import contacts using CSV or SQL. Prior to 4.7.11 (or 4.6.21), the permission "import contacts" allowed users to import by any means -- either CSV or SQL. A user with this permission could use it to bypass ACL rules. Beginning with 4.7.11+ (or 4.6.21+), there is now a separate permission "import SQL datasource". If you want your users to be able to import contacts using SQL, you must now grant both permissions ("import contacts" and "import SQL datasource").

CiviCRM previously did not set secure flags to restrict cookies to SSL where appropriate. This was not a security risk by itself, but the change is being made and notified in security release information as part of a wider "defense in depth" process within CiviCRM.

An access bypass was identified where if a user was permitted only the "View own contact" permission in the CMS, they were also able to edit their own contact. This bypass of permissions checking did not extend to other contacts in CiviCRM.

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").

A bundled library, TCPDF, had a recent security flaw patched. This vulnerability permitted a malicious user to make the PDF library perform unexpected actions, potentially permitting data disclosure. This was mitigated by the fact that only administrative users have access to the PDF generation functionality which uses TCPDF.