Vendors shipping products based on Chromium might wish to rate the severity of security issues in the products they release. This document contains guidelines for how to rate these issues. Check out our security release management page for guidance on how to release fixes based on severity.
Any significant mitigating factors, such as unusual or additional user interaction, or running Chrome with a specific command line flag or non-default feature enabled, may reduce an issue’s severity by one or more levels.
Conversely, we do not consider it a mitigating factor if a vulnerability applies only to a particular group of users. For instance, a Critical vulnerability is still considered Critical even if it applies only to Linux or to those users running with accessibility features enabled.
Also note that most crashes do not indicate vulnerabilities. Chromium is designed to crash in a controlled manner (e.g., with a
__debugBreak) when memory is exhausted or in other exceptional circumstances.
Critical severity issues allow an attacker to read or write arbitrary resources (including but not limited to the file system, registry, network, et c.) on the underlying platform, with the user's full privileges.
They are normally assigned priority Pri-0 and assigned to the current stable milestone (or earliest milestone affected). For critical severity bugs, SheriffBot will automatically assign the milestone.
For critical severity vulnerabilities, we aim to deploy the patch to all Chrome users in under 30 days.
Critical vulnerability details may be made public in 60 days, in accordance with Google's general vulnerability disclosure recommendations, or faster (7 days) if there is evidence of active exploitation.
Note that the individual bugs that make up the chain will have lower severity ratings.
High severity vulnerabilities allow an attacker to execute code in the context of, or otherwise impersonate other origins or read cross-origin data. Bugs which would normally be critical severity with unusual mitigating factors may be rated as high severity. For example, renderer sandbox escapes fall into this category as their impact is that of a critical severity bug, but they require the precondition of a compromised renderer. (Bugs which involve using MojoJS to trigger an exploitable browser process crash usually fall into this category).
They are normally assigned priority Pri-1 and assigned to the current stable milestone (or earliest milestone affected). For high severity bugs, SheriffBot will automatically assign the milestone.
For high severity vulnerabilities, we aim to deploy the patch to all Chrome users in under 60 days.
Medium severity bugs allow attackers to read or modify limited amounts of information, or are not harmful on their own but potentially harmful when combined with other bugs. This includes information leaks that could be useful in potential memory corruption exploits, or exposure of sensitive user information that an attacker can exfiltrate. Bugs that would normally be rated at a higher severity level with unusual mitigating factors may be rated as medium severity.
They are normally assigned priority Pri-1 and assigned to the current stable milestone (or earliest milestone affected). If the fix seems too complicated to merge to the current stable milestone, they may be assigned to the next stable milestone.
Low severity vulnerabilities are usually bugs that would normally be a higher severity, but which have extreme mitigating factors or highly limited scope.
They are normally assigned priority Pri-2. Milestones can be assigned to low severity bugs on a case-by-case basis, but they are not normally merged to stable or beta branches.
If the bug can't impact Chrome users by default, this is denoted instead by the Security-Impact_None label. See the security labels document for more information. The bug should still have a severity set according to these guidelines.