Sep 04 2019
Sep 04

Vulnerability: 

Various 3rd Party Vulnerabilities

Description: 

In June of 2011, the Drupal Security Team issued Public Service Advisory PSA-2011-002 - External libraries and plugins.

8 years later that is still the policy of the Drupal Security team. As Drupal core and modules leverage 3rd party code more and more it seems like an important time to remind site owners that they are responsible for monitoring security of 3rd party libraries. Here is the advice from 2011 which is even more relevant today:

Just like there's a need to diligently follow announcements and update contributed modules downloaded from Drupal.org, there's also a need to follow announcements by vendors of third-party libraries or plugins that are required by such modules.

Drupal's update module has no functionality to alert you to these announcements. The Drupal security team will not release announcements about security issues in external libraries and plugins.

Current PHPUnit/Mailchimp library exploit

Recently we have become aware of a vulnerability that is being actively exploited on some Drupal sites. The vulnerability is in PHPUnit and has a CVE# CVE-2017-9841. The exploit targets Drupal sites that currently or previously used the Mailchimp or Mailchimp commerce module and still have a vulnerable version of the file sites/all/libraries/mailchimp/vendor/phpunit/phpunit/src/Util/PHP/eval-stdin.php. See below for details on whether a file is vulnerable or not. The vulnerable file might be at other paths on your individual site, but an automated attack exists that is looking for that specific path. This attack can execute PHP on the server.

Solution: 

Follow release announcements by the vendors of the external libraries and plugins you use.

In this specific case, check for the existence of a file named eval-stdin.php and check its contents. If they match the new version in this commit then it is safe. If the file reads from php://input then the codebase is vulnerable. This is not an indication of a site being compromised, just of it being vulnerable. To fix this vulnerability, update your libraries. In particular you should ensure the Mailchimp and Mailchimp Ecommerce modules and their libraries are updated.

If you discover your site has been compromised, we have a guide of how to remediate a compromised site.

Also see the Drupal core project page.

Jul 17 2019
Jul 17

Description: 

In Drupal 8.7.4, when the experimental Workspaces module is enabled, an access bypass condition is created.

This can be mitigated by disabling the Workspaces module. It does not affect any release other than Drupal 8.7.4.

Drupal 8.7.3 and earlier, Drupal 8.6.x and earlier, and Drupal 7.x are not affected.

Solution: 

If the site is running Drupal 8.7.4, upgrade to Drupal 8.7.5.

Note, manual step needed. For sites with the Workspaces module enabled, update.php needs to run to ensure a required cache clear. If there is a reverse proxy cache or content delivery network (e.g. Varnish, CloudFlare) it is also advisable to clear these as well.

May 08 2019
May 08

Description: 

This security release fixes third-party dependencies included in or required by Drupal core. As described in TYPO3-PSA-2019-007: By-passing protection of Phar Stream Wrapper Interceptor:

In order to intercept file invocations like file_exists or stat on compromised Phar archives the base name has to be determined and checked before allowing to be handled by PHP Phar stream handling. [...]

The current implementation is vulnerable to path traversal leading to scenarios where the Phar archive to be assessed is not the actual (compromised) file.

The known vulnerability in Drupal core requires the "administer themes" permission. However, additional vulnerabilities may exist in contributed or custom modules, so site should still update even if they do not grant this permission.

Solution: 

Install the latest version:

Versions of Drupal 8 prior to 8.6.x are end-of-life and do not receive security coverage.

Also see the Drupal core project page.

May 07 2019
May 07

Vulnerability: 

Drupal 7 and 8 release on May 8th, 2019

Description: 

The Drupal Security Team will be coordinating a security release for Drupal 7 and 8 this week on Wednesday, May 8th, 2019.

We are issuing this PSA in advance because according to the regular security release window schedule, May 8th would not typically be a core security window.

This release is rated as moderately critical.

The Drupal 7 and 8 core release will be made between 16:00 – 21:00 UTC (noon – 5:00pm Eastern).

May 8th also remains a normal security release window for contributed projects.

Apr 17 2019
Apr 17

Description: 

The jQuery project released version 3.4.0, and as part of that, disclosed a security vulnerability that affects all prior versions. As described in their release notes:

jQuery 3.4.0 includes a fix for some unintended behavior when using jQuery.extend(true, {}, ...). If an unsanitized source object contained an enumerable __proto__ property, it could extend the native Object.prototype. This fix is included in jQuery 3.4.0, but patch diffs exist to patch previous jQuery versions.

It's possible that this vulnerability is exploitable with some Drupal modules. As a precaution, this Drupal security release backports the fix to jQuery.extend(), without making any other changes to the jQuery version that is included in Drupal core (3.2.1 for Drupal 8 and 1.4.4 for Drupal 7) or running on the site via some other module such as jQuery Update.

2019-04-22, edited to add CVE.

Solution: 

Install the latest version:

Versions of Drupal 8 prior to 8.5.x are end-of-life and do not receive security coverage.

Also see the Drupal core project page.

Additional information

All advisories released today:

Updating to the latest Drupal core release will apply the fixes for all the above advisories.

Apr 17 2019
Apr 17

Description: 

This security release fixes third-party dependencies included in or required by Drupal core.

  • CVE-2019-10909: Escape validation messages in the PHP templating engine. From that advisory:

    Validation messages were not escaped when using the form theme of the PHP templating engine which, when validation messages may contain user input, could result in an XSS.

  • CVE-2019-10910: Check service IDs are valid. From that advisory:

    Service IDs derived from unfiltered user input could result in the execution of any arbitrary code, resulting in possible remote code execution.

  • CVE-2019-10911: Add a separator in the remember me cookie hash. From that advisory:

    This fixes situations where part of an expiry time in a cookie could be considered part of the username, or part of the username could be considered part of the expiry time. An attacker could modify the remember me cookie and authenticate as a different user. This attack is only possible if remember me functionality is enabled and the two users share a password hash or the password hashes (e.g. UserInterface::getPassword()) are null for all users (which is valid if passwords are checked by an external system, e.g. an SSO).

