Core Security Advisories

Subscribe to Core Security Advisories feed
Updated: 1 hour 16 min ago

Drupal Core - Multiple Vulnerabilities - SA-CORE-2017-004

Wed, 08/16/2017 - 12:38pm

Drupal 8.3.7 is a maintenance releases which contain fixes for security vulnerabilities.

Download Drupal 8.3.7

Updating your existing Drupal 8 sites is strongly recommended (see instructions for Drupal 8). This release fixes security issues only; there are no new features nor non-security-related bug fixes in this release. See the 8.3.7 release notes for details on important changes and known issues affecting this release. Read on for details of the security vulnerabilities that were fixed in this release.

Description Views - Access Bypass - Moderately Critical - Drupal 8 - CVE-2017-6923

When creating a view, you can optionally use Ajax to update the displayed data via filter parameters. The views subsystem/module did not restrict access to the Ajax endpoint to only views configured to use Ajax. This is mitigated if you have access restrictions on the view.

It is best practice to always include some form of access restrictions on all views, even if you are using another module to display them.

REST API can bypass comment approval - Access Bypass - Moderately Critical - Drupal 8 - CVE-2017-6924

When using the REST API, users without the correct permission can post comments via REST that are approved even if the user does not have permission to post approved comments.

This issue only affects sites that have the RESTful Web Services (rest) module enabled, the comment entity REST resource enabled, and where an attacker can access a user account on the site with permissions to post comments, or where anonymous users can post comments.

Entity access bypass for entities that do not have UUIDs or have protected revisions - Access Bypass - Critical - Drupal 8 - CVE-2017-6925

There is a vulnerability in the entity access system that could allow unwanted access to view, create, update, or delete entities. This only affects entities that do not use or do not have UUIDs, and entities that have different access restrictions on different revisions of the same entity.

Versions affected
  • Drupal core 8.x versions prior to 8.3.7
Solution

Install the latest version:

Drupal 7 core is not affected, however, Drupal 7 Views is: see Views - Moderately Critical - Access Bypass - DRUPAL-SA-CONTRIB-2017-068

Also see the Drupal core project page.

Reported by Views - Access Bypass REST API can bypass comment approval - Access Bypass Entity access bypass for entities that do not have UUIDs or protected revisions - Access Bypass Fixed by Views - Access Bypass REST API can bypass comment approval - Access Bypass Entity access bypass for entities that do not have UUIDs or protected revisions - Access Bypass Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal Core - Multiple Vulnerabilities - SA-CORE-2017-003

Wed, 06/21/2017 - 1:44pm

Drupal 8.3.4 and Drupal 7.56 are maintenance releases which contain fixes for security vulnerabilities.

Download Drupal 8.3.4 Download Drupal 7.56

Updating your existing Drupal 8 and 7 sites is strongly recommended (see instructions for Drupal 8 and for Drupal 7). This release fixes security issues only; there are no new features nor non-security-related bug fixes in this release. See the 8.3.4 release notes and the 7.56 release notes for details on important changes and known issues affecting this release. Read on for details of the security vulnerabilities that were fixed in this release.

  • Advisory ID: DRUPAL-SA-CORE-2017-003
  • Project: Drupal core
  • Version: 7.x, 8.x
  • Date: 2017-June-21
  • Multiple vulnerabilities
Description PECL YAML parser unsafe object handling - Critical - Drupal 8 - CVE-2017-6920

PECL YAML parser does not handle PHP objects safely during certain operations within Drupal core. This could lead to remote code execution.

File REST resource does not properly validate - Less Critical - Drupal 8 - CVE-2017-6921

The file REST resource does not properly validate some fields when manipulating files. A site is only affected by this if the site has the RESTful Web Services (rest) module enabled, the file REST resource is enabled and allows PATCH requests, and an attacker can get or register a user account on the site with permissions to upload files and to modify the file resource.

Files uploaded by anonymous users into a private file system can be accessed by other anonymous users - Moderately Critical - Drupal 7 and Drupal 8 - CVE-2017-6922

Private files that have been uploaded by an anonymous user but not permanently attached to content on the site should only be visible to the anonymous user that uploaded them, rather than all anonymous users. Drupal core did not previously provide this protection, allowing an access bypass vulnerability to occur. This issue is mitigated by the fact that in order to be affected, the site must allow anonymous users to upload files into a private file system.

The security team has also received reports that this vulnerability is being exploited for spam purposes, similar to the scenario discussed in PSA-2016-003 for the public file system.

Versions affected
  • Drupal core 7.x versions prior to 7.56
  • Drupal core 8.x versions prior to 8.3.4
Solution

Install the latest version:

Also see the Drupal core project page.

Reported by PECL YAML parser unsafe object handling File REST resource does not properly validate Files uploaded by anonymous users into a private file system can be accessed by other anonymous users Fixed by PECL YAML parser unsafe object handling File REST resource does not properly validate Files uploaded by anonymous users into a private file system can be accessed by other anonymous users Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal version: Drupal 7.xDrupal 8.x

Drupal Core - Critical - Access Bypass - SA-CORE-2017-002

Wed, 04/19/2017 - 1:13pm
Description

This is a critical access bypass vulnerability. A site is only affected by this if all of the following conditions are met:

  • The site has the RESTful Web Services (rest) module enabled.
  • The site allows PATCH requests.
  • An attacker can get or register a user account on the site.

While we don't normally provide security releases for unsupported minor releases, given the potential severity of this issue, we have also provided an 8.2.x release to ensure that sites that have not had a chance to update to 8.3.0 can update safely.

CVE identifier(s) issued
  • A CVE identifier will be requested, and added upon issuance, in accordance with Drupal Security Team processes.
Versions affected
  • Drupal 8 prior to 8.2.8 and 8.3.1.
  • Drupal 7.x is not affected.
Solution
  • If the site is running Drupal 8.2.7 or earlier, upgrade to 8.2.8.
  • If the site is running Drupal 8.3.0, upgrade to 8.3.1.

Also see the Drupal core project page.

Reported by Fixed by Coordinated by
  • The Drupal Security team
Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal Core - Multiple Vulnerabilities - SA-CORE-2017-001

Wed, 03/15/2017 - 3:24pm

Drupal 8.2.7, a maintenance release which contains fixes for security vulnerabilities, is now available for download.

Download Drupal 8.2.7

Upgrading your existing Drupal 8 sites is strongly recommended. There are no new features nor non-security-related bug fixes in this release. See the 8.2.7 release notes for details on important changes and known issues affecting this release. Read on for details of the security vulnerabilities that were fixed in this release.

  • Advisory ID: DRUPAL-SA-CORE-2017-001
  • Project: Drupal core
  • Version: 8.x
  • Date: 2017-March-15
