Security Advisory policy

What is a Security Advisory?

A security advisory is a public announcement managed by the Backdrop Security Team which informs site owners about a reported security problem in Backdrop 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 project 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.

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?

All projects in the backdrop-contrib Github group are covered by the security advisory policy.  All project maintainers opt into security advisory coverage for all of their projects when they agree to the Backdrop Contributed Project Agreement. 

CVE Assignment

All security fixes for Backdrop Core that warrant Security Advisories will get Common Vulnerabilities and Exposures identifiers. If the fix is common to Drupal or any included library like jQuery or CKEditor, the CVE for the source project will be referenced.

At present, we are following Drupal's CVE assignment policy for contributed projects: CVE's will be assigned for contributed projects that get SA's and have over 10,000 reported installs. This is subject to change at any time. 

Which Releases Get Security Advisories?

Backdrop core

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

Two minor versions receive security advisories at a time; both the most recent minor and the previous minor. For example, Backdrop 1.20.x will continue receiving security advisories until the release of Backdrop 1.21.0.

Contributed projects

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

Supported major version branches include:

• branches supported by Backdrop core (at the time of writing, Backdrop 1.x only. When 2.x is released both 2.x and 1.x will be supported until Backdrop 3.x is released)
• branches supported by the project maintainer, as indicated via the project page on backdropcms.org.

The Security Team will not create an advisory for projects hosted via external repositories, such as some distributions.

Vulnerabilities in External Libraries or Plugins

Security advisories will be issued in the event of a vulnerability in any external library that has been bundled into either Backdrop core (for example, the jQuery JavaScript library) or any contributed project. 

No security advisory will be issued if a project requires you to download and install an external library separately. This holds even if a Backdrop contributed project requires you to install an external library as a requirement for using that project. This policy applies regardless of the method used to install the external library (for example, either manually or using a tool such as drush, bee, or Composer)

Vulnerabilities Which Require Advanced Permissions

No security advisory is required when an exploit requires advanced permissions. Any person with one of the following 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 the following permissions.

• Administer contact forms and contact form settings
• Administer content types
• Administer fields
• Administer file types
• Administer Flexible Templates
• Administer layouts
• Administer modules
• Administer permissions
• Administer site configuration
• Administer software updates
• Administer text formats and filters
• Administer themes
• Administer user accounts
• Administer views
• Assign user roles
• Bypass content access control
• Bypass file access control
• Synchronize, import, and export configuration
• Translate interface
• Use the Raw HTML text format
• View site reports
• Any other permission that is defined with restrict access set to TRUE. For more information about restrict access see hook_permission documentation.

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 security 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, 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, 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), 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.