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.
Allows an attacker run arbitrary code with the user's privileges in the normal course of browsing. Critical severity vulnerabilities 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.
- An uncontrolled buffer overflow in the browser process, especially if a malicious web site can directly control the contents of the buffer.
- Most memory safety issues in the browser process, unless the possibility of arbitrary code execution can be ruled out.
- Not all crashes indicate a critical vulnerability. Chromium is designed to crash in a controlled manner (e.g., with a __debugBreak) when memory is exhausted or in other exceptional circumstances.
- An arbitrary code execution vulnerability that requires unusual user action (e.g. printing a certificate error message or running Chrome with a specific command-line flag) should typically not be rated as critical.
Allows an attacker to read or modify confidential data belonging to other web sites. High severity vulnerabilities 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.
- A bug that allows circumvention of the same-origin policy.
- A bug that allows arbitrary code execution within the confines of the sandbox
- Example: many use-after-frees (UAFs).
- Bugs that interfere with browser security features.
- Examples: control over the apparent origin in the omnibox, or showing a green lock icon on an HTTP page. (Note that the status bubble is not a security indicator.)
- If there signals that a savvy user could use to tell the attack from normal browser operation (e.g. a fullscreen spoof that can't replicate the user's real OS menu bar), downgrade to lower severity.
Allows an attacker to obtain limited amounts of information. Medium severity vulnerabilities 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, or if the issue does not seem severe enough to warrant it due any mitigating factors, assign it to the next stable milestone.
- Bug that allows an attacker to enumerate recently visited URLs.
- Note that some cache timing attacks on individual resources can't be mitigated without slowing down or breaking the web.
- Bugs that are not harmful independently, but can be combined with other bugs to cause harm.
- Example: ignoring a "do not cache" directive might not itself be harmful but might facilitate other attacks.
- Any bug that might be High Severity, but requires unusual user action.
- Example: triggering the bug requires terminating a tab's process while in full-screen mode.
- Out-of-bounds memory reads inside the confines of the sandbox.
Allows an attacker temporary control over non-critical browser features. Low severity vulnerabilities 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.
- A bug that allows an attacker to hang the browser.
- Note that tab hangs are not security issues if they can be resolved simply by closing the tab.
Note that Denial of Service bugs used to be considered low severity, but now they are not considered security bugs at all.