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.

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.

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

Oct 17 2018
Oct 17

The Drupal Security team has a core and contrib release window on the 3rd Wednesday of the month. This window normally ends at 5pm Eastern (9PM UTC).

Due to unforeseen circumstances, we are extending the current window we are in by 3 hours until Oct 17th, 2018 at 8pm Eastern (11:59PM UTC).

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

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

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.

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

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.

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
Jul 12 2016
Jul 12

Update: Release Annoucements

The following modules have security releases that are now available, listed in order of severity. There are no more releases planned for today.

Description

There will be multiple releases of Drupal contributed modules on Wednesday July 13th 2016 16:00 UTC that will fix highly critical remote code execution vulnerabilities (risk scores up to 22/25). These contributed modules are used on between 1,000 and 10,000 sites. The Drupal Security Team urges you to reserve time for module updates at that time because exploits are expected to be developed within hours/days. Release announcements will appear at the standard announcement locations.

Drupal core is not affected. Not all sites will be affected. You should review the published advisories on July 13th 2016 to see if any modules you use are affected.

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: approximate usage of the modules, links to the final releases, that there are no more releases for today..

Dec 02 2015
Dec 02

Description

When a Drupal installation is not completed past the database configuration phase and install.php is left accessible via the internet, any visitor to install.php may complete the installation with a remote database of their selection.

Such a malicious user may use the remote database to execute code on the server.

The above also applies to sites that react to certain hostnames with an installation page and have a sites folder owned or writable by the webserver. Such inadvertent multisites may occur when no default settings.php is present and directory permissions are misconfigured.

These vulnerabilities are mitigated by setting directory and/or file permissions that prevent the webserver from writing to the sites/default/ and sites/ directories.

Versions affected

Drupal 6 core, Drupal 7 core and Drupal 8 core.

Solution

Always complete installations fully on servers exposed to the internet. Ensure that the webserver does not own the sites folder and cannot write to the sites folder.

Consider removing install.php after installation.

Consider installing and automating the execution of Security review which will identify weak file permissions and ownership.

Also see the Drupal core project page.

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

Oct 29 2014
Oct 29

Description

This Public Service Announcement is a follow up to SA-CORE-2014-005 - Drupal core - SQL injection. This is not an announcement of a new vulnerability in Drupal.

Automated attacks began compromising Drupal 7 websites that were not patched or updated to Drupal 7.32 within hours of the announcement of SA-CORE-2014-005 - Drupal core - SQL injection. You should proceed under the assumption that every Drupal 7 website was compromised unless updated or patched before Oct 15th, 11pm UTC, that is 7 hours after the announcement.

Simply updating to Drupal 7.32 will not remove backdoors.

If you have not updated or applied this patch, do so immediately, then continue reading this announcement; updating to version 7.32 or applying the patch fixes the vulnerability but does not fix an already compromised website. 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 have applied the patch as a way to guarantee they are the only attacker in control of the site.

Data and damage control

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 not possible to be certain all backdoors have been found.

The Drupal security team recommends that you consult with your hosting provider. If they did not patch Drupal for you or otherwise block the SQL injection attacks within hours of the announcement of Oct 15th, 4pm UTC, restore your website to a backup from before 15 October 2014:

  1. Take the website offline by replacing it with a static HTML page
  2. Notify the server’s administrator emphasizing that other sites or applications hosted on the same server might have been compromised via a backdoor installed by the initial attack
  3. Consider obtaining a new server, or otherwise remove all the website’s files and database from the server. (Keep a copy safe for later analysis.)
  4. Restore the website (Drupal files, uploaded files and database) from backups from before 15 October 2014
  5. Update or patch the restored Drupal core code
  6. Put the restored and patched/updated website back online
  7. Manually redo any desired changes made to the website since the date of the restored backup
  8. Audit anything merged from the compromised website, such as custom code, configuration, files or other artifacts, to confirm they are correct and have not been tampered with.

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 see our FAQ on SA-CORE-2014-005.

Written by

Coordinated by

Contact and More Information

We've prepared a FAQ on this release. Read more at FAQ on SA-CORE-2014-005.

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.

May 21 2014
May 21
  • Advisory ID: DRUPAL-PSA-2014-002
  • Project: Drupal core
  • Version: 6.x, 7.x
  • Date: 2014-May-21
  • Security risk: Not critical
  • Exploitable from: Remote
  • Vulnerability: Information Disclosure