Description Editor module incorrectly checks access to inline private files - Drupal 8 - Access Bypass - Critical - CVE-2017-6377

When adding a private file via a configured text editor (like CKEditor), the editor will not correctly check access for the file being attached, resulting in an access bypass.

Some admin paths were not protected with a CSRF token - Drupal 8 - Cross Site Request Forgery - Moderately Critical - CVE-2017-6379

Some administrative paths did not include protection for CSRF. This would allow an attacker to disable some blocks on a site. This issue is mitigated by the fact that users would have to know the block ID.

Remote code execution - Drupal 8 - Remote code execution - Moderately Critical - CVE-2017-6381

A 3rd party development library including with Drupal 8 development dependencies is vulnerable to remote code execution.

This is mitigated by the default .htaccess protection against PHP execution, and the fact that Composer development dependencies aren't normal installed.

You might be vulnerable to this if you are running a version of Drupal before 8.2.2. To be sure you aren’t vulnerable, you can remove the /vendor/phpunit directory from the site root of your production deployments.

Solution

Upgrade to Drupal 8.2.7

Reported by Editor module incorrectly checks access to inline private files - Drupal 8 - Access Bypass - Critical - CVE-2017-6377 Some admin paths were not protected with a CSRF token - Drupal 8 - Cross Site Request Forgery - Moderately Critical - CVE-2017-6379 Remote code execution - Drupal 8 - Remote code execution - Moderately Critical - CVE-2017-6381 Fixed by Editor module incorrectly checks access to inline private files - Drupal 8 - Access Bypass - Critical - CVE-2017-6377 Some admin paths were not protected with a CSRF token - Drupal 8 - Cross Site Request Forgery - Moderately Critical - CVE-2017-6379 Remote code execution - Drupal 8 - Remote code execution -Moderately Critical - CVE-2017-6381 Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal Core - Moderately Critical - Multiple Vulnerabilities - SA-CORE-2016-005

Wed, 11/16/2016 - 12:37pm
Description Inconsistent name for term access query (Less critical - Drupal 7 and Drupal 8)

Drupal provides a mechanism to alter database SELECT queries before they are executed. Contributed and custom modules may use this mechanism to restrict access to certain entities by implementing hook_query_alter() or hook_query_TAG_alter() in order to add additional conditions. Queries can be distinguished by means of query tags. As the documentation on EntityFieldQuery::addTag() suggests, access-tags on entity queries normally follow the form ENTITY_TYPE_access (e.g. node_access). However, the taxonomy module's access query tag predated this system and used term_access as the query tag instead of taxonomy_term_access.

As a result, before this security release modules wishing to restrict access to taxonomy terms may have implemented an unsupported tag, or needed to look for both tags (term_access and taxonomy_term_access) in order to be compatible with queries generated both by Drupal core as well as those generated by contributed modules like Entity Reference. Otherwise information on taxonomy terms might have been disclosed to unprivileged users.

Incorrect cache context on password reset page (Less critical - Drupal 8)

The user password reset form does not specify a proper cache context, which can lead to cache poisoning and unwanted content on the page.

Confirmation forms allow external URLs to be injected (Moderately critical - Drupal 7)

Under certain circumstances, malicious users could construct a URL to a confirmation form that would trick users into being redirected to a 3rd party website after interacting with the form, thereby exposing the users to potential social engineering attacks.

Denial of service via transliterate mechanism (Moderately critical - Drupal 8)

A specially crafted URL can cause a denial of service via the transliterate mechanism.

CVE identifier(s) issued
  • A CVE identifier will be requested, and added upon issuance, in accordance with Drupal Security Team processes.
Versions affected
  • Drupal core 7.x versions prior to 7.52
  • Drupal core 8.x versions prior to 8.2.3
Solution

Install the latest version:

Also see the Drupal core project page.

Reported by

Inconsistent name for term access query:

Incorrect cache context on password reset page:

Confirmation forms allow external URLs to be injected:

Denial of service via transliterate mechanism:

Fixed by

Inconsistent name for term access query:

Incorrect cache context on password reset page:

Confirmation forms allow external URLs to be injected:

Denial of service via transliterate mechanism:

Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal version: Drupal 7.xDrupal 8.x

Drupal Core - Critical - Multiple Vulnerabilities - SA-CORE-2016-004

Wed, 09/21/2016 - 12:35pm
Description

Users who have rights to edit a node, can set the visibility on comments for that node.

Description

Users without "Administer comments" can set comment visibility on nodes they can edit. (Less critical)

Users who have rights to edit a node, can set the visibility on comments for that node. This should be restricted to those who have the administer comments permission.

Cross-site Scripting in http exceptions (critical)

An attacker could create a specially crafted url, which could execute arbitrary code in the victim’s browser if loaded. Drupal was not properly sanitizing an exception

Full config export can be downloaded without administrative permissions (critical)
The system.temporary route would allow the download of a full config export. The full config export should be limited to those with Export configuration permission.

CVE identifier(s) issued
  • A CVE identifier will be requested, and added upon issuance, in accordance with Drupal Security Team processes.
Versions affected

8.x

Solution

Upgrade to Drupal 8.1.10

Reported by

Users without "Administer comments" can set comment visibility on nodes they can edit.

XSS in http exceptions

Full config export can be downloaded without administrative permissions

Fixed by

Users without "Administer comments" can set comment visibility on nodes they can edit.

XSS in http exceptions

Full config export can be downloaded without administrative permissions

Coordinated by

The Drupal Security Team

Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal version: Drupal 8.x

Drupal Core - Highly Critical - Injection - SA-CORE-2016-003

Mon, 07/18/2016 - 9:53am
Description

Drupal 8 uses the third-party PHP library Guzzle for making server-side HTTP requests. An attacker can provide a proxy server that Guzzle will use. The details of this are explained at https://httpoxy.org/.

CVE identifier(s) issued
  • CVE-2016-5385
Versions affected
  • Drupal core 8.x versions prior to 8.1.7
Solution

Install the latest version:

  • If you use Drupal 8.x, upgrade to Drupal core 8.1.7
  • If you use Drupal 7.x, Drupal core is not affected. However you should consider using the mitigation steps at https://httpoxy.org/ since you might have modules or other software on your server affected by this issue. For example, sites using Apache can add the following code to .htaccess:
    <IfModule mod_headers.c> RequestHeader unset Proxy </IfModule>

We also suggest mitigating it as described here: https://httpoxy.org/