Solution: 

Install the latest version:

Versions of Drupal 8 prior to 8.5.x are end-of-life and do not receive security coverage.

Also see the Drupal core project page.

Additional information

All advisories released today:

Updating to the latest Drupal core release will apply the fixes for all the above advisories.

Mar 20 2019
Mar 20

Description: 

Under certain circumstances the File module/subsystem allows a malicious user to upload a file that can trigger a cross-site scripting (XSS) vulnerability.

Solution: 

Versions of Drupal 8 prior to 8.5.x are end-of-life and do not receive security coverage.

Feb 25 2019
Feb 25

Drupal 7 was first released in January 2011. In November 2021, after over a decade, Drupal 7 will reach end of life (EOL). (More information on why this date was chosen.) Official community support for version 7 will end, along with support provided by the Drupal Association on Drupal.org. This means that automated testing services for Drupal 7 will be shut down, and there will be no more updates provided by the Drupal Security Team.

When this occurs, Drupal 7 will be marked end-of-life in the update manager, which appears in the Drupal administrative interface. Updates, security fixes, and enhancements will no longer be provided by the community, but may be available on a limited basis from select commercial vendors.

If you have a site that is running on Drupal 7, now is the time to start planning the upgrade. Note that the transition from Drupal 8 to Drupal 9 will not be the significant effort that the transition from 7 to 8 was. In fact, the first release of Drupal 9 will be identical to the last release of Drupal 8, except with deprecated code removed and dependencies updated to newer versions. (See Plan for Drupal 9 for more information on Drupal 9.)

What this means for your Drupal 7 sites is, as of November 2021:

  • Drupal 7 will no longer be supported by the community at large. The community at large will no longer create new projects, fix bugs in existing projects, write documentation, etc. around Drupal 7.
  • There will be no more core commits to Drupal 7.
  • The Drupal Security Team will no longer provide support or Security Advisories for Drupal 7 core or contributed modules, themes, or other projects. Reports about Drupal 7 vulnerabilities might become public creating 0 day exploits.
  • All Drupal 7 releases on all project pages will be flagged as not supported. Maintainers can change that flag if they desire to.
  • On Drupal 7 sites with the update status module, Drupal Core will show up as unsupported.
  • After November 2021, using Drupal 7 may be flagged as insecure in 3rd party scans as it no longer gets support.
  • Best practice is to not use unsupported software, it would not be advisable to continue to build new Drupal 7 sites.
  • Now is the time to start planning your migration to Drupal 8.

If, for any reason, you are unable to migrate to Drupal 8 or 9 by the time version 7 reaches end of life, there will be a select number of organizations that will provide Drupal 7 Vendor Extended Support (D7ES) for their paying clients. This program is the successor to the successful Drupal 6 LTS program. Like that program, it will be an additional paid service, fully operated by these organizations with some help from the Security Team.

The Drupal Association and Drupal Security Team will publish an announcement once we have selected the Drupal 7 Vendor Extended Support partners.

If you would like more information about the Drupal release cycle, consult the official documentation on Drupal.org. If you would like more information about the upcoming release of Drupal 9, join us at DrupalCon Seattle.

Information for organizations interested in providing commercial Drupal 7 Vendor Extended Support

Organizations interested in providing commercial Drupal 7 Vendor Extended Support to their customers and who have the technical knowledge to maintain Drupal 7 are invited to fill out the
application for the Drupal 7 Vendor Extended Support team. The application submission should explain why the vendor is a good fit for the program, and explain how they meet the requirements as outlined below.

Base requirements for this program include:

  1. We will confirm that each vendor meets the requirements outlined above and is a good fit for the program.
  2. If the Security Working Group does not think you are a good fit, we will explain why and decline your application. If you are rejected, you are able to reapply. Most rejections will be due to Organizations not having enough ongoing contribution to Drupal 7 and Organizations not having a Drupal Security Team member at their organization.
  3. The Drupal Association signs off on your participation in the program.
  4. If you are accepted, you will be added to the Drupal 7 Vendor Extended Support vendor mailing list.
  5. The Security Working Group will do a coordinated announcement with the vendors to promote the program.

If you have any questions you can email [email protected]

Feb 23 2019
Feb 23

Vulnerability: 

SA-CORE-2019-003 Notice of increased risk and Additional exploit path

Description: 

This Public Service Announcement is a follow-up to SA-CORE-2019-003. This is not an announcement of a new vulnerability. If you have not updated your site as described in SA-CORE-2019-003 you should do that now.

There are public exploits now available for this SA.

Update, February 25: Mass exploits are now being reported in the wild.

In the original SA we indicated this could be mitigated by blocking POST, PATCH and PUT requests to web services resources, there is now a new way to exploit this using GET requests.

The best mitigation is:

This only applies to your site if:

  • The site has the Drupal 8 core RESTful Web Services (rest) module enabled.
  • OR

  • The site has another web services module enabled, like JSON:API in Drupal 8, or Services or RESTful Web Services in Drupal 7, or custom code that allows entity updates via non-form sources.

What to do if your site may be compromised

Take a look at our existing documentation, ”Your Drupal site got hacked, now what”.
We’ll continue to update the SA if novel types of exploit appear.

Feb 20 2019
Feb 20

Description: 

Some field types do not properly sanitize data from non-form sources. This can lead to arbitrary PHP code execution in some cases.

A site is only affected by this if one of the following conditions is met:

  • The site has the Drupal 8 core RESTful Web Services (rest) module enabled and allows GET, PATCH or POST requests, or
  • the site has another web services module enabled, like JSON:API in Drupal 8, or Services or RESTful Web Services in Drupal 7.

(Note: The Drupal 7 Services module itself does not require an update at this time, but you should still apply other contributed updates associated with this advisory if Services is in use.)

Updates

  • 2019-02-22: Updated risk score given new information; see PSA-2019-02-22. The security risk score has been updated to 23/25 as there are now known exploits in the wild. In addition, any enabled REST resource end-point, even if it only accepts GET requests, is also vulnerable. Note this does not include REST exports from Views module.

