Security advisory process and permissions policy

Last updated on
3 November 2017

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 Releases Get Security Advisories?

Security advisories are only made for issues affecting stable releases (Y.x-Z.0 or higher) in the supported major version branches (at the time of writing Drupal 7.x and Drupal 8.x). That means no security advisories for development releases (-dev), ALPHAs, BETAs or RCs.

Support means both as supported by Drupal core and by the project maintainer via their project page.

The requirement for a full 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, 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, 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 site configuration
  • Administer views
  • Translate interface
  • Any other permission that is defined with "restrict access" set to TRUE -- see the hook_permission documentation for more information

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.