Also see the Drupal core project page.

What if I am running Drupal core 8.0.x?

Drupal core 8.0.x is no longer supported. Update to 8.1.7 to get the latest security and bug fixes.

Why is this being released Monday rather than Wednesday?

The Drupal Security Team usually releases Security Advisories on Wednesdays. However, this vulnerability affects more than Drupal, and the authors of Guzzle and reporters of the issue coordinated to make it public Monday. Therefore, we are issuing a core release to update to the secure version of Guzzle today.

Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal version: Drupal 8.x

Drupal Core - Moderately Critical - Multiple Vulnerabilities - SA-CORE-2016-002

Wed, 06/15/2016 - 2:45pm
Description Saving user accounts can sometimes grant the user all roles (User module - Drupal 7 - Moderately Critical)

A vulnerability exists in the User module, where if some specific contributed or custom code triggers a rebuild of the user profile form, a registered user can be granted all user roles on the site. This would typically result in the user gaining administrative access.

This issue is mitigated by the fact that it requires contributed or custom code that performs a form rebuild during submission of the user profile form.

Views can allow unauthorized users to see Statistics information (Views module - Drupal 8 - Less Critical)

An access bypass vulnerability exists in the Views module, where users without the "View content count" permission can see the number of hits collected by the Statistics module for results in the view.

This issue is mitigated by the fact that the view must be configured to show a "Content statistics" field, such as "Total views", "Views today" or "Last visit".

The same vulnerability exists in the Drupal 7 Views module (see SA-CONTRIB-2016-036).

CVE identifier(s) issued
  • A CVE identifier will be requested, and added upon issuance, in accordance with Drupal Security Team processes.
Versions affected
  • Drupal core 7.x versions prior to 7.44
  • Drupal core 8.x versions prior to 8.1.3
Solution

Install the latest version:

Also see the Drupal core project page.

Reported by

Saving user accounts can sometimes grant the user all roles:

Views can allow unauthorized users to see Statistics information:

Fixed by

Saving user accounts can sometimes grant the user all roles:

Views can allow unauthorized users to see Statistics information:

Coordinated by

The Drupal Security Team

Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal version: Drupal 7.xDrupal 8.x

Drupal Core - Critical - Multiple Vulnerabilities - SA-CORE-2016-001

Wed, 02/24/2016 - 12:33pm
Description File upload access bypass and denial of service (File module - Drupal 7 and 8 - Moderately Critical)

A vulnerability exists in the File module that allows a malicious user to view, delete or substitute a link to a file that the victim has uploaded to a form while the form has not yet been submitted and processed. If an attacker carries out this attack continuously, all file uploads to a site could be blocked by deleting all temporary files before they can be saved.

This vulnerability is mitigated by the fact that the attacker must have permission to create content or comment and upload files as part of that process.

Brute force amplification attacks via XML-RPC (XML-RPC server - Drupal 6 and 7 - Moderately Critical)

The XML-RPC system allows a large number of calls to the same method to be made at once, which can be used as an enabling factor in brute force attacks (for example, attempting to determine user passwords by submitting a large number of password variations at once).

This vulnerability is mitigated by the fact that you must have enabled a module that provides an XML-RPC method that is vulnerable to brute-forcing. There are no such modules in Drupal 7 core, but Drupal 6 core is vulnerable via the Blog API module. It is additionally mitigated if flood control protection is in place for the method in question.

Open redirect via path manipulation (Base system - Drupal 6, 7 and 8 - Moderately Critical)

In Drupal 6 and 7, the current path can be populated with an external URL. This can lead to Open Redirect vulnerabilities.

This vulnerability is mitigated by the fact that it would only occur in combination with custom code, or in certain cases if a user submits a form shown on a 404 page with a specially crafted URL.

For Drupal 8 this is a hardening against possible browser flaws handling certain redirect paths.

Form API ignores access restrictions on submit buttons (Form API - Drupal 6 - Critical)

An access bypass vulnerability was found that allows input to be submitted, for example using JavaScript, for form button elements that a user is not supposed to have access to because the button was blocked by setting #access to FALSE in the server-side form definition.

This vulnerability is mitigated by the fact that the attacker must have access to submit a form that has such buttons defined for it (for example, a form that both administrators and non-administrators can access, but where administrators have additional buttons available to them).

HTTP header injection using line breaks (Base system - Drupal 6 - Moderately Critical)

A vulnerability in the drupal_set_header() function allows an HTTP header injection attack to be performed if user-generated content is passed as a header value on sites running PHP versions older than 5.1.2. If the content contains line breaks the user may be able to set arbitrary headers of their own choosing.

This vulnerability is mitigated by the fact that most hosts have newer versions of PHP installed, and that it requires a module to be installed on the site that allows user-submitted data to appear in HTTP headers.

Open redirect via double-encoded 'destination' parameter (Base system - Drupal 6 - Moderately Critical)

The drupal_goto() function in Drupal 6 improperly decodes the contents of $_REQUEST['destination'] before using it, which allows the function's open redirect protection to be bypassed and allows an attacker to initiate a redirect to an arbitrary external URL.

This vulnerability is mitigated by that fact that the attack is not possible for sites running on PHP 5.4.7 or greater.

Reflected file download vulnerability (System module - Drupal 6 and 7 - Moderately Critical)

Drupal core has a reflected file download vulnerability that could allow an attacker to trick a user into downloading and running a file with arbitrary JSON-encoded content.

This vulnerability is mitigated by the fact that the victim must be a site administrator and that the full version of the attack only works with certain web browsers.

Saving user accounts can sometimes grant the user all roles (User module - Drupal 6 and 7 - Less Critical)

Some specific contributed or custom code may call Drupal's user_save() API in a manner different than Drupal core. Depending on the data that has been added to a form or the array prior to saving, this can lead to a user gaining all roles on a site.

This issue is mitigated by the fact that it requires contributed or custom code that calls user_save() with an explicit category and code that loads all roles into the array.

Email address can be matched to an account (User module - Drupal 7 and 8 - Less Critical)

In certain configurations where a user's email addresses could be used to log in instead of their username, links to "have you forgotten your password" could reveal the username associated with a particular email address, leading to an information disclosure vulnerability.

This issue is mitigated by the fact that it requires a contributed module to be installed that permits logging in with an email address, and that it is only relevant on sites where usernames are typically chosen to hide the users' real-life identities.

Session data truncation can lead to unserialization of user provided data (Base system - Drupal 6 - Less Critical)

On certain older versions of PHP, user-provided data stored in a Drupal session may be unserialized leading to possible remote code execution.