Description

This is a public service announcement regarding the "access site reports" permission (labeled as "View site reports" in the Drupal 7 administrative interface) provided by Drupal 6 and 7 core.

This permission allows users to see logs (for example, those provided by the core Database Logging module) and other reports via the administrative interface of a Drupal site. Due to the nature of the data logged by various core and contributed modules, users with this permission can see information in the logs that they otherwise may not have access to (for example, the titles of nodes that are restricted by node access).

As such:

  • This permission should be granted to trusted site administrators only. It is now listed as an advanced permission at https://drupal.org/security-advisory-policy, and a future release of Drupal 7 core will mark it as restricted on the permissions page as well.
  • Developers may freely use Drupal's watchdog() function to log relevant information about the actions they are performing (without worrying about minor information disclosure or access bypass issues). However, care should still be taken to only log what is necessary. For example, logging extremely sensitive information such as plain-text user passwords (see SA-CONTRIB-2010-091) would still be considered a security issue because plain-text passwords should never be saved or displayed anywhere on the site.

CVE identifier(s) issued

  • A CVE identifier will be requested, and added upon issuance, in accordance with Drupal Security Team processes.

Versions affected

All versions of Drupal 6 and Drupal 7 core.

Solution

Only grant trusted site administrators the "access site reports"/"View site reports" permission.

Also see the Drupal core project page.

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

Jan 08 2014
Jan 08
  • Advisory ID: PSA-2014-001
  • Project: Media (third-party module)
  • Version: 7.x
  • Date: 2014-01-08
  • Security risk: Moderately critical
  • Exploitable from: Remote
  • Vulnerability: Access Bypass

Description

This is a public service announcement regarding the "import media" permission, labeled as "Import media files from the local file system," provided by the Media module.

The Media module provides a method for Drupal administrators to import existing files from an arbitrary location on the server. Users with the 'import media' permission can import any file from the server as local Drupal files, even those outside the Drupal install directory, which could lead to information disclosure.

As such, this permission should be granted to trusted site administrators. In the 7.x-2.x version of the module, you may disable the sub-module named "Media Bulk Upload" to disable this functionality.

CVE identifier(s) issued

  • A CVE identifier will be requested, and added upon issuance, in accordance with Drupal Security Team processes.

Versions affected

  • Media module for Drupal 7.x

Drupal core is not affected. If you do not use the contributed Media module, there is nothing you need to do.

Solution

Only grant trusted site administrators the "import media" permission.

This permission is not marked as a restricted permission in the following versions:

  • Media module 7.x-1.x versions prior to 7.x-1.4
  • Media module 7.x-2.x versions prior to 7.x-2.0-alpha3+37-dev

Upgrading to the latest release is recommended, but not required.

Also see the Media project page.

Reported by

Fixed by

  • Dave Reid the module maintainer and of the Drupal Security Team

Coordinated by

  • Dave Reid the module maintainer and 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 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

Oct 30 2013
Oct 30

This is a short addition to the security announcements released on October 30th.

Due to Drupal.org's scheduled downtime on October 31, not all links in those mails may be available when you need them.

If you encounter this situation, please use the following direct URLs to the archives containing the updates.

Sep 04 2013
Sep 04
  • Advisory ID: PSA-2013-001
  • Project: Drupal core
  • Version: 6.x, 7.x
  • Date: 2013-September-04
  • Security risk: Not critical
  • Exploitable from: Remote
  • Vulnerability: Information Disclosure

Description

This is a public service announcement regarding possible insertion of hidden links in comments using core CSS selectors within filtered HTML Text formats ("Input formats" in Drupal 6). Drupal core provides several CSS selectors that, by design, hide elements on the page. Using these selectors it is possible to create links to third-party websites that are hidden within a comment. This technique has been observed on live production websites.

Drupal core provides mechanisms that sanitize user submitted links by adding a rel="nofollow" attribute. This feature can be enabled for Drupal 7 sites at admin/config/content/formats/filtered_html and for Drupal 6 sites at admin/settings/filters/1/configure. Note that these paths are for the default formats provided with core. Your site may define custom formats which should be reviewed and updated as well.

Careful moderation of user submitted comments is always advised. Additionally, automated comment moderation tools may help to mitigate and flag these malicious comment submissions.

Solution

Review user-submitted content on your site to see if untrusted users have posted content that includes classes. Review those classes to see if they will hide unwanted content.

Reported 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
Mar 07 2012
Mar 07
  • Advisory ID: DRUPAL-PSA-2012-001
  • Version: 6.x, 7.x
  • Date: 2012-March-07
  • Security risk: Moderately critical
  • Exploitable from: Remote
  • Vulnerability: Cross Site Scripting

Description

This is a public service announcement regarding possible cross-site scripting risks associated with interface localizations for Drupal. Drupal has cross-site scripting prevention filters in the interface localization import code in Drupal core, however, the extent to which localization can be used to inject markup to webpages is wider, and due to Drupal's localization architecture and code reuse, we cannot tell in advance where the localized text is going to be used and how we should sanitize the translated text. When translated text is used, developers do not expect that it might cause cross-site scripting issues and therefore do not use filtering techniques when the resulting text is assembled into the output.

You should be aware that Drupal's cross-site scripting prevention for interface localizations is not complete and therefore you should review the localizations imported to your site before importing them or ensure that they come from trusted sources. Even Drupal's central localization source, localize.drupal.org has configurable permission system for teams. Those teams where translations are moderated by a team of volunteers are less likely to contain any attack code.

Consequently we are adding translate interface to our list of advanced permissions in our Security advisories process and permissions policy document.

The issue also affect contributed modules like Localization update which automate localization import from localize.drupal.org and compatible servers or String overrides, which allows you to use the localization system to override English built-in text.

Versions affected

Multiple modules can be used to translate the interface text. Some of those are

Drupal core is not affected. If you do not use the contributed module, there is nothing you need to do.

Solution

Given that translations strings can be harmful, you should treat them with the same skepticism that you treat modules. Get them from reputable sources or review them prior to using them.

See also the project page.

Reported by

Fixed by

This PSA drafted 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
Jan 11 2012
Jan 11
  • Advisory ID: DRUPAL-PSA-2012-001
  • Project: Drupal core
  • Version: 6.x, 7.x
  • Date: 2012-01-11
  • Security risk: Less critical
  • Exploitable from: Remote
  • Vulnerability: Denial of Service

Description

Update, June 12th 2012: this advisory is related to flaws in PHP with CVE identifiers CVE-2011-4885 and CVE-2012-0830. Users are encouraged to update the PHP used for their site to a version that is known to fix those vulnerabilities. See below for mitigation techniques if your site runs a version of PHP that doesn't contain those fixes and you cannot change it.

PHP is vulnerable to a hash collision denial of service (DOS) attack. If an attacker can post a large amount of specifically chosen variables to the site, a large amount of CPU time is consumed preventing service to visitors.

Many users deploy the Suhosin PHP extension to limit the amount of posted variables that will be handled by PHP, thus preventing the DOS attack.

There's an unfortunate interaction with the mbstring extension required by Drupal to work with UTF-8. When the setting mbstring.encoding_translation is updated via .htaccess the mbstring extension changes the PHP POST handlers so that only every other POST variable can be handled by Suhosin.

While Suhosin will still remove half of the variables over the post.max_vars limit, it is ultimately unsuccesful in limiting the amount of posted variables and thus in preventing the hash collision DOS attack.

Versions affected

All versions

Solution

Confirm that the master value of mbstring.encoding_translation is set to Off via:

  • Drupal 7: Reports > Status, then More information on the PHP version (admin/reports/status/php)
  • Drupal 6: Administer > Reports > Status report, then follow the link on the PHP version (admin/reports/status/php)

Next, remove the lines from the file .htaccess in the Drupal root.

For Drupal 7.x remove the lines:

php_flag mbstring.encoding_translation off

For Drupal 6.x remove the lines:

php_value mbstring.encoding_translation 0

If the master value of mbstring.encoding_translation is On, change it to Off via PHP.ini. Contact your hosting provider if necessary.

If you do not use Suhosin, limit the amount of variables posted to your site in another way. You should consider upgrading to PHP 5.3.9 and using its newly introduced directive 'max_input_vars'.

Please note that setting such limits too low (whether via Suhosin or PHP) can break processing on long forms like the permissions administration screen.

It is likely that the near-future will see an update to Suhosin, making the procedure described in this PSA unnecessary.

See also the Drupal core project page.

Reported by

  • Dominic Böttger

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
Jun 15 2011
Jun 15
  • Advisory ID: PSA-2011-002
  • Date: 2011-June-15
  • Project: External libraries and plugins

Description

Just like there's a need to dilligently 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.

The specific issue precipitating this public service announcement is a cross site scripting vulnerability in (F)CKEditor, a common JavaScript-based WYSIWYG editor used as a library in the modules CKeditor, FCKEditor and WYSIWYG.

Exploit examples are circulating.

Versions affected

  • CKEditor versions prior to version 3.5.4
  • FCKEditor versions prior to version 2.6.4.1

Solution

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

In this specific case, remove the _samples directory from the (f)ckeditor installation or upgrade to a non-vulnerable version. Make sure to test compatibility between Drupal modules and new library versions before deploying.

Reported by

The Drupal security was alerted to this issue by Henry Sudhof.

Contact

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

Feb 17 2011
Feb 17
  • Advisory ID: PSA-2011-001
  • Project: Drupal core and contrib
  • Versions: All versions
  • Date: 2011-February-17
  • Security risk: Not critical

Description

This is a public service announcement regarding a recent social engineering attack via the following mail purporting to come from the Drupal security team.

Hello,

I am a member of the Drupal security team. Our installation records show that your site runs Drupal on PHP [version] and [server]. We have recently found a security problem with that configuration which could allow a hacker to get into the site and delete any posts they want. We have not posted anything about this yet publicly as we want to get this patch out to as many people as possible first.

We have developed a patch for this bug - all you need to do is upload this file to your site in the sites/default/files/ folder (do not change the name of the file) and Drupal will see it and install it for you. We recommend you do this as soon as possible.

Sincerely,
James
Drupal security team

The mail was sent with Drupal Security <[email protected]> as the (easily-forged) "From" address. It also contained an attachment that was said to be a patch that had to be uploaded and installed. Needless to say that this file contained code to make the system accessible from the outside. If you received a message like the above, do not upload the attached file.

How the Drupal Security Team communicates:

  1. The Security Team does not supply patches to sites.
  2. The Security Team will never ask site administrators to upload random files to their site. We only recommend to update to latest core or contrib releases downloaded from drupal.org.
  3. The Security Team officially uses three forms of communication for Drupal Security Advisories; the update report in your Drupal installation, the posts and RSS feed on http://drupal.org/security, and the newsletter available from your Drupal.org user page. The Drupal Security Team does not publish to a Twitter feed or provide any other official communication channel.
  4. The Security Team will never ask for passwords for your host or your Drupal install.

If you receive communications from someone saying they are a member of the Security Team and their request is questionable, please forward the email to the team at sec[email protected].

Contact

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

Jun 16 2010
Jun 16
  • Advisory ID: PSA-2010-002
  • Project: Views (third-party module)
  • Versions: 5.x, 6.x
  • Date: 2010-June-16
  • Security risk: Not critical

Description

This is a public service announcement regarding the "administer views" permission provided by the Views module.

The Views module provides a flexible method for Drupal site designers to control how lists and tables of content are presented. The module grants considerable power to users with "administer views" permission, with much of a site's behaviour being configurable via the views administration pages.

The permission "administer views" is therefore comparable in scope to the "administer site configuration" permission. Only grant this permission to trusted site administrators.

Versions affected

  • Views module for Drupal 5.x
  • Views module for Drupal 6.x

Drupal core is not affected. If you do not use the contributed Views module, there is nothing you need to do.

Solution

Only grant trusted site administrators the "administer views" permission.

Contact

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

May 13 2010
May 13
  • Advisory ID: PSA-2010-001
  • Project: Drupal core and contrib
  • Versions: 5.x and 6.x and above
  • Date: 2010-May-13
  • Security risk: None

Description

This is a public service announcement regarding Drupal Security Team policies. In a previous PSA we stated that vulnerabilities in modules which require the "administer content types" permission to be exploited would not receive an official security release with a security advisory (SA) and would be handled publicly much like the way the "administer site configuration" permission was treated. We now maintain a list of permissions that are treated similarly at Security advisories process and permissions policy.

That page also clarifies which projects (modules, themes, and distributions) on drupal.org receive SAs and includes only projects that have an official release that is identified as "Y.x-Z.0" and not for projects in beta, alpha, or even release candidate (RC) stage. This means that a security vulnerability in a 6.x-1.0 or 6.x-2.2 release will receive a SA while a 6.x-1.0-beta10 or 6.x-2.0-RC3 will not receive a SA. A project maintainer may use the "Security update" term to indicate a release that includes security improvements even if there is no SA, but they are not required to do so. Using the "Security update" term will trigger the Update module in Drupal 6.x+ core to alert site maintainers to update their site. The goal with this policy is to ensure that official security releases with SAs are relevant and receive appropriate attention, to allow maintainers to readily fix problems when their project is still in active development, and to permit effective channels of communication between the maintainers and users of a project.

Solution

Only grant the most trusted site administrators the permissions listed on the Security advisories process and permissions policy page.

Be aware that projects on drupal.org will not receive an SA and security vulnerabilities will not be kept private until a project reaches an official release "Y.x-Z.0" status. You are encouraged to use only "Y.x-Z.0" projects for your sites, and to contribute to or sponsor work on projects you use so that they can reach an official release.

Contact

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

Feb 11 2009
Feb 11
  • Advisory ID: DRUPAL-SA-CORE-2009-002
  • Project: Drupal core
  • Versions: 5.x and 6.x
  • Date: 2009-February-11
  • Security risk: None

Description

This is a public service announcement regarding the "administer content types" permission. The rise of the Content Construction Kit (CCK) and a legion of powerful CCK field modules have considerably extended the abilities of a user with this permission, with much of a site's behaviour now being configurable via the content types administration pages.

The permission "administer content types" is therefore comparable in scope to the "administer site configuration" permission. Only grant this permission to trusted site administrators.

Solution

Only grant trusted site administrators the "administer content types" permission.

Contact

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

Oct 17 2007
Oct 17
Posted by Heine on 17 Oct 2007 at 18:29 UTC
  • Advisory ID: SA-2007-023
  • Project: PHP
  • Version: PHP 4 < 4.4.3, PHP 5 < 5.1.4
  • Date: 2007-October-17
  • Security risk: Critical
  • Exploitable from: Remote
  • Vulnerability: unset() hash / index collision exploit using Drupal (CVE-2006-3017)

Description

The PHP unset() Hash / Index collision vulnerability causes the unset() statement to fail in certain circumstances.

Drupal uses the unset statement to eliminate all non-whitelisted global variables when the option "register_globals" is enabled for your PHP installation. As unset() can be caused to fail on vulnerable versions of PHP, arbitrary global variables can be created. This can easily lead to the execution of arbitrary PHP code with a specially crafted URL, similar to the one shown below, that causes the menu system to call the PHP evaluator with arbitrary code:

http://example.com?_menu[callbacks][1][callback]=drupal_eval&_menu[items...();

An exploit for this is widely circulating. The attack will not work when "register_globals" is set to off.

The issue is not limited to installations with "register_globals" set to on. unset() is used in other parts of the codebase where a bypass may result in unintended actions that may compromise your security.

Versions affected

  • PHP 4 before version 4.4.3.
  • PHP 5 before version 5.1.4.

Solution

Upgrade to the latest version of PHP:

  • When using PHP 4 upgrade to PHP 4.4.7.
  • When using PHP 5 upgrade to PHP 5.2.4.

Always apply the latest security patches to your server components.
You may need to review your server management strategy if you are still running a vulnerable PHP version.

Contact

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

Jan 04 2006
chx
Jan 04
Posted by chx on 4 Jan 2006 at 16:15 UTC

Someone under the pseudonym "Liz0ziM" sent a false security alarm to BugTraq without first contacting the security team:

http://www.securityfocus.com/archive/1/420671/30/0/threaded

This vulnerability is fixed in Drupal 4.5.6, 4.6.4 and onwards. Drupal's new XSS filter mechanism takes care of all vulnerabilities listed on http://ha.ckers.org/xss.html (and even more).

If you have already updated to at least 4.5.6 / 4.6.4 then you are safe and you do not need to take any action. If you have not updated yet, then we advise you again to do so ASAP.

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