Solution: 

Versions of Drupal 8 prior to 8.5.x are end-of-life and do not receive security coverage.

To immediately mitigate the vulnerability, you can disable all web services modules, or configure your web server(s) to not allow GET/PUT/PATCH/POST requests to web services resources. Note that web services resources may be available on multiple paths depending on the configuration of your server(s). For Drupal 7, resources are for example typically available via paths (clean URLs) and via arguments to the "q" query argument. For Drupal 8, paths may still function when prefixed with index.php/.

Feb 19 2019
Feb 19

Description: 

There will be a security release of 8.5.x and 8.6.x on February 20th 2019 between 1PM to 5PM America/New York (1800 to 2200 UTC). (To see this in your local timezone, refer to the Drupal Core Calendar) . The risk on this is currently rated at 20/25 (Highly critical) AC:None/A:None/CI:All/II:All/E:Theoretical/TD:Uncommon.

Not all configurations are affected. Reserve time on February 20 during the release window to determine whether your sites are affected and in need of an immediate update. Mitigation information will be included in the advisory.

Contributed module security updates may also be required.

If you are running Drupal 7, no core update is required, but you may need to update contributed modules if you are using an affected module. We are unable to provide the list of those modules at this time.

Neither the Security Team nor any other party is able to release any more information about this vulnerability until the announcement is made. The announcement will be made public at https://www.drupal.org/security, over Twitter, and in email for those who have subscribed to our email list. To subscribe to the email list: log in on Drupal.org, go to your user profile page and subscribe to the security newsletter on the Edit » My newsletters tab.

Security release announcements will appear on the Drupal.org security advisory page.

Jan 16 2019
Jan 16

Vulnerability: 

Arbitrary PHP code execution

Description: 

A remote code execution vulnerability exists in PHP's built-in phar stream wrapper when performing file operations on an untrusted phar:// URI.

Some Drupal code (core, contrib, and custom) may be performing file operations on insufficiently validated user input, thereby being exposed to this vulnerability.

This vulnerability is mitigated by the fact that such code paths typically require access to an administrative permission or an atypical configuration.

Solution: 

  • If you are using Drupal 8.6.x, upgrade to Drupal 8.6.6.
  • If you are using Drupal 8.5.x or earlier, upgrade to Drupal 8.5.9.
  • If you are using Drupal 7.x, upgrade to Drupal 7.62.

Versions of Drupal 8 prior to 8.5.x are end-of-life and do not receive security coverage.

Known issues

This fix introduced a fatal error for some Drush installations when updating a site with Drush. New releases (8.6.7, 8.5.10, and 7.63) have been issued to resolve this regression. See the release notes for additional details.

Update information

.phar added to dangerous extensions list

The .phar file extension has been added to Drupal's dangerous extensions list, which means that any such file uploaded to a Drupal file field will automatically be converted to a text file (with the .txt extension) to prevent it from being executed. This is similar to how Drupal handles file uploads with a .php extension.

phar:// stream wrapper disabled by default for Drupal 7 sites on PHP 5.3.2 and earlier

The replacement stream wrapper is not compatible with PHP versions lower than 5.3.3. Drupal 8 requires a higher PHP version than that, but for Drupal 7 sites using lower PHP versions, the built-in phar stream wrapper has been disabled rather than replaced. Drupal 7 sites using PHP 5.2 (or PHP 5.3.0-5.3.2) that require phar support will need to re-enable the stream wrapper for it; however, note that re-enabling the stream wrapper will re-enable the insecure PHP behavior on those PHP versions.

It is very uncommon to both be running a PHP version lower than 5.3.3 and to need phar support. If you're in that situation, consider upgrading your PHP version instead of restoring insecure phar support.

Fixed By: 

Additional information

Note: Going forward, Drupal core will issue individual security advisories for separate vulnerabilities included in the release, rather than lumping "multiple vulnerabilities" into a single advisory. All advisories released today:

Updating to the latest Drupal core release will apply the fixes for all the above advisories.

Jan 16 2019
Jan 16

Description: 

Drupal core uses the third-party PEAR Archive_Tar library. This library has released a security update which impacts some Drupal configurations. Refer to CVE-2018-1000888 for details.

Solution: 

  • If you are using Drupal 8.6.x, upgrade to Drupal 8.6.6.
  • If you are using Drupal 8.5.x or earlier, upgrade to Drupal 8.5.9.
  • If you are using Drupal 7.x, upgrade to Drupal 7.62.

Versions of Drupal 8 prior to 8.5.x are end-of-life and do not receive security coverage.

Fixed By: 

Known issues

Users are reporting seeing a fatal error when updating their sites with Drush. Site owners may be able to run drush updb and either drush cc all or drush cr depending on the version to complete the update. Check the status report afterward to confirm that Drupal has been updated. See https://www.drupal.org/project/drupal/issues/3026386 for details.

Additional information

Note: Going forward, Drupal core will issue individual security advisories for separate vulnerabilities included in the release, rather than lumping "multiple vulnerabilities" into a single advisory. All advisories released today:

Updating to the latest Drupal core release will apply the fixes for all the above advisories.

Oct 17 2018
Oct 17
  • Advisory ID: DRUPAL-SA-CORE-2018-006
  • Project: Drupal core
  • Version: 7.x, 8.x
  • Date: 2018-October-17

Description

Content moderation - Moderately critical - Access bypass - Drupal 8

In some conditions, content moderation fails to check a users access to use certain transitions, leading to an access bypass.

In order to fix this issue, the following changes have been made to content moderation which may have implications for backwards compatibility:

ModerationStateConstraintValidator Two additional services have been injected into this service. Anyone subclassing this service must ensure these additional dependencies are passed to the constructor, if the constructor has been overridden. StateTransitionValidationInterface An additional method has been added to this interface. Implementations of this interface which do not extend the StateTransitionValidation should implement this method.

Implementations which do extend from the StateTransitionValidation should ensure any behavioural changes they have made are also reflected in this new method.

User permissions Previously users who didn't have access to use any content moderation transitions were granted implicit access to update content provided the state of the content did not change. Now access to an associated transition will be validated for all users in scenarios where the state of content does not change between revisions.

Reported by

Fixed by

External URL injection through URL aliases - Moderately Critical - Open Redirect - Drupal 7 and Drupal 8

The path module allows users with the 'administer paths' to create pretty URLs for content.

In certain circumstances the user can enter a particular path that triggers an open redirect to a malicious url.

The issue is mitigated by the fact that the user needs the administer paths permission to exploit.

Reported by

Fixed by

Anonymous Open Redirect - Moderately Critical - Open Redirect - Drupal 8

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.

This vulnerability has been publicly documented.

RedirectResponseSubscriber event handler removal

As part of the fix, \Drupal\Core\EventSubscriber\RedirectResponseSubscriber::sanitizeDestination has been removed, although this is a public function, it is not considered an API as per our API policy for event subscribers.
If you have extended that class or are calling that method, you should review your implementation in line with the changes in the patch. The existing function has been removed to prevent a false sense of security.

Reported by

Fixed by

Injection in DefaultMailSystem::mail() - Critical - Remote Code Execution - Drupal 7 and Drupal 8

When sending email some variables were not being sanitized for shell arguments, which could lead to remote code execution.

Reported by

Fixed by

Contextual Links validation - Critical - Remote Code Execution - Drupal 8

The Contextual Links module doesn't sufficiently validate the requested contextual links.
This vulnerability is mitigated by the fact that an attacker must have a role with the permission "access contextual links".

Reported by

Fixed by

Solution

Upgrade to the most recent version of Drupal 7 or 8 core.

Minor versions of Drupal 8 prior to 8.5.x are not supported and do not receive security coverage, so sites running older versions should update to the above 8.5.x release immediately. 8.5.x will receive security coverage until May 2019.

Aug 01 2018
Aug 01
  • Advisory ID: DRUPAL-SA-CORE-2018-005
  • Project: Drupal core
  • Version: 8.x
  • CVE: CVE-2018-14773
  • Date: 2018-August-01

Description

The Drupal project uses the Symfony library. The Symfony library has released a security update that impacts Drupal. Refer to the Symfony security advisory for the issue.

The same vulnerability also exists in the Zend Feed and Diactoros libraries included in Drupal core; however, Drupal core does not use the vulnerable functionality. If your site or module uses Zend Feed or Diactoros directly, read the Zend Framework security advisory and update or patch as needed.

The Drupal Security Team would like to to thank the Symfony and Zend Security teams for their collaboration on this issue.

Versions affected

8.x versions before 8.5.6.

Solution

Upgrade to Drupal 8.5.6.

Versions of Drupal 8 prior to 8.5.x are end-of-life and do not receive security coverage.

Reported 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

Jul 30 2018
Jul 30

The Drupal Security Team will be coordinating a security release for Drupal 8 this week on Wednesday, August 1, 2018. (We are issuing this PSA in advance because the in the regular security release window schedule, August 1 would not typically be a core security window.)

The Drupal 8 core release will be made between 16:00 – 21:00 UTC (noon – 5:00pm EDT). It is rated as moderately critical and will be an update to a vendor library only.

August 1 also remains a normal security release window for contributed projects.

Updates

  • 2018-07-31 — Made the time window consistent with the normal security release window.
  • 2018-08-01 — Added UTC times in addition it EDT.
Jun 07 2018
Jun 07

Various media outlets are reporting that a large number of Drupal sites are still vulnerable to the recent highly critical core vulnerabilities SA-CORE-2018-002 and SA-CORE-2018-004.

Those reports are all based on the same source. The source investigated the contents of CHANGELOG.txt of a large number of sites and assumed all sites reporting a version lower than 7.58 to be vulnerable.

Checking the contents of CHANGELOG.txt is not a valid way to determine whether a site is vulnerable to any given attack vector. Patches distributed by the Drupal security team to fix the issues were widely used, but did not touch CHANGELOG.txt or any version strings defined elsewhere. There are also other mitigations that vendors have provided which would also not affect CHANGELOG.txt but would protect the site.

We believe the presented numbers to be inaccurate. We consider it to be misleading to draw conclusions from this sparse information. The Drupal project has a long history of a reliable coordinated disclosure security program. For the past 4 years, the Drupal Security Team has provided support to journalists covering our releases and policies and is available for further enquiries.

If you are a member of the press and want the Drupal Security Team to comment, please contact [email protected].

Jun 07 2018
Jun 07

Various media outlets are reporting that a large number of Drupal sites are still vulnerable to the recent highly critical core vulnerabilities SA-CORE-2018-002 and SA-CORE-2018-004.

Those reports are all based on the same source. The source investigated the contents of CHANGELOG.txt of a large number of sites and assumed all sites reporting a version lower than 7.58 to be vulnerable.

Checking the contents of CHANGELOG.txt is not a valid way to determine whether a site is vulnerable to any given attack vector. Patches distributed by the Drupal security team to fix the issues were widely used, but did not touch CHANGELOG.txt or any version strings defined elsewhere. There are also other mitigations that vendors have provided which would also not affect CHANGELOG.txt but would protect the site.

We believe the presented numbers to be inaccurate. We consider it to be misleading to draw conclusions from this sparse information. The Drupal project has a long history of a reliable coordinated disclosure security program. For the past 4 years, the Drupal Security Team has provided support to journalists covering our releases and policies and is available for further enquiries.

If you are a member of the press and want the Drupal Security Team to comment, please contact [email protected].

Apr 25 2018
Apr 25

Description: 

A remote code execution vulnerability exists within multiple subsystems of Drupal 7.x and 8.x. This potentially allows attackers to exploit multiple attack vectors on a Drupal site, which could result in the site being compromised. This vulnerability is related to Drupal core - Highly critical - Remote Code Execution - SA-CORE-2018-002. Both SA-CORE-2018-002 and this vulnerability are being exploited in the wild.

Updated — this vulnerability is being exploited in the wild.

Solution: 

Upgrade to the most recent version of Drupal 7 or 8 core.

  • If you are running 7.x, upgrade to Drupal 7.59.
  • If you are running 8.5.x, upgrade to Drupal 8.5.3.
  • If you are running 8.4.x, upgrade to Drupal 8.4.8. (Drupal 8.4.x is no longer supported and we don't normally provide security releases for unsupported minor releases. However, we are providing this 8.4.x release so that sites can update as quickly as possible. You should update to 8.4.8 immediately, then update to 8.5.3 or the latest secure release as soon as possible.)

If you are unable to update immediately, or if you are running a Drupal distribution that does not yet include this security release, you can attempt to apply the patch below to fix the vulnerability until you are able to update completely:

These patches will only work if your site already has the fix from SA-CORE-2018-002 applied. (If your site does not have that fix, it may already be compromised.)

Apr 23 2018
Apr 23

There will be a security release of Drupal 7.x, 8.4.x, and 8.5.x on April 25th, 2018 between 16:00 - 18:00 UTC. This PSA is to notify that the Drupal core release is outside of the regular schedule of security releases. For all security updates, the Drupal Security Team urges you to reserve time for core updates at that time because there is some risk that exploits might be developed within hours or days. Security release announcements will appear on the Drupal.org security advisory page.

This security release is a follow-up to the one released as SA-CORE-2018-002 on March 28.

  • Sites on 7.x or 8.5.x can immediately update when the advisory is released using the normal procedure.
  • Sites on 8.4.x should immediately update to the 8.4.8 release that will be provided in the advisory, and then plan to update to 8.5.3 or the latest security release as soon as possible (since 8.4.x no longer receives official security coverage).

The security advisory will list the appropriate version numbers for each branch. Your site's update report page will recommend the 8.5.x release even if you are on 8.4.x or an older release, but temporarily updating to the provided backport for your site's current version will ensure you can update quickly without the possible side effects of a minor version update.

Patches for Drupal 7.x, 8.4.x, 8.5.x and 8.6.x will be provided in addition to the releases mentioned above. (If your site is on a Drupal 8 release older than 8.4.x, it no longer receives security coverage and will not receive a security update. The provided patches may work for your site, but upgrading is strongly recommended as older Drupal versions contain other disclosed security vulnerabilities.)

This release will not require a database update.

The CVE for this issue is CVE-2018-7602. The Drupal-specific identifier for the issue will be SA-CORE-2018-004.

The Security Team or any other party is not able to release any more information about this vulnerability until the announcement is made. The announcement will be made public at https://www.drupal.org/security, over Twitter, and in email for those who have subscribed to our email list. To subscribe to the email list: login on Drupal.org, go to your user profile page, and subscribe to the security newsletter on the Edit » My newsletters tab.

Journalists interested in covering the story are encouraged to email [email protected] to be sure they will get a copy of the journalist-focused release. The Security Team will release a journalist-focused summary email at the same time as the new code release and advisory.
If you find a security issue, please report it at https://www.drupal.org/security-team/report-issue.

Apr 18 2018
Apr 18

Description: 

CKEditor, a third-party JavaScript library included in Drupal core, has fixed a cross-site scripting (XSS) vulnerability. The vulnerability stemmed from the fact that it was possible to execute XSS inside CKEditor when using the image2 plugin (which Drupal 8 core also uses).

We would like to thank the CKEditor team for patching the vulnerability and coordinating the fix and release process, and matching the Drupal core security window.

Apr 13 2018
Apr 13

Description

This Public Service Announcement is a follow-up to SA-CORE-2018-002 - Drupal core - RCE. This is not an announcement of a new vulnerability. If you have not updated your site as described in SA-CORE-2018-002 you should assume your site has been targeted and follow directions for remediation as described below.

The security team is now aware of automated attacks attempting to compromise Drupal 7 and 8 websites using the vulnerability reported in SA-CORE-2018-002. Due to this, the security team is increasing the security risk score of that issue to 24/25

Sites not patched by Wednesday, 2018-04-11 may be compromised. This is the date when evidence emerged of automated attack attempts. It is possible targeted attacks occurred before that.

Simply updating Drupal will not remove backdoors or fix compromised sites. You should assume that the host is also compromised and that any other sites on a compromised host are compromised as well.

If you find that your site is already patched, but you didn’t do it, that can be a symptom that the site was compromised. Some attacks in the past have applied the patch as a way to guarantee that only that attacker is in control of the site.

What to do if your site may be compromised

Attackers may have copied all data out of your site and could use it maliciously. There may be no trace of the attack.

Take a look at our help documentation, ”Your Drupal site got hacked, now what.”

Recovery

Attackers may have created access points for themselves (sometimes called “backdoors”) in the database, code, files directory and other locations. Attackers could compromise other services on the server or escalate their access.

Removing a compromised website’s backdoors is difficult because it is very difficult to be certain all backdoors have been found.

If you did not patch, you should restore from a backup. While recovery without restoring from backup may be possible, this is not advised because backdoors can be extremely difficult to find. The recommendation is to restore from backup or rebuild from scratch. For more information please refer to this guide on hacked sites.

Contact and More Information

We prepared a FAQ that was released when SA-CORE-2018-002 was published. Read more at FAQ on SA-CORE-2018-002.

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.

Mar 28 2018
Mar 28

Description: 

A remote code execution vulnerability exists within multiple subsystems of Drupal 7.x and 8.x. This potentially allows attackers to exploit multiple attack vectors on a Drupal site, which could result in the site being completely compromised.

The security team has written an FAQ about this issue.

Solution: 

Upgrade to the most recent version of Drupal 7 or 8 core.

  • If you are running 7.x, upgrade to Drupal 7.58. (If you are unable to update immediately, you can attempt to apply this patch to fix the vulnerability until such time as you are able to completely update.)
  • If you are running 8.5.x, upgrade to Drupal 8.5.1. (If you are unable to update immediately, you can attempt to apply this patch to fix the vulnerability until such time as you are able to completely update.)

Drupal 8.3.x and 8.4.x are no longer supported and we don't normally provide security releases for unsupported minor releases. However, given the potential severity of this issue, we are providing 8.3.x and 8.4.x releases that includes the fix for sites which have not yet had a chance to update to 8.5.0.

Your site's update report page will recommend the 8.5.x release even if you are on 8.3.x or 8.4.x. Please take the time to update to a supported version after installing this security update.

This issue also affects Drupal 8.2.x and earlier, which are no longer supported. If you are running any of these versions of Drupal 8, update to a more recent release and then follow the instructions above.

This issue also affects Drupal 6. Drupal 6 is End of Life. For more information on Drupal 6 support please contact a D6LTS vendor.

Fixed By: 

Contact and more information

The Drupal security team can be reached by email at security at drupal.org or via the contact form.

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

Mar 28 2018
Mar 28

How many sites are likely affected?

Drupal 8, 7, and 6 sites are affected. According to the Drupal project usage information this represents over one million sites or about 9% of sites that are running a known CMS according to Builtwith.

How dangerous is this issue?

Drupal security advisories include a risk score based on the NIST Common Misuse Scoring System. This helps give an objective sense of the risk of different issues. The risk of SA-CORE-2018-002 is scored 24/25 (Highly Critical) AC:None/A:None/CI:All/II:All/E:Exploit/TD:Default.

In the long form this means:

  • How difficult is it for the attacker to leverage the vulnerability? None (user visits page).
  • What privilege level is required for an exploit to be successful? None (all/anonymous users).
  • Does this vulnerability cause non-public data to be accessible? All non-public data is accessible.
  • Can this exploit allow system data (or data handled by the system) to be compromised? All data can be modified or deleted.
  • Does a known exploit exist? Exploit exists (documented or deployed exploit code already in the wild).
  • What percentage of users are affected? Default or common module configurations are exploitable, but a config change can disable the exploit.

Note on the last point that while a configuration change can theoretically mitigate the issue, it would have to be a drastic configuration change. The Security Team strongly recommends that the best solution is for sites to upgrade.

Who found this issue?

The issue was identified by Jasper Mattsson (Jasu_M) as part of general research into the security of Drupal. Jasper works for Druid who provide a variety of services including security audits of Drupal sites.

Over the years, security issues in Drupal have been found a variety of ways including researchers with personal motivation and through paid penetration tests or security audits. Drupal site owners concerned about security are encouraged to hire security firms to review their site.

What could an attacker do on a vulnerable site?

A successful exploit of the vulnerability can have a dramatic impact on the site. See the description of the risk score for details.

Is the issue being exploited?

Exploits have been developed. Sites not patched by Wednesday, 2018-04-11 may be compromised. This is the date when evidence emerged of automated attack attempts. It is possible targeted attacks occurred before that.

Simply updating Drupal will not remove backdoors or fix compromised sites. Site builders should therefore update their sites immediately and then investigate to see if their site was compromised, perhaps following the guide for fixing a compromised site. See Drupal Core - Highly Critical - Public Service announcement - PSA-2018-002.

My site has been hacked, what should I do now?

Whether it was exploited via this issue or some prior issue, there is a general guide for "hacked" sites.

I manage a Drupal 6 site, is a fix available?

Yes, Drupal 6 is also affected and the Drupal 6 Long Term Support project has patches available.

What other security measures might I put in place to improve my site's security.

A few general suggestions include:

I manage a Drupal 8.0/8.1/8.2 site, is a fix available?

Previous minor versions of Drupal 8 are not supported after a new minor release is created. If your site is currently on a Drupal release prior to 8.3.8, there are other disclosed security vulnerabilities that may affect your site. For this reason, you should immediately update to at least Drupal 8.3.9 or 8.4.6, then plan to update to Drupal 8.5.1 or higher within the next month.

I can't update my site, what can I do to mitigate the problem?

There are several solutions, but they are all based on the idea of not serving the vulnerable Drupal pages to visitors. Temporarily replacing your Drupal site with a static HTML page is an effective mitigation. For staging or development sites you could disable the site or turn on a "Basic Auth" password to prevent access to the site.

List of updates

This FAQ may be updated and any updates will be summarized here.

Mar 21 2018
Mar 21
  • Advisory ID: DRUPAL-PSA-2018-001
  • Project: Drupal Core
  • Version: 7.x, 8.x
  • Date: 2018-March-21

Description

There will be a security release of Drupal 7.x, 8.3.x, 8.4.x, and 8.5.x on March 28th 2018 between 18:00 - 19:30 UTC, one week from the publication of this document, that will fix a highly critical security vulnerability. The Drupal Security Team urges you to reserve time for core updates at that time because exploits might be developed within hours or days. Security release announcements will appear on the Drupal.org security advisory page.

While Drupal 8.3.x and 8.4.x are no longer supported and we don't normally provide security releases for unsupported minor releases, given the potential severity of this issue, we are providing 8.3.x and 8.4.x releases that include the fix for sites which have not yet had a chance to update to 8.5.0. The Drupal security team strongly recommends the following:

  • Sites on 8.3.x should immediately update to the 8.3.x release that will be provided in the advisory, and then plan to update to the latest 8.5.x security release in the next month.
  • Sites on 8.4.x should immediately update to the 8.4.x release that will be provided in the advisory, and then plan to update to the latest 8.5.x security release in the next month.
  • Sites on 7.x or 8.5.x can immediately update when the advisory is released using the normal procedure.

The security advisory will list the appropriate version numbers for all three Drupal 8 branches. Your site's update report page will recommend the 8.5.x release even if you are on 8.3.x or 8.4.x, but temporarily updating to the provided backport for your site's current version will ensure you can update quickly without the possible side effects of a minor version update.

This will not require a database update.

Patches for Drupal 7.x and 8.3.x, 8.4.x, 8.5.x and 8.6.x will be provided.

The CVE for this issue is CVE-2018-7600. The Drupal-specific identifier for the issue is SA-CORE-2018-002.

The Security Team or any other party is not able to release any more information about this vulnerability until the announcement is made. The announcement will be made public at https://www.drupal.org/security, over Twitter, and in email for those who have subscribed to our email list. To subscribe to the email list: log in on drupal.org, go to your user profile page and subscribe to the security newsletter on the Edit » My newsletters tab.

Journalists interested in covering the story are encouraged to email [email protected] to be sure they will get a copy of the journalist-focused release. The Security Team will release a journalist-focused summary email at the same time as the new code release and advisory.

If you find a security issue, please report it at https://www.drupal.org/security-team/report-issue.

updated 2018-03-22: Added information about database updates

updated 2018-03-27: Added information about patches

updated 2018-03-28: Added information about CVE and identifiers

Feb 21 2018
Feb 21

This security advisory fixes multiple vulnerabilities in both Drupal 7 and Drupal 8. See below for a list.

Comment reply form allows access to restricted content - Critical - Drupal 8 - CVE-2017-6926

Users with permission to post comments are able to view content and comments they do not have access to, and are also able to add comments to this content.

This vulnerability is mitigated by the fact that the comment system must be enabled and the attacker must have permission to post comments.

JavaScript cross-site scripting prevention is incomplete - Critical - Drupal 7 and Drupal 8 - CVE-2017-6927

Drupal has a Drupal.checkPlain() JavaScript function which is used to escape potentially dangerous text before outputting it to HTML (as JavaScript output is not auto-escaped by either Drupal 7 or Drupal 8). This function does not correctly handle all methods of injecting malicious HTML, leading to a cross-site scripting vulnerability under certain circumstances.

The PHP functions which Drupal provides for HTML escaping are not affected.

Private file access bypass - Moderately Critical - Drupal 7 - CVE-2017-6928

When using Drupal's private file system, Drupal will check to make sure a user has access to a file before allowing the user to view or download it. This check fails under certain conditions in which one module is trying to grant access to the file and another is trying to deny it, leading to an access bypass vulnerability.

This vulnerability is mitigated by the fact that it only occurs for unusual site configurations.

jQuery vulnerability with untrusted domains - Moderately Critical - Drupal 7 - CVE-2017-6929

A jQuery cross site scripting vulnerability is present when making Ajax requests to untrusted domains (the CVE for this issue in jQuery is CVE-2015-9251). This vulnerability is mitigated by the fact that it requires contributed or custom modules in order to exploit.

For Drupal 8, this vulnerability was already fixed in Drupal 8.4.0 in the Drupal core upgrade to jQuery 3. For Drupal 7, it is fixed in the current release (Drupal 7.57) for jQuery 1.4.4 (the version that ships with Drupal 7 core) as well as for other newer versions of jQuery that might be used on the site, for example using the jQuery Update module.

Language fallback can be incorrect on multilingual sites with node access restrictions - Moderately Critical - Drupal 8 - CVE-2017-6930

When using node access controls with a multilingual site, Drupal marks the untranslated version of a node as the default fallback for access queries. This fallback is used for languages that do not yet have a translated version of the created node. This can result in an access bypass vulnerability.

This issue is mitigated by the fact that it only applies to sites that a) use the Content Translation module; and b) use a node access module such as Domain Access which implement hook_node_access_records().

Note that the update will mark the node access tables as needing a rebuild, which will take a long time on sites with a large number of nodes.

Settings Tray access bypass - Moderately Critical - Drupal 8 - CVE-2017-6931

The Settings Tray module has a vulnerability that allows users to update certain data that they do not have the permissions for.

If you have implemented a Settings Tray form in contrib or a custom module, the correct access checks should be added. This release fixes the only two implementations in core, but does not harden against other such bypasses.

This vulnerability can be mitigated by disabling the Settings Tray module.

External link injection on 404 pages when linking to the current page - Less Critical - Drupal 7 - CVE-2017-6932

Drupal core has an external link injection vulnerability when the language switcher block is used. A similar vulnerability exists in various custom and contributed modules. This vulnerability could allow an attacker to trick users into unwillingly navigating to an external site.

Aug 17 2017
Aug 17
  • Advisory ID: DRUPAL-PSA-2017-002
  • Project: Drupal contributed modules
  • Version: 7.x, 8.x
  • Date: 2017-Aug-16

Description

The Drupal Security Team is now aware that the Views ajax access bypass vulnerability (DRUPAL-SA-CONTRIB-2017-068 and SA-CORE-2017-004) released 16 Aug 2017 is more severe than originally announced, because many widely used contrib modules don't have access restrictions set on the default views they provide. Any view that does not have access controls on the default (master) display may be vulnerable. The vulnerability does not require any authentication to be exploited. A successful exploit results in some non-public data being made public.

Sites running versions of Views prior to 7.x-3.17 or Drupal 8 core prior to version 8.3.7 (including Drupal 8.1.x and 8.2.x) should update immediately. Drupal 7 core is only affected if the Views module is enabled.

If you are unable to update Views, you can mitigate this by editing views that contain sensitive data in the Views UI and making sure they utilise one of the permission controls - such as 'require a role' or 'require a permission'. See Views permissions manual page for more information.

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

Aug 16 2017
Aug 16

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

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

Jul 17 2017
Jul 17

Symfony contacted the Drupal Security team about today's Symfony security release addressing an issue in UserPasswordValidator. This announcement is to reassure the Drupal community that Drupal 8 is not affected by this fix, as it does not make use of this security component. There is no Drupal 8 release scheduled for this, and there is no action you need to take on your Drupal site(s).

Jun 21 2017
Jun 21

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

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

Apr 19 2017
Apr 19

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

  • CVE-2017-6919

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

Apr 17 2017
Apr 17
  • Advisory ID: DRUPAL-PSA-2017-001
  • Project: Drupal core
  • Version: 8.x
  • Date: 2017-Apr-17

Description

There will be a security release of Drupal 8.3.x and 8.2.x on April 19th 2017 between
17:00 - 18:00 UTC that will fix a critical vulnerability. While we don't normally provide security releases for unsupported minor releases, given the potential severity, we will provide an 8.2.x release that includes the fix for sites which have not had a chance to update to 8.3.0. The Drupal Security Team urges you to reserve time for core updates at that time because exploits are expected to be developed within hours or days. Security release announcements will appear at the standard announcement locations.

