Security Advisories

Previously there was no validation of the passed in grp url parameter which was passed in to the grouping part of an SQL which allowed for SQL injection possibility. The SQL to list the reports has now been re-written to properly validate all variables that are used in the SQL. 

There wasn't any validation on the key url parameter which allowed for some cross site scripting to potentially occur. The fix is to add in validation to ensure the key is of normal standard extension key pattern.

CiviCRM used to output the Search criteria in the description field without any escaping. Given that certain parts of the criteria in a search form can be passed through as URL parameters, there was the possibility of XSS scripting coming in and not being properly escaped when displayed. 

When viewing the list of message templates, one could pass through a variable called selectedChild through the URL which would specify which of the two lists it would default to showing. This variable was not properly validated against the known two types (user  and workflow). There is now proper validation on the url parameter

Administrators were able to store and have displayed through the description field on a tag cross site scripting code. This would show up when the system tried to display the description as an alt html tag. It has now been changed to properly escape the alt tag

The form processing for the dedupe rules listing page did not properly validate the contact type variable that is passed through in the URL parameters. This potentially allowed for XSS to occur. This has been fixed to allow for only known contact types to be passed in. 

When creating premium product in CiviCRM, the output of the product name was not properly being escaped as the alternate text when an image was being used for the product. This had the potential on contribution pages to expose credit card information. 

As part of CiviCRM's defense in depth program, we have upgraded Smarty following an announcement by them that one of the functions in the Smarty templating engine potentially allowed for shell injection.

Despite this vulnerability in the Smarty library, CiviCRM's usage of Smarty appears to prevent such shell injection vulnerabilities.

In a number of locations within the CiviCRM code base there were potentially un-escaped variables passed into html link attributes such as alt and title​. One such example was in event registration pages where administrators were able to set the button text and also the title attribute to anything they chose. This fixes it by properly escaping the content of those attributes. 

In the "Search Results" screen, some elements were not properly escaped.

Drupal Views allows an administrator to produce a screen with data from CiviCRM's custom-fields. Certain custom-fields could potentially be manipulated to inject SQL.

When viewing the CiviCRM "Mailing" report, a logged-in user could modify the URL to access the report for another mailing -- even if
they ordinarily would not have access that information.
 

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.

The pingback system is an optional mechanism which reports statistical data to civicrm.org. The pingback URL specified an unencrypted protocol (HTTP), and well-positioned eavesdropper could potentially intercept statistical data. The pingback URL should specify an encrypted protocol (HTTPS) to prevent eavesdropping.

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.
 

In the "Recently Viewed" block, the title field of the hyperlink was not properly escaped.

In CiviContribute forms which combine the "On Behalf Of" feature with "Organization" records, some data was not properly escaped.

When displaying entity reference fields, the labels were not properly being escaped.

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.

When generating an API query, the ORDER BY clause for some entities was not correctly validated and escaped. This may have permitted data disclosure via time-based blind SQL attacks.

This is mitigated by the fact that attacks would require API access to exploit the vulnerability.

It was identified that inputs were not correctly validated when viewing an activity related to a case, due to custom group title not being properly escaped for SQL generation.

This is mitigated by the fact that an attacker would need to have the "administer CiviCRM" permission, and that the issue only affects sites with CiviCase enabled.

It was identified that CRM_Contact_BAO_Query::apiQuery did not correctly validate contact ID inputs. This could expose contact data via SQL injection.

This is mitigated by permissions restrictions meaning that anonymous users would not typically be able to exploit this vector.

Sites which use the Drupal 6 "devel" module with CiviCRM to log SQL queries may be vulnerable to a SQL injection. However, it is not clear if this vulnerability is exploitable.

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: