Upgrade Your Drupal Skills

We trained 1,000+ Drupal Developers over the last decade.

See Advanced Courses NAH, I know Enough
Jul 21 2021
Jul 21

The Drupal project uses the pear Archive_Tar library, which has released a security update that impacts Drupal.

The vulnerability is mitigated by the fact that Drupal core's use of the Archive_Tar library is not vulnerable, as it does not permit symlinks.

Exploitation may be possible if contrib or custom code uses the library to extract tar archives (for example .tar, .tar.gz, .bz2, or .tlz) which come from a potentially untrusted source.

This advisory is not covered by Drupal Steward.

Jun 29 2021
Jun 29

How do I upgrade my Drupal 8 site to Drupal 9?

The Drupal 8 to Drupal 9 upgrade process is much easier than previous major-version upgrades. There are many automated tools available to assist with the upgrade. Learn more about upgrading your Drupal 8 site to Drupal 9.

What if a module I need doesn't have a Drupal 9 release?

Many modules can be upgraded automatically. Check the module's issue queue for an issue created by "Project Update Bot".

  1. If the "Project Update Bot" issue is not yet marked "Reviewed and Tested by the Community" ("RTBC"), review and test whether the module works for you on Drupal 9 with that patch applied to its code.
    • If the issue is set to "Needs review" and your testing does not encounter any problems, you can mark the issue RTBC, along with a comment explaining what you tested and how.
    • Otherwise, if it does not work or causes bugs that didn't happen before, mark the issue "Needs work" explaining what did not work with the Drupal 9 patch.
  2. If the existing issue is already "Reviewed & Tested by the Community", test it yourself, and comment on the issue reporting what testing you did. Consider using the maintainer's contact form to reach out to them asking them to make a Drupal 9 release.
     
  3. If you have maintained contributed projects before and the patch has been RTBC for at least two weeks, consider taking over maintenance of the module. Otherwise, if you work with an organization that provides Drupal services, ask that organization to consider taking over maintenance of the module.

If you cannot find anyone to maintain the module, try using the patch directly with composer.

The Drupal Association will also be taking additional steps to help with the creation of Drupal-9-compatible releases in the coming months.

What about Drupal 7?

Drupal 7 will still have community-based security coverage until November 28, 2022. The paid Drupal 7 Vendor Extended Support program will continue until November 2025.

Jun 01 2021
Jun 01

The Drupal Core security release SA-CORE-2021-003 on 2021 May 26 was delayed by a combination of infrastructure issues, causing the release to be delayed to outside the planned release window. This post-mortem blog explains the circumstances, and how the Drupal security team and Drupal Association are collaborating to improve the situation for the next release.

On 2021-05-25, the Drupal Security team published a Public Service Announcement (PSA) about an off-cycle release for Drupal Core. Typically, the Drupal security team will publish PSA's about releases under a few conditions:

  1. If the release is off-cycle (core security releases are on the 3rd Wednesday of the month
  2. If the release is highly critical, the security team will issue a PSA before the normal window.

For SA-CORE-2021-003 the release was off-cycle because it related to a 3rd party library, and so a PSA was issued.

At 17:30pm UTC on 2021-05-26 the release process started. This normally takes 20-45min. The PSA had triggered a large amount of "bot" like traffic to our GitLab infrastructure.

Because of the nature of this particular commit as a change to the integration points of a 3rd party dependency, the diff was exceptionally large. As a result, each request to commit pages in the Drupal GitLab instance was significantly more resource-intensive than average.

The load on the GitLab infrastructure caused the systems that create the packages and update subtree splits to become unstable.

Key points

  • A PSA was sent in advance of the release because it was happening outside the normal core cycle.
  • This PSA resulted in large amounts of traffic to Drupal.org and to our GitLab installation, and in particular, a large number of people and scripts looking at the commit history for new commits - even before the release was published.
  • Because of the nature of this particular commit, the diff was exceptionally large, and each request to commit pages triggered a heavy syntax highlighting operation.
  • Once the commit was pushed to git, even before the packaged release was available, requests from CI systems and Composer increased dramatically.
  • These combined factors resulted in the release packaging process itself being blocked on 500 errors, unable to populate a key db table in the middle of the pipeline process.
  • We mitigated this by blocking the most aggressive automated traffic that was repeatedly attempting to gather commit information.
  • This allowed us to complete the packaging process, and get the packaged release out. 
  • In the meantime, the load on the GitLab instance itself remained high, resulting in slowdowns and 500 errors for several hours, as it gradually cleared. 

Future mitigations: 

We are still evaluating potential mitigations for future release windows, but they may include one or more of the following strategies:

  • Improving log collection from our GitLab servers for better diagnosis of issues.
  • Enforcing static archiving on GitLab commit pages, either temporarily or permanently.
  • Investigating the possibility of separating web traffic from Git traffic for our GitLab instance, or at least to reduce load spikes and provide dedicated git resources to the packaging job. 
  • Dividing read-only traffic between the GitLab primary and the replica, for which we have a plan.
  • Deliberately redirect all non-cached traffic until packaging completes.

These mitigations should help ensure that the full release process can be completed within the specified window.

Communication

The final aspect of this release that was disruptive was communication. We recognize that communication gets sparse whenever there is an unexpected delay, because the team is fully occupied trying to resolve any issues as quickly as possible. In future, we'll try to designate a person to handle communications, so that if we have to update the expected release time, we do so in a timely manner.

As a long-term goal, we know our international community members would benefit from more peace of mind when updating sites. We hope a combination of the in-development Automatic Updates initiative and the Drupal Steward program for highly critical vulnerabilities can help these international teams. 

May 26 2021
May 26

Update: 2021-06-11: Added CVE-2021-33829 identifier

Drupal core uses the third-party CKEditor library. This library has an error in parsing HTML that could lead to an XSS attack. CKEditor 4.16.1 and later include the fix.

Update: 2021-06-11: More details are available on CKEditor's blog.

Users of the CKEditor library via means other than Drupal core should update their 3rd party code (e.g. the WYSIWYG module for Drupal 7). The Drupal Security Team policy is not to alert for issues affecting 3rd party libraries unless those are shipped with Drupal core. See DRUPAL-SA-PSA-2016-004 for more details.

This issue is mitigated by the fact that it only affects sites with CKEditor enabled.

May 25 2021
May 25

Update: After some delays, the new estimate for this release is 20:00UTC on May 26th, 2021. Apologies for the inconvenience.

There will be a security release of Drupal Core 8.9.x, and 9.1.x on May 26th, 2021 between 16:00 - 18:00 UTC. This Public Service Advisory 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.

The security risk of the advisory is currently rated as Moderately Critical.
This is not a mass-exploitable vulnerability as far as the security team is currently aware.


Given that this is a moderately critical vulnerability and is not believed to be mass exploitable it is not covered by Drupal Steward partners.

Apr 21 2021
Apr 21

Drupal core's sanitization API fails to properly filter cross-site scripting under certain circumstances.

Not all sites and users are affected, but configuration changes to prevent the exploit might be impractical and will vary between sites. Therefore, we recommend all sites update to this release as soon as possible.

Jan 20 2021
Jan 20

The Drupal project uses the pear Archive_Tar library, which has released a security update that impacts Drupal. For more information please see:

Exploits may be possible if Drupal is configured to allow .tar, .tar.gz, .bz2, or .tlz file uploads and processes them.

Nov 18 2020
Nov 18

Install the latest version:

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

Additionally, it's recommended that you audit all previously uploaded files to check for malicious extensions. Look specifically for files that include more than one extension, like filename.php.txt or filename.html.gif, without an underscore (_) in the extension. Pay specific attention to the following file extensions, which should be considered dangerous even when followed by one or more additional extensions:

  • phar
  • php
  • pl
  • py
  • cgi
  • asp
  • js
  • html
  • htm
  • phtml

This list is not exhaustive, so evaluate security concerns for other unmunged extensions on a case-by-case basis.

Sep 16 2020
Sep 16

Install the latest version:

Versions of Drupal 8 prior to 8.8.x are end-of-life and do not receive security coverage. Sites on 8.7.x or earlier should update to 8.8.10.

Sep 16 2020
Sep 16

Install the latest version:

Versions of Drupal 8 prior to 8.8.x are end-of-life and do not receive security coverage. Sites on 8.7.x or earlier should update to 8.8.10.

Jun 17 2020
Jun 17
Project: Drupal coreDate: 2020-June-17Security risk: Critical 15∕25 AC:Complex/A:None/CI:Some/II:Some/E:Theoretical/TD:AllVulnerability: Cross Site Request ForgeryCVE IDs: CVE-2020-13663Description: 

The Drupal core Form API does not properly handle certain form input from cross-site requests, which can lead to other vulnerabilities.

Solution: 

Versions of Drupal 8 prior to 8.8.x are end-of-life and do not receive security coverage. Sites on 8.7.x or earlier should update to 8.8.8.

Reported By: Fixed By: 
May 20 2020
May 20

The jQuery project released version 3.5.0, and as part of that, disclosed two security vulnerabilities that affect all prior versions. As mentioned in the jQuery blog, both are

[...] security issues in jQuery’s DOM manipulation methods, as in .html(), .append(), and the others. Security advisories for both of these issues have been published on GitHub.

Those advisories are:

These vulnerabilities may be exploitable on some Drupal sites. This Drupal security release backports the fixes to the relevant jQuery functions, without making any other changes to the jQuery version that is included in Drupal core or running on the site via some other module such as jQuery Update. It is not necessary to update jquery_update on Drupal 7 sites that have the module installed.

Backwards-compatibility code has also been added to minimize regressions to Drupal sites that might rely on jQuery's prior behavior. With jQuery 3.5, incorrect self-closing HTML tags in JavaScript for elements where end tags are normally required will encounter a change in what jQuery returns or inserts. To minimize that disruption in 8.8.x and earlier, this security release retains jQuery's prior behavior for most safe tags. There may still be regressions for edge cases, including invalidly self-closed custom elements on Internet Explorer.

(Note: the backwards compatibility layer will not be included in the upcoming Drupal 8.9 and 9.0 releases, so Drupal 8 and 9 modules, themes, and sites should correct tags in JavaScript to properly use closing tags.)

If you find a regression caused by the jQuery changes, please report it in Drupal core's issue queue (or that of the relevant contrib project). However, if you believe you have found a security issue, please report it privately to the Drupal Security Team.

Dec 18 2019
Dec 18
  • If you are using Drupal 8.7.x, you should upgrade to Drupal 8.7.11.
  • If you are using Drupal 8.8.x, you should upgrade to Drupal 8.8.1.

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

Alternatively, you may mitigate this vulnerability by unchecking the "Enable advanced UI" checkbox on /admin/config/media/media-library. (This mitigation is not available in 8.7.x.)

Additional information

All advisories released today:

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

Dec 18 2019
Dec 18

Install the latest version:

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

To mitigate this issue in any version of Drupal 8, you can also block access to install.php if it's not required.

Additional information

All advisories released today:

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

Feb 25 2019
Feb 25

This PSA is now out of date. Read: Extending Drupal 7's End-of-Life - PSA-2020-06-24

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:

  • You must have experience in the public issue queue supporting Drupal 7 core or Drupal 7 Modules. You should be able to point to a history of such contribution. One way to measure this is issue credits, but there are other ways. You must continue this throughout your enrollment in the program. If you have other ways to show your experience, feel free to highlight them.
  • You must make a commitment to the Security Team, the Drupal Association, and your customers that you will remain active in this program for 3 years.
  • As a partner, you must contribute to at least 20% of all Drupal 7 Vendor Extended Support module patches and 80% of D7ES core patches in a given year. (Modules that have been moved into core in Drupal 8 count as part of core metrics in Drupal 7) .
  • Any organization involved in this program must have at least 1 member on the Drupal Security Team for at least 3 months prior to joining the program and while a member of the program. (See How to join the Drupal Security Team for information.) This person will need a positive evaluation of their contributions from the Security Working Group.
  • Payment of an Drupal 7 Vendor Extended Support annual fee for program participation is required (around $3000 a year). These fees will go to communication tools for the Drupal 7 Vendor Extended Support vendors and/or the greater community.
  • Payment of a $450 application fee is required.
  • Your company must provide paid support to Drupal 7 clients. This program is not for companies that don't provide services to external clients.
  • Application review process:

  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

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.

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

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