Upgrade Your Drupal Skills

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

See Advanced Courses NAH, I know Enough
Nov 30 2021
Nov 30

As of November 17, 2021, the Drupal core version 8 series has reached end-of-life. This means that all releases of Drupal 8 core (with 8.y.x version numbers) and Drupal contributed project releases that are compatible with only Drupal 8 will be marked unsupported as they no longer have security team support.

Drupal 8.0.0 was first released on November 9, 2015. The last version was released on November 17, 2021.

All Drupal 8 site owners must upgrade to Drupal 9 to receive security updates and bug fixes. The Drupal Association will also disable testing with unsupported versions of Drupal.

Security issues that only affect Drupal 8 (and not Drupal 9 or Drupal 7) will be made public and sites are at risk of having these issues exploited if they do not upgrade.

What about Drupal 7 and Drupal 9?

Contributed projects like themes and modules will still receive security advisories if they are compatible with either Drupal 7 or 9 and have opted in to security coverage.

Drupal 7's end-of-life is currently scheduled for November of 2022, and it will receive security updates until then. Drupal 9's end-of-life is scheduled for November of 2023. For more information on release schedules, see the core release cycle overview.

Nov 17 2021
Nov 17

The Drupal project uses the CKEditor library for WYSIWYG editing. CKEditor has released a security update that impacts Drupal, along with a hotfix for that update.

Vulnerabilities are possible if Drupal is configured to allow use of the CKEditor library for WYSIWYG editing. An attacker that can create or edit content (even without access to CKEditor themselves) may be able to exploit one or more Cross-Site Scripting (XSS) vulnerabilities to target users with access to the WYSIWYG CKEditor, including site admins with privileged access.

For more information, see CKEditor's security advisories:

This advisory is not covered by Drupal Steward.

Sep 15 2021
Sep 15

Under some circumstances, the Drupal core JSON:API module does not properly restrict access to certain content, which may result in unintended access bypass.

Sites that do not have the JSON:API module enabled are not affected.

This advisory is not covered by Drupal Steward.

Sep 15 2021
Sep 15

The QuickEdit module does not properly check access to fields in some circumstances, which can lead to unintended disclosure of field data.

Sites are only affected if the QuickEdit module (which comes with the Standard profile) is installed.

This advisory is not covered by Drupal Steward.

Sep 15 2021
Sep 15

Drupal's JSON:API and REST/File modules allow file uploads through their HTTP APIs. The modules do not correctly run all file validation, which causes an access bypass vulnerability. An attacker might be able to upload files that bypass the file validation process implemented by modules on the site.

This vulnerability is mitigated by three factors:

  1. The JSON:API or REST File upload modules must be enabled on the site.
  2. An attacker must have access to a file upload via JSON:API or REST.
  3. The site must employ a file validation module.

This advisory is not covered by Drupal Steward.

Also see GraphQL - Moderately critical - Access bypass - SA-CONTRIB-2021-029 which addresses a similar vulnerability for that module.

Sep 15 2021
Sep 15

The QuickEdit module does not properly validate access to routes, which could allow cross-site request forgery under some circumstances and lead to possible data integrity issues.

Sites are only affected if the QuickEdit module (which comes with the Standard profile) is installed. Removing the "access in-place editing" permission from untrusted users will not fully mitigate the vulnerability.

This advisory is not covered by Drupal Steward.

Sep 15 2021
Sep 15

The Drupal core Media module allows embedding internal and external media in content fields. In certain circumstances, the filter could allow an unprivileged user to inject HTML into a page when it is accessed by a trusted user with permission to embed media. In some cases, this could lead to cross-site scripting.

This advisory is not covered by Drupal Steward.

Also see Entity Embed - Moderately critical - Cross Site Request Forgery - SA-CONTRIB-2021-028 which addresses a similar vulnerability for that module.

Updated 18:15 UTC to clarify text.

Aug 12 2021
Aug 12

Install the latest version:

Versions of Drupal 8 prior to 8.9.x and versions of Drupal 9 prior to 9.1.x are end-of-life and do not receive security coverage.

Drupal 7 core is not affected, although Drupal 7, 8, and 9 site owners should review their site following the protocol for managing external libraries and plugins previously suggested by the Drupal Security Team, as contributed projects may use additional CKEditor plugins not packaged in Drupal core.

Aug 09 2021
Aug 09

The Drupal Security Team will be coordinating a security release for Drupal core 8.9, 9.1, and 9.2 this week on Thursday, August 12, 2021.

We are issuing this PSA in advance because August 12, 2021 is not a security window in the regular Drupal security release window schedule, so there would not normally be any security release on this date.

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

Drupal 7 core is not affected, although Drupal 7 site owners should review their site following the protocol for managing external libraries and plugins previously suggested by the Drupal Security Team.

Because this is a moderately critical release for a vendor library update, it is not covered by the Drupal Steward program. (For covered releases, the Drupal Steward program provides an added layer of protection—so that site owners can install the update on their own schedule. For more information consult drupal.org/steward.)

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 all 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 25 2020
Nov 25

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

Multiple vulnerabilities are possible if Drupal is configured to allow .tar, .tar.gz, .bz2, or .tlz file uploads and processes them.

To mitigate this issue, prevent untrusted users from uploading .tar, .tar.gz, .bz2, or .tlz files.

This is a different issue than SA-CORE-2019-012. Similar configuration changes may mitigate the problem until you are able to patch.

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.

Once a site running Workspaces is upgraded, authenticated users may continue to see unauthorized workspace content that they accessed previously until they are logged out.

If it is important for the unintended access to stop immediately, you may wish to end all active user sessions on your site (for example, by truncating the sessions table). Be aware that this will immediately log all users out and can cause side effects like lost user input.

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.

In addition to updating Drupal core, sites that override \Drupal\Core\Form\FormBuilder's renderPlaceholderFormAction() and/or buildFormAction() methods in contrib and/or custom code should ensure that appropriate sanitization is applied for URLs.

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.

If you were previously relying on Drupal's AJAX API to perform trusted JSONP requests, you'll either need to override the AJAX options to set "jsonp: true", or you'll need to use the jQuery AJAX API directly.

If you are using jQuery's AJAX API for user-provided URLs in a contrib or custom module, you should review your code and set "jsonp: false" where this is appropriate.

Updates

Drupal 7 sites should also pass such URLs through the new Drupal.sanitizeAjaxUrl() function.

The update to Drupal 7 is likely to cause a regression in AJAX functionality on sites which use jQuery 1.5 (for example via the jQuery Update module). This issue seems to specifically affect jQuery 1.5; the version included in Drupal 7 core (1.4.4) and versions 1.6 and later do not suffer from the regression.

Jun 24 2020
Jun 24

Previously, Drupal 7's end-of-life was scheduled for November 2021. Given the impact of COVID-19 on budgets and businesses, we will be extending the end of life until November 28, 2022. The Drupal Security Team will continue to follow the Security Team processes for Drupal 7 core and contributed projects.

However, this means extra work from the Drupal community at large and the security team in particular to review security reports, create patches, and release security advisories for Drupal 7. This community effort will give site owners more time while budgets recover, but the organizations that sponsor security team members and the individual security team members who volunteer their time could use your support. If you can, please donate to support the end-of-life extension.

Drupal 8 will still be end-of-life on November 2, 2021, due to Symfony 3's end of life. However, since the upgrade path from Drupal 8 to Drupal 9 is much easier, we don't anticipate the same impact on end-users.

What does this mean for my Drupal 7 site?

You can continue to run the site and get security updates via the normal channels and processes. This will give you an extra year to work on converting your site to Drupal 9.

Do I need to upgrade to Drupal 8 before I upgrade to Drupal 9?

Migrating directly from Drupal 7 to Drupal 9 is supported with the core Migrate module. Read more on preparing a Drupal 7 site for Drupal 9.

How can I help?

Consider donating to support this effort. If you are a representative of a large end-user of Drupal, we'd love you to join the Drupal Association and the security team as a partner.

You can also consider getting more involved in fixing issues in the issue queue or joining the Security Team as a way to support the effort.

What about Drupal 7 Vendor Extended Support?

The extended support will now run from November 2022 until November 2025. You can read more about the Drupal 7 Vendor Extended Support program.

What about contributed projects?

The Security Team will continue to follow the Security Team processes for contributed projects. Contributed project maintainers are asked to consider supporting existing Drupal 7 releases if they are able.

Jun 17 2020
Jun 17

JSON:API PATCH requests may bypass validation for certain fields.

By default, JSON:API works in a read-only mode which makes it impossible to exploit the vulnerability. Only sites that have the read_only set to FALSE under jsonapi.settings config are vulnerable.

Jun 17 2020
Jun 17

Drupal 8 and 9 have a remote code execution vulnerability under certain circumstances.

An attacker could trick an administrator into visiting a malicious site that could result in creating a carefully named directory on the file system. With this directory in place, an attacker could attempt to brute force a remote code execution vulnerability.

Windows servers are most likely to be affected.

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

Drupal 7 has an Open Redirect vulnerability. For example, a user could be tricked into visiting a specially crafted link which would redirect them to an arbitrary external URL.

The vulnerability is caused by insufficient validation of the destination query parameter in the drupal_goto() function.

Other versions of Drupal core are not vulnerable.

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.

Mar 18 2020
Mar 18

Install the latest version:

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

The CKEditor module can also be disabled to mitigate the vulnerability until the site is updated.

Note for Drupal 7 users

Drupal 7 core is not affected by this release; however, users who have installed the third-party CKEditor library (for example, with a contributed module) should ensure that the downloaded library is updated to CKEditor 4.14 or higher, or that CDN URLs point to a version of CKEditor 4.14 or higher. Disabling all WYSIWYG modules can mitigate the vulnerability until the site is updated.

Dec 18 2019
Dec 18

The Drupal project uses the third-party library Archive_Tar, which has released a security improvement that is needed to protect some Drupal configurations.

Multiple vulnerabilities are possible if Drupal is configured to allow .tar, .tar.gz, .bz2 or .tlz file uploads and processes them.

The latest versions of Drupal update Archive_Tar to 1.4.9 to mitigate the file processing vulnerabilities.

Edited to clarify the nature of the upstream release.

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.

Sep 04 2019
Sep 04

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.

May 07 2019
May 07

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

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.

Feb 19 2019
Feb 19

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.

Jul 30 2018
Jul 30

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

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

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

Updates

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

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

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

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

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

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

Pages

About Drupal Sun

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

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

See the blog post at Evolving Web

Evolving Web