Security advisory process and permissions policy

What is a Security Advisory?

A security advisory is a public announcement managed by the Drupal Security Team which informs site owners about a reported security problem in Drupal core or a contributed project and the steps site owners should take to address it. (Usually this involves updating to a new release of the code that fixes the security problem.) The problem is kept secret until the advisory is ready to be released, at which point it is publicized widely so that site owners can address it quickly.

For examples, look through past security advisories for Drupal core and contributed projects.

Occasionally, the security team may issue a public service announcement on a Monday before a Wednesday security release, notifying users that a specific release is upcoming. This can be done for highly critical or critical issues which we feel might be easily turned into automated attacks.

Which Projects are Covered?

Covered contributed projects have a grey shield icon and “Stable releases for this project are covered by the security advisory policy.” note on their project page.

Project maintainers may opt into security advisory coverage when they meet the requirements:

• A maintainer with “write to VCS access” has applied to have the "vetted" role, and received it.
• The project is a full project, not sandbox projects.
• There are no known security issues, open issues tagged “security” for the project.
• New projects must wait 10 days before opting in.

If all the requirements are met, the maintainer can edit their project to opt into coverage. This policy changed in March 2017, all projects created before then are opted into security advisory coverage.

In rare cases, the Drupal Security Team can make exceptions. For example, shortening the 10 day waiting period if a project’s codebase is copied from a covered project.

Which Releases Get Security Advisories?

Drupal core

See Drupal core release cycle: major, minor, and patch releases for details about what Drupal Core versions are currently supported, and end of life dates.

Starting with the release of Drupal 8.6.0, two minor versions at a time receive security advisories, both the most recent minor and the previous minor. For example, Drupal 8.6.x will continue receiving security advisories until the release of Drupal 8.8.0, and 8.7.x will receive security advisories until the release of 8.9.0.

Contributed projects

Security advisories are only made for issues affecting stable releases (Y.x-Z.0 or higher / X.Y.0 or higher) in the supported major version branches. That means no security advisories for development releases (-dev), alphas, betas, or release candidates.

Support means both as supported by Drupal core (at the time of writing, Drupal 8.x and Drupal 7.x) and by the project maintainer via their project page.

The requirement for a stable release means that the Security Team will not create an advisory for "sandbox" projects nor projects hosted via external repositories such as some distributions.

We do not take the usage of a project into account to keep this policy clear for our users.

What About Vulnerabilities in External Libraries or Plugins?

Since security advisories are only issued for projects hosted on Drupal.org, no advisories will be issued for external libraries or plugins, even if a Drupal contributed project requires you to install an external library on your site as a requirement for using it.  This policy applies regardless of the method used to install the external library (for example, either manually or using a tool such as Composer).  See PSA-2011-002 for additional information.

Drupal core ships with copies of several external libraries that are included as part of the downloaded package (for example, the jQuery JavaScript library).  Since that code actually is hosted on Drupal.org, security advisories will be issued in the event of a vulnerability in one of those particular external libraries.

What About Vulnerabilities Which Require Advanced Permissions?

Another case where no security advisory is required is when an exploit requires one of the following permissions:

• Access site reports (a.k.a. "View site reports")
• Administer fields (added in Drupal 7.50)
• Administer filters
• Administer users
• Administer permissions
• Administer content types
• Administer modules
• Administer site configuration
• Administer views
• Translate interface
• Any other permission that is defined with restrict access set to TRUE. For more information about restrict access see PermissionHandler.php for Drupal 8 or hook_permission documentation for Drupal 7.

Any user with one of the above permissions can already take over the site or bypass various access restrictions on the site, so there is no meaningful added risk if a vulnerability is only accessible to a user with one of these permissions.

What about security issues that can't be exploited?

There are often instances where it is unlikely that an issue can be exploited on actual sites. In these cases the team considers several elements to determine whether the issue should be handled in the module's public queue or the private queue:

• If there is a way to exploit the issue by installing a contributed module then it should probably be handled in private.
• If the steps to exploit the issue are extremely complex it can more likely be handled in public.
• If the solution is likely to be controversial or difficult to get right then it is more likely it should be handled in public.
• If there is no known way to exploit the issue and it's difficult to imagine a way to exploit it without some other attack already in place (e.g. SQL injection) then the issue can probably be handled in public.
• If the issue is related to insecure cryptographic storage of site keys (e.g. they are stored in plain text in the database) that is disclosed or reasonably expected of the module then the issue can be handled in public. If a module stores sensitive user information in a non-encrypted format that should be handled as a private issue.

For example, an issue that requires a username that contains XSS cannot be exploited with core alone because core has validation on usernames. However, it is likely that a module importing users or making usernames from an external source (like distributed authentication) will allow non-standard usernames that might contain malicious characters. So, in the past there have been issues handled privately and with an Advisory to fix XSS in user names. On the other hand, an XSS issue related to other names (e.g. languages) that are unlikely to be entered/imported from an untrusted source can be handled in public.

Always report the issue to the team and let them make the decision on whether to handle in public or private.

How does the "Security update" taxonomy term relate to Security Advisories?

In addition to the list of security advisories there is also a taxonomy term for security updates. The security update term is part of the set of tools used to communicate security issues and plays a role in how the Update module (part of Drupal core in 6.x and above) displays update messages to site administrators. Module maintainers may use the "security update" tag even if no security advisory is created as a way to indicate a new release (perhaps from Alpha to Beta) where security issues were fixed even if it doesn't meet the criteria for sending a security advisory. Note that releases tagged "Security update" are not automatically published so you need to contact the security team to get it published.

The reason for this policy is not to try to hide vulnerabilities, but simply to provide a mechanism for alerting people to problems with developer-level releases that doesn't create the noise nor require the overhead of a normal security advisory.