Beginning today, Drupal core issues reported to the Security Team with risk levels that are "Not Critical", "Less Critical", or "Moderately Critical" may be treated as bugs in the public issue queue, not as private security issues requiring a security advisory and CVE.
Policy Change
The Security Team will use its discretion to handle some issues in public depending on the risk score, the severity of the impact, the difficulty to exploit, and any other mitigating factors.
We still encourage all security researchers to start by filing a private issue that can then be moved public later. Members of the Security Team also will sometimes unpublish a public issue and move it private as needed.
Drupal core issues with risk levels of "Critical" or "Highly Critical" will continue to be private security issues. Some issues with lower risk scores will also be handled privately at Security Team discretion, depending on their impact.
What are some examples?
Exactly which issues are moved into the public queue will be at the discretion of the Security Team members triaging the issue. Some examples of common categories follow.
Information disclosure
Information disclosure is when information that should be private can be seen outside of the intended private context.
A key difference between this and other kinds of security issues is that the circumstances in which it is a security risk often greatly reduce the risk of information being disclosed publicly.
Sometimes, the information being disclosed is already public on the internet without any explicit action from users. For example, if unpublished article teasers accidentally show in a listing accessible to anonymous users, these will be visible to anyone visiting the page including search engines and other crawlers. Keeping the information disclosure bug private does not keep the information itself private in these cases; it is already public.
Other times, metadata about an article like its title or URL is leaked only to users who already have content editing or similar permissions on a site, and via their normal workflows. The potential audience for the leaked information is very small, they may already be seeing it, the impact of learning that secret is likely low.
These issues often require significant active effort against an individual site to exploit. The amount of effort and individual-site nature make them less likely to be exploited.
Scenarios that would make the issue a security vulnerability are extremely uncommon. For example, a vulnerability might expose the content of a field under very specific circumstances. The contents of that field might only be considered important in rare circumstances. In those situations we would tend toward fixing the bug in public.
In scenarios when the information disclosure would represent a great risk to many sites we will not disclose publicly. For example, if you could get access to the passwords of users, or secret keys as an anonymous user, those issues would be handled privately with a security advisory.
Content injection
Content injection vulnerabilities exist when information from a URL ends up reflected in the HTML page, which can result in unwanted content being accessible from a domain. While these bugs are embarrassing, they do not allow other kinds of access unless paired with a cross-site scripting (XSS) or similar vulnerability.
Denial of service
Denial of service is an attack intended to render a site unusable, usually by saturating it with traffic. Certain categories of bugs sometimes make these attacks easier (for example, triggering code that takes a long time to run). However, they are often symptoms of scalability issues or type checking errors, which are routinely fixed in public.
What if sites I manage are concerned about these kinds of issues?
You should monitor the Drupal core issue queue for the 'Security' and 'Security improvements' tags and dedicate resources to helping fix those issues.
What should I do if I find a security issue that might fall under the above?
You should still report the issue privately to the Security Team so that they can verify it is not a symptom of a different security issue (such as access bypass or privilege escalation) and that it meets the guidelines above that allow it to be handled in public. The Security Team may then have you open a public issue and close the private report.
What will happen to issues meeting these criteria that are already open in the private issue tracker?
These will be transferred to the public issue queues for their respective projects over time.
Coordinated By:The following people contributed to this public service announcement.
- xjm of the Drupal Security Team
- Michael Hess of the Drupal Security Team
- Nathaniel Catchpole of the Drupal Security Team
- Greg Knaddison of the Drupal Security Team
- Lee Rowlands of the Drupal Security Team
- cilefen of the Drupal Security Team
- Cathy Theys of the Drupal Security Team