This issue is mitigated by the fact that it requires an unusual set of circumstances to exploit and depends on the particular Drupal code that is running on the site. It is also believed to be mitigated by upgrading to PHP 5.4.45, 5.5.29, 5.6.13, or any higher version.

CVE identifier(s) issued (#)
  • CVE identifiers will be requested, and added upon issuance, in accordance with Drupal Security Team processes.
Versions affected
  • Drupal core 6.x versions prior to 6.38
  • Drupal core 7.x versions prior to 7.43
  • Drupal core 8.0.x versions prior to 8.0.4
Solution

Install the latest version:

Also see the Drupal core project page.

Reported by

File upload access bypass and denial of service:

Brute force amplification attacks via XML-RPC:

Open redirect via path manipulation:

Form API ignores access restrictions on submit buttons:

HTTP header injection using line breaks:

Open redirect via double-encoded 'destination' parameter:

Reflected file download vulnerability:

Saving user accounts can sometimes grant the user all roles:

Email address can be matched to an account:

Session data truncation can lead to unserialization of user provided data:

Fixed by

File upload access bypass and denial of service:

Brute force amplification attacks via XML-RPC:

Open redirect via path manipulation:

Form API ignores access restrictions on submit buttons:

HTTP header injection using line breaks:

Open redirect via double-encoded 'destination' parameter:

Reflected file download vulnerability:

Saving user accounts can sometimes grant the user all roles:

Email address can be matched to an account:

Session data truncation can lead to unserialization of user provided data:

Coordinated by Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal version: Drupal 6.xDrupal 7.xDrupal 8.x

Drupal Core - Overlay - Less Critical - Open Redirect - SA-CORE-2015-004

Wed, 10/21/2015 - 3:16pm
Description

The Overlay module in Drupal core displays administrative pages as a layer over the current page (using JavaScript), rather than replacing the page in the browser window. The Overlay module does not sufficiently validate URLs prior to displaying their contents, leading to an open redirect vulnerability.

This vulnerability is mitigated by the fact that it can only be used against site users who have the "Access the administrative overlay" permission, and that the Overlay module must be enabled.

An incomplete fix for this issue was released as part of SA-CORE-2015-002.

CVE identifier(s) issued
  • A CVE identifier will be requested, and added upon issuance, in accordance with Drupal Security Team processes.
Versions affected
  • Drupal core 7.x versions prior to 7.41.
Solution

Install the latest version:

Also see the Drupal core project page.

Reported by Fixed by Coordinated by Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal version: Drupal 7.x

Drupal Core - Critical - Multiple Vulnerabilities - SA-CORE-2015-003

Wed, 08/19/2015 - 3:27pm

This security advisory fixes multiple vulnerabilities. See below for a list.

Cross-site Scripting - Ajax system - Drupal 7

A vulnerability was found that allows a malicious user to perform a cross-site scripting attack by invoking Drupal.ajax() on a whitelisted HTML element.

This vulnerability is mitigated on sites that do not allow untrusted users to enter HTML.

Drupal 6 core is not affected, but see the similar advisory for the Drupal 6 contributed Ctools module: SA-CONTRIB-2015-141.

Cross-site Scripting - Autocomplete system - Drupal 6 and 7

A cross-site scripting vulnerability was found in the autocomplete functionality of forms. The requested URL is not sufficiently sanitized.

This vulnerability is mitigated by the fact that the malicious user must be allowed to upload files.

SQL Injection - Database API - Drupal 7

A vulnerability was found in the SQL comment filtering system which could allow a user with elevated permissions to inject malicious code in SQL comments.

This vulnerability is mitigated by the fact that only one contributed module that the security team found uses the comment filtering system in a way that would trigger the vulnerability. That module requires you to have a very high level of access in order to perform the attack.

Cross-site Request Forgery - Form API - Drupal 6 and 7

A vulnerability was discovered in Drupal's form API that could allow file upload value callbacks to run with untrusted input, due to form token validation not being performed early enough. This vulnerability could allow a malicious user to upload files to the site under another user's account.

This vulnerability is mitigated by the fact that the uploaded files would be temporary, and Drupal normally deletes temporary files automatically after 6 hours.

Information Disclosure in Menu Links - Access system - Drupal 6 and 7

Users without the "access content" permission can see the titles of nodes that they do not have access to, if the nodes are added to a menu on the site that the users have access to.

CVE identifier(s) issued
  • CVE identifiers have been requested and will be added upon issuance, in accordance with Drupal Security Team processes.
Versions affected
  • Drupal core 6.x versions prior to 6.37
  • Drupal core 7.x versions prior to 7.39
Solution

Install the latest version:

Also see the Drupal core project page.

Credits Cross-site Scripting - Ajax system - Drupal 7 Reported by Fixed by Cross-site Scripting - Autocomplete system - Drupal 6 and 7 Reported by Fixed by SQL Injection - Database API - Drupal 7 Reported by Fixed by Cross-site Request Forgery - Form API - Drupal 6 and 7 Reported by Fixed by Information Disclosure in Menu Links - Access system - Drupal 6 and 7 Reported by Fixed by Coordinated by
  • Alex Bronstein, Angie Byron, Michael Hess, Pere Orga, David Rothstein and Peter Wolanin of the Drupal Security Team
Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal version: Drupal 6.xDrupal 7.x

Drupal Core - Critical - Multiple Vulnerabilities - SA-CORE-2015-002

Wed, 06/17/2015 - 12:12pm
Description Impersonation (OpenID module - Drupal 6 and 7 - Critical)

A vulnerability was found in the OpenID module that allows a malicious user to log in as other users on the site, including administrators, and hijack their accounts.

This vulnerability is mitigated by the fact that the victim must have an account with an associated OpenID identity from a particular set of OpenID providers (including, but not limited to, Verisign, LiveJournal, or StackExchange).

Open redirect (Field UI module - Drupal 7 - Less critical)

The Field UI module uses a "destinations" query string parameter in URLs to redirect users to new destinations after completing an action on a few administration pages. Under certain circumstances, malicious users can use this parameter to construct a URL that will trick users into being redirected to a 3rd party website, thereby exposing the users to potential social engineering attacks.

This vulnerability is mitigated by the fact that only sites with the Field UI module enabled are affected.

Drupal 6 core is not affected, but see the similar advisory for the Drupal 6 contributed CCK module: SA-CONTRIB-2015-126

Open redirect (Overlay module - Drupal 7 - Less critical)

The Overlay module displays administrative pages as a layer over the current page (using JavaScript), rather than replacing the page in the browser window. The Overlay module does not sufficiently validate URLs prior to displaying their contents, leading to an open redirect vulnerability.

This vulnerability is mitigated by the fact that it can only be used against site users who have the "Access the administrative overlay" permission, and that the Overlay module must be enabled.

Information disclosure (Render cache system - Drupal 7 - Less critical)

On sites utilizing Drupal 7's render cache system to cache content on the site by user role, private content viewed by user 1 may be included in the cache and exposed to non-privileged users.

This vulnerability is mitigated by the fact that render caching is not used in Drupal 7 core itself (it requires custom code or the contributed Render Cache module to enable) and that it only affects sites that have user 1 browsing the live site. Exposure is also limited if an administrative role has been assigned to the user 1 account (which is done, for example, by the Standard install profile that ships with Drupal core).

CVE identifier(s) issued
  • Impersonation (OpenID module - Drupal 6 and 7): CVE-2015-3234
  • Open redirect (Field UI module - Drupal 7): CVE-2015-3232
  • Open redirect (Overlay module - Drupal 7: CVE-2015-3233
  • Information disclosure (Render cache system - Drupal 7): CVE-2015-3231
Versions affected
  • Drupal core 6.x versions prior to 6.36
  • Drupal core 7.x versions prior to 7.38
Solution

Install the latest version:

Also see the Drupal core project page.

Reported by

Impersonation in the OpenID module:

Open redirect in the Field UI module:

Open redirect in the Overlay module:

Information disclosure in the render cache system:

Fixed by

Impersonation in the OpenID module:

Open redirect in the Field UI module:

Open redirect in the Overlay module:

Information disclosure in the render cache system:

Coordinated by Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal version: Drupal 6.xDrupal 7.x

Drupal Core - Moderately Critical - Multiple Vulnerabilities - SA-CORE-2015-001

Wed, 03/18/2015 - 2:04pm
Description Access bypass (Password reset URLs - Drupal 6 and 7)

Password reset URLs can be forged under certain circumstances, allowing an attacker to gain access to another user's account without knowing the account's password.

In Drupal 7, this vulnerability is mitigated by the fact that it can only be exploited on sites where accounts have been imported or programmatically edited in a way that results in the password hash in the database being the same for multiple user accounts. In Drupal 6, it can additionally be exploited on sites where administrators have created multiple new user accounts with the same password via the administrative interface, or where accounts have been imported or programmatically edited in a way that results in the password hash in the database being empty for at least one user account.

Drupal 6 sites that have empty password hashes, or a password field with a guessable string in the database, are especially prone to this vulnerability. This could apply to sites that use external authentication so that the password field is set to a fixed, invalid value.

Open redirect (Several vectors including the "destination" URL parameter - Drupal 6 and 7)

Drupal core and contributed modules frequently use a "destination" query string parameter in URLs to redirect users to a new destination after completing an action on the current page. Under certain circumstances, malicious users can use this parameter to construct a URL that will trick users into being redirected to a 3rd party website, thereby exposing the users to potential social engineering attacks.

In addition, several URL-related API functions in Drupal 6 and 7 can be tricked into passing through external URLs when not intending to, potentially leading to additional open redirect vulnerabilities.

This vulnerability is mitigated by the fact that many common uses of the "destination" parameter are not susceptible to the attack. However, all confirmation forms built using Drupal 7's form API are vulnerable via the Cancel action that appears at the bottom of the form, and some Drupal 6 confirmation forms are vulnerable too.

CVE identifier(s) issued
  • Access bypass via password reset URLs: CVE-2015-2559
  • Open redirect via the "destination" URL parameter: CVE-2015-2749
  • Open redirect via URL-related API functions: CVE-2015-2750
Versions affected
  • Drupal core 6.x versions prior to 6.35
  • Drupal core 7.x versions prior to 7.35
Solution

Install the latest version:

Also see the Drupal core project page.

Reported by

Access bypass via password reset URLs:

Open redirect via vectors including the "destination" URL parameter:

Fixed by

Access bypass via password reset URLs:

Open redirect via vectors including the "destination" URL parameter:

Coordinated by Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal Core - Moderately Critical - Multiple Vulnerabilities - SA-CORE-2014-006

Wed, 11/19/2014 - 1:21pm
Description Session hijacking (Drupal 6 and 7)

A specially crafted request can give a user access to another user's session, allowing an attacker to hijack a random session.

This attack is known to be possible on certain Drupal 7 sites which serve both HTTP and HTTPS content ("mixed-mode"), but it is possible there are other attack vectors for both Drupal 6 and Drupal 7.

Denial of service (Drupal 7 only)

Drupal 7 includes a password hashing API to ensure that user supplied passwords are not stored in plain text.

A vulnerability in this API allows an attacker to send specially crafted requests resulting in CPU and memory exhaustion. This may lead to the site becoming unavailable or unresponsive (denial of service).

This vulnerability can be exploited by anonymous users.

CVE identifier(s) issued
  • Session hijacking (Drupal 6 and 7): CVE-2014-9015
  • Denial of service (Drupal 7): CVE-2014-9016
Versions affected
  • Drupal core 6.x versions prior to 6.34.
  • Drupal core 7.x versions prior to 7.34.
Solution

Install the latest version:

If you have configured a custom session.inc file for your Drupal 6 or Drupal 7 site you also need to make sure that it is not prone to the same session hijacking vulnerability disclosed in this security advisory.

If you have configured a custom password.inc file for your Drupal 7 site you also need to make sure that it is not prone to the same denial of service vulnerability disclosed in this security advisory. See also the similar security advisory for the Drupal 6 contributed Secure Password Hashes module: SA-CONTRIB-2014-113

Also see the Drupal core project page.

Reported by

Session hijacking:

Denial of service:

Fixed by

Session hijacking:

Denial of service:

Coordinated by
  • The Drupal Security Team
Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Edits to this advisory since publishing
  • Edited to mention the effect on sites that have configured a custom session.inc file.
Drupal version: Drupal 6.xDrupal 7.x

SA-CORE-2014-005 - Drupal core - SQL injection

Wed, 10/15/2014 - 12:02pm
Description

Drupal 7 includes a database abstraction API to ensure that queries executed against the database are sanitized to prevent SQL injection attacks.

A vulnerability in this API allows an attacker to send specially crafted requests resulting in arbitrary SQL execution. Depending on the content of the requests this can lead to privilege escalation, arbitrary PHP execution, or other attacks.

This vulnerability can be exploited by anonymous users.

Update: Multiple exploits have been reported in the wild following the release of this security advisory, and Drupal 7 sites which did not update soon after the advisory was released may be compromised. See this follow-up announcement for more information: https://www.drupal.org/PSA-2014-003

CVE identifier(s) issued

  • CVE-2014-3704
Versions affected
  • Drupal core 7.x versions prior to 7.32.
Solution

Install the latest version:

If you are unable to update to Drupal 7.32 you can apply this patch to Drupal's database.inc file to fix the vulnerability until such time as you are able to completely upgrade to Drupal 7.32.

Also see the Drupal core project page and the follow-up public service announcement.

Reported by
  • Stefan Horst
Fixed by Coordinated by Contact and More Information

We've prepared a FAQ on this release. Read more at https://www.drupal.org/node/2357241.

The Drupal security team can be reached at security at drupal.org or via the contact form at
https://www.drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Edits to this advisory since publishing
  • Updated risk factor from 20/25 to 25/25 once exploits did appear
  • Edited to add link to PSA.
Drupal version: Drupal 7.x

SA-CORE-2014-004 - Drupal core - Denial of service

Wed, 08/06/2014 - 1:41pm
Description

Drupal 6 and Drupal 7 include an XML-RPC endpoint which is publicly available (xmlrpc.php). The PHP XML parser used by this XML-RPC endpoint is vulnerable to an XML entity expansion attack and other related XML payload attacks which can cause CPU and memory exhaustion and the site's database to reach the maximum number of open connections. Any of these may lead to the site becoming unavailable or unresponsive (denial of service).

All Drupal sites are vulnerable to this attack whether XML-RPC is used or not.

In addition, a similar vulnerability exists in the core OpenID module (for sites that have this module enabled).

This is a joint release as the XML-RPC vulnerability also affects WordPress (see the announcement).

CVE identifier(s) issued
  • CVE-2014-5265 has been issued for the code changes in xmlrpc.inc which prevent entity declarations and therefore address the "vulnerable to an XML entity expansion attack ... can cause CPU and memory exhaustion" concern.
  • CVE-2014-5266 has been issued for the "Skip parsing if there is an unreasonably large number of tags" in both xmlrpc.inc and xrds.inc.
  • CVE-2014-5267 has been issued for the code change to reject any XRDS document with a /<!DOCTYPE/i match.
Versions affected
  • Drupal core 7.x versions prior to 7.31.
  • Drupal core 6.x versions prior to 6.33.
Solution

Install the latest version:

If you are unable to install the latest version of Drupal immediately, you can alternatively remove the xmlrpc.php file from the root of Drupal core (or add a rule to .htaccess to prevent access to xmlrpc.php) and disable the OpenID module. These steps are sufficient to mitigate the vulnerability in Drupal core if your site does not require the use of XML-RPC or OpenID functionality. However, this mitigation will not be effective if you are using a contributed module that exposes Drupal's XML-RPC API at a different URL (for example, the Services module); updating Drupal core is therefore strongly recommended.

Also see the Drupal core project page.

Reported by Fixed by Coordinated by Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at http://drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Drupal version: Drupal 6.xDrupal 7.x

SA-CORE-2014-003 - Drupal core - Multiple vulnerabilities

Wed, 07/16/2014 - 10:48am
  • Advisory ID: DRUPAL-SA-CORE-2014-003
  • Project: Drupal core
  • Version: 6.x, 7.x
  • Date: 2014-July-16
  • Security risk: Critical
  • Exploitable from: Remote
  • Vulnerability: Multiple vulnerabilities
Description

Multiple vulnerabilities were fixed in the supported Drupal core versions 6 and 7.

Denial of service with malicious HTTP Host header (Base system - Drupal 6 and 7 - Critical)

Drupal core's multisite feature dynamically determines which configuration file to use based on the HTTP Host header.

The HTTP Host header validation does not sufficiently check maliciously-crafted header values, thereby exposing a denial of service vulnerability. This vulnerability also affects sites that don't actually use the multisite feature.

Access bypass (File module - Drupal 7 - Critical)

The File module included in Drupal 7 core allows attaching files to pieces of content. The module doesn't sufficiently check permission to view the attached file when attaching a file that was previously uploaded. This could allow attackers to gain access to private files.

This vulnerability is mitigated by the fact that the attacker must have permission to create or edit content with a file field.

Note: The Drupal 6 FileField module is affected by a similar issue (see SA-CONTRIB-2014-071 - FileField - Access bypass) and requires an update to the current security release of Drupal 6 core in order for the fix released there to work correctly. However, Drupal 6 core itself is not directly affected.

Cross-site scripting (Form API option groups - Drupal 6 and 7 - Moderately critical)

A cross-site scripting vulnerability was found due to Drupal's form API failing to sanitize option group labels in select elements. This vulnerability affects Drupal 6 core directly, and likely affects Drupal 7 forms provided by contributed or custom modules.

This vulnerability is mitigated by the fact that it requires the "administer taxonomy" permission to exploit in Drupal 6 core, and there is no known exploit within Drupal 7 core itself.

Cross-site scripting (Ajax system - Drupal 7 - Moderately critical)

A reflected cross-site scripting vulnerability was found in certain forms containing a combination of an Ajax-enabled textfield (for example, an autocomplete field) and a file field.

This vulnerability is mitigated by the fact that an attacker can only trigger the attack in a limited set of circumstances, usually requiring custom or contributed modules.

CVE identifier(s) issued
  • Denial of service (Base system - Drupal 6 and 7 - Critical): CVE-2014-5019
  • Access bypass (File module - Drupal 7 - Critical): CVE-2014-5020
  • Cross-site scripting (Form API - Drupal 6 and 7 - Moderately critical): CVE-2014-5021
  • Cross-site scripting (Ajax system - Drupal 7 - Moderately critical): CVE-2014-5022
Versions affected
  • Drupal core 6.x versions prior to 6.32.
  • Drupal core 7.x versions prior to 7.29.
Solution

Install the latest version:

Also see the Drupal core project page.

Reported by
  • The denial of service vulnerability using malicious HTTP Host headers was reported by Régis Leroy.
  • The access bypass vulnerability in the File module was reported by Ivan Ch.
  • The cross-site scripting vulnerability with Form API option groups was reported by Károly Négyesi.
  • The cross-site scripting vulnerability in the Ajax system was reported by mani22test.
Fixed by
  • The denial of service vulnerability using malicious HTTP Host headers was fixed by Régis Leroy, and by Klaus Purer of the Drupal Security Team.
  • The access bypass vulnerability in the File module was fixed by Nate Haug and Ivan Ch, and by Drupal Security Team members David Rothstein, Heine Deelstra and David Snopek.
  • The cross-site scripting vulnerability with Form API option groups was fixed by Greg Knaddison of the Drupal Security Team.
  • The cross-site scripting vulnerability in the Ajax system was fixed by Neil Drumm of the Drupal Security Team.
Coordinated by Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at http://drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal version: Drupal 6.xDrupal 7.x

SA-CORE-2014-002 - Drupal core - Information Disclosure

Wed, 04/16/2014 - 3:50pm
  • Advisory ID: DRUPAL-SA-CORE-2014-002
  • Project: Drupal core
  • Version: 6.x, 7.x
  • Date: 2014-April-16
  • Security risk: Moderately critical
  • Exploitable from: Remote
  • Vulnerability: Information Disclosure
Description

Drupal's form API has built-in support for temporary storage of form state, for example user input. This is often used on multi-step forms, and is required on Ajax-enabled forms in order to allow the Ajax calls to access and update interim user input on the server.

When pages are cached for anonymous users (either by Drupal or by an external system), form state may leak between anonymous users. As a consequence there is a chance that interim form input recorded for one anonymous user (which may include sensitive or private information, depending on the nature of the form) will be disclosed to other users interacting with the same form at the same time. This especially affects multi-step Ajax forms because the window of opportunity (i.e. the time span between user input and final form submission) is indeterminable.

This vulnerability is mitigated by the fact that Drupal core does not expose any such forms to anonymous users by default. However, contributed modules or individual sites which leverage the Drupal Form API under the aforementioned conditions might be vulnerable.

Note: This security release introduces small API changes which may require code updates on sites that expose Ajax or multi-step forms to anonymous users, and where the forms are displayed on pages that are cached (either by Drupal or by an external system). See the Drupal 6.31 release notes and Drupal 7.27 release notes for more information.

CVE identifier(s) issued
  • CVE-2014-2983
Versions affected
  • Drupal core 6.x versions prior to 6.31.
  • Drupal core 7.x versions prior to 7.27.
Solution

Install the latest version:

Also see the Drupal core project page.

Reported by Fixed by Coordinated by Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at http://drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal version: Drupal 6.xDrupal 7.x

SA-CORE-2014-001 - Drupal core - Multiple vulnerabilities

Wed, 01/15/2014 - 2:33pm
  • Advisory ID: DRUPAL-SA-CORE-2014-001
  • Project: Drupal core
  • Version: 6.x, 7.x
  • Date: 2014-January-15
  • Security risk: Highly critical
  • Exploitable from: Remote
  • Vulnerability: Multiple vulnerabilities
Description

Multiple vulnerabilities were fixed in the supported Drupal core versions 6 and 7.

Impersonation (OpenID module - Drupal 6 and 7 - Highly critical)

A vulnerability was found in the OpenID module that allows a malicious user to log in as other users on the site, including administrators, and hijack their accounts.

This vulnerability is mitigated by the fact that the malicious user must have an account on the site (or be able to create one), and the victim must have an account with one or more associated OpenID identities.

Access bypass (Taxonomy module - Drupal 7 - Moderately critical)

The Taxonomy module provides various listing pages which display content tagged with a particular taxonomy term. Custom or contributed modules may also provide similar lists. Under certain circumstances, unpublished content can appear on these pages and will be visible to users who should not have permission to see it.

This vulnerability is mitigated by the fact that it only occurs on Drupal 7 sites which upgraded from Drupal 6 or earlier.

Security hardening (Form API - Drupal 7 - Not critical)

The form API provides a method for developers to submit forms programmatically using the function drupal_form_submit(). During programmatic form submissions, all access checks are deliberately bypassed, and any form element may be submitted regardless of the current user's access level.

This is normal and expected behavior for most uses of programmatic form submissions; however, there are cases where custom or contributed code may need to send data provided by the current (untrusted) user to drupal_form_submit() and therefore need to respect access control on the form.

To facilitate this, a new, optional $form_state['programmed_bypass_access_check'] element has been added to the Drupal 7 form API. If this is provided and set to FALSE, drupal_form_submit() will perform the normal form access checks against the current user while submitting the form, rather than bypassing them.

This change does not fix a security issue in Drupal core itself, but rather provides a method for custom or contributed code to fix security issues that would be difficult or impossible to fix otherwise.

CVE identifier(s) issued
  • Impersonation (OpenID module - Drupal 6 and 7 - Highly critical): CVE-2014-1475
  • Access bypass (Taxonomy module - Drupal 7 - Moderately critical): CVE-2014-1476
  • Security hardening (Form API - Drupal 7 - Not critical): No CVE necessary.
Versions affected
  • Drupal core 6.x versions prior to 6.30.
  • Drupal core 7.x versions prior to 7.26.
Solution

Install the latest version:

Also see the Drupal core project page.

Reported by
  • The OpenID module impersonation issue was reported by Christian Mainka and Vladislav Mladenov.
  • The Taxonomy module access bypass issue was reported by Matt Vance, and by Damien Tournoud of the Drupal Security Team.
  • The form API access bypass issue was reported by David Rothstein of the Drupal Security Team.
Fixed by Coordinated by Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at http://drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Follow the Drupal Security Team on Twitter at https://twitter.com/drupalsecurity

Drupal version: Drupal 6.xDrupal 7.x

SA-CORE-2013-003 - Drupal core - Multiple vulnerabilities

Wed, 11/20/2013 - 3:41pm
  • Advisory ID: DRUPAL-SA-CORE-2013-003
  • Project: Drupal core
  • Version: 6.x, 7.x
  • Date: 2013-November-20
  • Security risk: Highly critical
  • Exploitable from: Remote
  • Vulnerability: Multiple vulnerabilities
Description

Multiple vulnerabilities were fixed in the supported Drupal core versions 6 and 7.

Multiple vulnerabilities due to optimistic cross-site request forgery protection (Form API validation - Drupal 6 and 7)

Drupal's form API has built-in cross-site request forgery (CSRF) validation, and also allows any module to perform its own validation on the form. In certain common cases, form validation functions may execute unsafe operations. Given that the CSRF protection is an especially important validation, the Drupal core form API has been changed in this release so that it now skips subsequent validation if the CSRF validation fails.

This vulnerability is mitigated by the fact that a form validation callback with potentially unsafe side effects must be active on the site, and none exist in core. However, issues were discovered in several popular contributed modules which allowed remote code execution that made it worthwhile to fix this issue in core. Other similar issues with varying impacts are likely to have existed in other contributed modules and custom modules and therefore will also be fixed by this Drupal core release.

Multiple vulnerabilities due to weakness in pseudorandom number generation using mt_rand() (Form API, OpenID and random password generation - Drupal 6 and 7)

Drupal core directly used the mt_rand() pseudorandom number generator for generating security related strings used in several core modules. It was found that brute force tools could determine the seeds making these strings predictable under certain circumstances.

This vulnerability has no mitigation; all Drupal sites are affected until the security update has been applied.

Code execution prevention (Files directory .htaccess for Apache - Drupal 6 and 7)

Drupal core attempts to add a "defense in depth" protection to prevent script execution by placing a .htaccess file into the files directories that stops execution of PHP scripts on the Apache web server. This protection is only necessary if there is a vulnerability on the site or on a server that allows users to upload malicious files. The configuration in the .htaccess file did not prevent code execution on certain Apache web server configurations. This release includes new configuration to prevent PHP execution on several additional common Apache configurations. If you are upgrading a site and the site is run by Apache you must fix the file manually, as described in the "Solution" section below.

This vulnerability is mitigated by the fact that it only relates to a defense in depth mechanism, and sites would only be vulnerable if they are hosted on a server which contains code that does not use protections similar to those found in Drupal's file API to manage uploads in a safe manner.

Access bypass (Security token validation - Drupal 6 and 7)

The function drupal_valid_token() can return TRUE for invalid tokens if the caller does not make sure that the token is a string.

This vulnerability is mitigated by the fact that a contributed or custom module must invoke drupal_validate_token() with an argument that can be manipulated to not be a string by an attacker. There is currently no known core or contributed module that would suffer from this vulnerability.

Cross-site scripting (Image module - Drupal 7)

Image field descriptions are not properly sanitized before they are printed to HTML, thereby exposing a cross-site scripting vulnerability.

This vulnerability is mitigated by the fact that an attacker must have a permission to administer field descriptions, for example the "administer taxonomy" permission to edit fields on taxonomy terms.

Cross-site scripting (Color module - Drupal 7)

A cross-site scripting vulnerability was found in the Color module. A malicious attacker could trick an authenticated administrative user into visiting a page containing specific JavaScript that could lead to a reflected cross-site scripting attack via JavaScript execution in CSS.

This vulnerability is mitigated by the fact that it can only take place in older browsers, and in a restricted set of modern browsers, namely Opera through user interaction, and Internet Explorer under certain conditions.

Open redirect (Overlay module - Drupal 7)

The Overlay module displays administrative pages as a layer over the current page (using JavaScript), rather than replacing the page in the browser window. The Overlay module did not sufficiently validate URLs prior to displaying their contents, leading to an open redirect vulnerability.

This vulnerability is mitigated by the fact that it can only be used against site users who have the "Access the administrative overlay" permission.

CVE identifier(s) issued
  • Multiple vulnerabilities due to optimistic cross-site request forgery protection (Form API validation): CVE-2013-6385
  • Multiple vulnerabilities due to weakness in pseudorandom number generation using mt_rand() (Form API, OpenID and random password generation - Drupal 6 and 7): CVE-2013-6386
  • Code execution prevention (Files directory .htaccess for Apache - Drupal 6 and 7): No CVE; considered remediated through "security hardening"
  • Access bypass (Security token validation - Drupal 6 and 7): No CVE; considered remediated through "security hardening."
  • Cross-site scripting (Image module - Drupal 7): CVE-2013-6387
  • Cross-site scripting (Color module - Drupal 7): CVE-2013-6388
  • Open redirect (Overlay module - Drupal 7): CVE-2013-6389
Versions affected
  • Drupal core 6.x versions prior to 6.29.
  • Drupal core 7.x versions prior to 7.24.
Solution

Install the latest version:

Also see the Drupal core project page.

Warning: Fixing the code execution prevention may require server configuration; please read:

To fix the code execution prevention vulnerability on existing Apache installations also requires changes to your site's .htaccess files in the files directories. Until you do this, your site's status report page at admin/reports/status will display error messages about the problem. Please note that if you are using a different web server such as Nginx the .htaccess files have no effect and you need to configure PHP execution protection yourself in the respective server configuration files.

To fix this issue, you must edit or replace the old .htaccess files manually. Copies of the .htaccess files are found in the site's files directory and temporary files directory, and (for Drupal 7 only) the separate private files directory if your site is configured to use one. To find the location of these directories, consult the error messages at admin/reports/status, or visit the file system configuration page at admin/settings/file-system (Drupal 6) or admin/config/media/file-system (Drupal 7). Note that you should only make changes to the .htaccess files that are found in the directories specified on that page. Do not change the top-level .htaccess file (at the root of your Drupal installation).

Go onto your server, navigate to each directory, and replace or create the .htaccess file in this directory with the contents described below. Alternatively, you can remove the .htaccess file from each directory using SFTP or SSH and then visit the file system configuration page (admin/settings/file-system in Drupal 6 or admin/config/media/file-system in Drupal 7) and click the save button to have Drupal create the file automatically.

The recommended .htaccess file contents are as follows.

For Drupal 6:

# Turn off all options we don't need.
Options None
Options +FollowSymLinks

# Set the catch-all handler to prevent scripts from being executed.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
<Files *>
  # Override the handler again if we're run later in the evaluation list.
  SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
</Files>

# If we know how to do it safely, disable the PHP engine entirely.
<IfModule mod_php5.c>
  php_flag engine off
</IfModule>
# PHP 4, Apache 1.
<IfModule mod_php4.c>
  php_flag engine off
</IfModule>
# PHP 4, Apache 2.
<IfModule sapi_apache2.c>
  php_flag engine off
</IfModule>

For Drupal 7:

# Turn off all options we don't need.
Options None
Options +FollowSymLinks

# Set the catch-all handler to prevent scripts from being executed.
SetHandler Drupal_Security_Do_Not_Remove_See_SA_2006_006
<Files *>
  # Override the handler again if we're run later in the evaluation list.
  SetHandler Drupal_Security_Do_Not_Remove_See_SA_2013_003
</Files>

# If we know how to do it safely, disable the PHP engine entirely.
<IfModule mod_php5.c>
  php_flag engine off
</IfModule>

Additionally, the .htaccess of the temporary files directory and private files directory (if used) should include this command:

Deny from all Reported by Fixed by Coordinated by Contact and More Information

The Drupal security team can be reached at security at drupal.org or via the contact form at http://drupal.org/contact.

Learn more about the Drupal Security team and their policies, writing secure code for Drupal, and securing your site.

Drupal version: Drupal 6.xDrupal 7.x

Pages