This vulnerability does not affect all Drupal 8 sites; it only affects sites with certain configurations. It requires authenticated user access to exploit. The security release announcement on April 19th 2017 will make it clear which configurations are affected. If this vulnerability affects your site, you will need to update. Please set aside time on Wednesday to look into this update.

Neither the Security Team, nor Security Team members, nor any Drupal-related company are able to release any more information about this vulnerability until the announcement is made in accordance with our security policies and vulnerability disclosure best practices.

We provide pre-release warnings when we believe the security risk is high and the steps to exploit are scriptable.

Drupal 7 core is not affected by this issue.

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.

Mar 15 2017
Mar 15

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

Update 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

Update 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

Updates

Updated the above text to link to the correct update directions.

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

Dec 26 2016
Dec 26

Description

The PHPMailer and SMTP modules (and maybe others) add support for sending e-mails using the 3rd party PHPMailer library.

In general the Drupal project does not create advisories for 3rd party libraries. Drupal site maintainers should pay attention to the notifications provided by those 3rd party libraries as outlined in PSA-2011-002 - External libraries and plugins. However, given the extreme criticality of this issue and the timing of its release we are issuing a Public Service Announcement to alert potentially affected Drupal site maintainers.

CVE identifier(s) issued

  • CVE-2016-10033

Versions affected

All versions of the external PHPMailer library < 5.2.18.

Drupal core is not affected. If you do not use the contributed PHPMailer third party library, there is nothing you need to do.

Solution

Upgrade to the newest version of the phpmailler library. https://github.com/PHPMailer/PHPMailer

The SMTP module has a modified third party PHPMailer library in its codebase. The modified version of the library is not affected.
The SMTP module had an update marked as a security update, this was incorrect, the pervious version of smtp was not vulnerable to the phpmailler issue. This update just removed some older code that was not being used.

A special thanks to Fabiano Sant'Ana, SMTP module maintainer, for working on this with short notice.

Reported by

  • Dawid Golunski

Updates

Updated on 2016-12-27, to clarify smtp module does not need a security update

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

Nov 16 2016
Nov 16

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

  • Inconsistent name for term access query: CVE-2016-9449
  • Incorrect cache context on password reset page: CVE-2016-9450
  • Confirmation forms allow external URLs to be injected: CVE-2016-9451
  • Denial of service via transliterate mechanism: CVE-2016-9452

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

Oct 10 2016
Oct 10

Description

Recently the Drupal Security Team has seen a trend of attacks utilizing a site mis-configuration.
This issue only affects sites that allow file uploads by non-trusted or anonymous visitors, and stores those uploads in a public file system. These files are publically accessible allowing attackers to point search engines and people directly to them on the site. The majority of the reports are based around the webform module, however, other modules are vulnerable to this misconfiguration as well.

For example, if a webform configured to allow anonymous visitors to upload an image into the public file system, that image would then be accessible by anyone on the internet. The site could be used by an attacker to host images and other files that the legitimate site maintainers would not want made publicly available through their site.

To resolve this issue:

  1. Configure upload fields that non-trusted visitors, including anonymous visitors, can upload files with, to use the private file system.
  2. Ensure cron is properly running on the site. Read about setting up cron for for Drupal 7 or or Drupal 8).
  3. Consider forcing users to create accounts before submitting content.
  4. Audit your public file space to make sure that files that are uploaded there are valid.

Awareness acknowledgment

The Drupal Security Team became aware of the existence and exploits of this issue because the community reported this issue to the security team. As always, if your site has been exploited, even if the cause is a mistake in configuration, the security team is interested in hearing about the nature of the issue. We use these reports to look for trends and broader solutions.

Coordinated by

This post may be updated as more information is learned.

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.

Sep 21 2016
Sep 21

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

  • Users without "Administer comments" can set comment visibility on nodes they can edit: CVE-2016-7570
  • Cross-site Scripting in http exceptions: CVE-2016-7571
  • Full config export can be downloaded without administrative permissions: CVE-2016-7572

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

Jul 18 2016
Jul 18

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:

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

Jul 18 2016
Jul 18

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:

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

Jul 17 2016
Jul 17
  • Advisory ID: DRUPAL-PSA-2016-002
  • Project: Drupal
  • Version: 8.x
  • Date: 2016-July-17
  • Security risk: TBD
  • Vulnerability: TBD

Description

We will be doing a Drupal 8 core patch release on Monday, July 18th. This will occur between 14:15 UTC and 19:00 UTC.

There will not be a Drupal 7 release during this window.

Update: details and mitigating instructions

A release of Drupal core that fixes this issue is available via SA-CORE-2016-003. Details of the issue (dubbed httpoxy) are avialable at httpoxy.org. In addition to the background information available the site also includes mitigation instructions.

Why is this release being issued?

The Drupal security team has learned that a third-party Drupal 8 dependency will be making a security release on Monday, July 18th and in accordance we will be making a Drupal 8 release soon after. We will not disclose details of the third-party update in advance of that release and cannot respond to requests for further information. This security release is for the dependency only and does not affect Drupal 7 sites. Other mitigating factors will be included with our published SA.

What about the regularly scheduled release window on Wednesday, July 20?

We are moving the regularly scheduled window two days earlier to provide the third-party dependency update, so this replaces that window.

There will not be another core release on Wednesday, July 20th.

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

Edited to add:

  • July 18th 14:00 UTC: Link to details and mitigation instructions

Pages

About Drupal Sun

Drupal Sun is an Evolving Web project. It allows you to:

  • Do full-text search on all the articles in Drupal Planet (thanks to Apache Solr)
  • Facet based on tags, author, or feed
  • Flip through articles quickly (with j/k or arrow keys) to find what you're interested in
  • View the entire article text inline, or in the context of the site where it was created

See the blog post at Evolving Web

Evolving Web