For Developers‎ > ‎

Severity Guidelines for Security Issues

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.

Critical 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 vulnerabilities, we aim to have all users patched in under 30 days. We recognize that 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.

Examples:
  • 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.
Notes:
  • 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.


High Severity

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

Examples:
  • A bug that allows circumvention of the same-origin policy.
  • A bug that allows arbitrary code execution within the confines of the sandbox, e.g. many use-after-frees (UAFs).
  • Bugs that interfere with browser security features. E.g. A bug that disrupts the location bar and lock icon. (Note that the status bubble is not a security indicator.)

Medium 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).

Examples:
  • Bug that allows an attacker to enumerate recently visited URLs.
  • Bugs that are not harmful independently, but can be combined with other bugs to cause harm.  For 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 (such as terminating a tab's process while in full-screen mode).
  • Out-of-bounds memory reads inside the confines of the sandbox.


Low Severity

Allows an attacker temporary control over non-critical browser features. Low severity vulnerabilities are normally assigned priority Pri-2 and assigned to the next stable milestone.

Examples:
  • 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.