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 6.x and Drupal 7.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 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 filters
- Administer users
- Administer permissions
- Administer content types
- Administer site configuration
- Administer views
- Translate interface
- (Drupal 7 and higher) 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.
(*) Since this changed between Drupal 6 and 7, a Drupal 7 issue in which "restrict access" is set to TRUE (for permissions also present in Drupal 6) will justify a Drupal 6 advisory as well.
What about security issues that can't be exploited?
There are often instances where it is unlikely that an issue can be exploited via core or contributed. In these cases the team considers several elements to consider 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 an SA. 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 SA.