Security Severity Ratings/Client

The page pertains specifically to Client Applications: the Firefox web browser and mobile applications. For severity ratings for Mozilla Servers and Web Properties see Security_Severity_Ratings/Web. For details about Mozilla's bug bounty program please visit the bounty pages on our official site.

Severity Ratings

Severity ratings are used to indicate how severe we believe a bug is, and help provide guidance for its urgency and priority. Generally, we ask that they only be assigned by those with experience evaluating vulnerabilities in coordination with the security team. Presently we meet weekly to triage unclassified bugs.

Severity Ratings & Examples

The following items are keywords for the severity of an issue. sec-critical Critical vulnerabilities are urgent security issues that present an ongoing or immediate danger to Firefox users. There is no difference technically between a sec-critical and a sec-high, the difference is purely related to risk to users. Certain sec-critical vulnerabilities will cause an immediate dot-release to be issued. sec-critical Examples: Vulnerabilities actively exploited or publicly disclosed Certain types of vulnerabilities that are worm-able or exceptionally easy to exploit sec-high High-severity vulnerabilities are exploitable vulnerabilities which can lead to the widespread compromise of many users requiring no more than normal browsing actions. This includes most types of memory corruption, UXSS, cross-origin data leaks, and disclosure of other sensitive user data (including the user's IP address if a proxy is used.) sec-high Examples: Memory Safety issues, unless constrained e.g. by OOM conditions Theft of arbitrary files from local system Domain spoofing that allows arbitrary attacker controlled HTML, that a user can interact with, with an attacker-controlled URL in the actual address bar retaining normal badging and iconography JavaScript injection into browser chrome or other origins Failure to use TLS where needed to ensure confidential/security Sandbox escapes Proxy bypass Disclosure of detailed browsing history Launching of arbitrary local application with provided arguments Installation & execution of plugins/modules with chrome/native privileges, without user consent or via user dialog fatigue sec-moderate Moderate severity represents a fairly wide range of issues, that include: Vulnerabilities that would be considered a sec-high but require the user to perform unusual or complex actions or is limited in scope of affected users or capability, . Vulnerabilities which can provide an attacker additional information or positioning that could be used in combination with other vulnerabilities. Disclosure of sensitive information that represents a violation of privacy but by itself does not expose sensitive user data or uniquily identify the user. Many types of application Denial of Service. sec-moderate Examples: Memory Safety issues caused by OOM conditions; unless precise triggering of the condition can be shown Private Browsing Mode data leaks discoverable in the Browser UI (excepting user-directed actions like Bookmarks) Private Browsing Mode data leaks to disk on Desktop Disclosure of OS username Disclosure of more limited browsing history or browsing history through efficient and fast timing side channels Detection of arbitrary local files Launching of arbitrary local application without arguments The most severe or persistent types of DoS attacks, such as ones that require re-installing Firefox or can write unbounded storage to disk sec-low Low severity represents vulnerabilities that clearly have security implications, but typically are unexploitable, very limited in scope, or require excessive time or processing to exploit. sec-low Examples: Private Browsing Mode data leaks to disk on Mobile, excepting data cleaned on startup due to process reaping Techniques that put the browser into fullscreen mode without user interaction or while obscuring the notification Techniques that overlay the address bar with another piece of browser chrome to obscure it Techniques that cause a JavaScript alert or similar browser modal to be shown with a different domain than the one in the address bar (or one of its nested browsing contexts) Detection of a previous visit to a specific site, or when the affected site has a certain configuration Identification of users by profiling browsing behavior. Corruption of chrome dialogs or user input without the ability to spoof arbitrary messages Most Denial of Service vulnerabilities, such as triggering a release assertion or those requiring a browser restart Mitigating Circumstances If there are mitigating circumstances that severely constrain the vulnerability, then the issue could be reduced by one level of severity. Examples of mitigating circumstances include difficulty in reproducing due to very specific timing or load order requirements, a complex or unusual set of actions the user would have to take beyond normal browsing behaviors, or an unusual software configuration not provided by our Preferences page. As a rough guide, to be considered for reduction in severity, the vulnerability should be exploitable less than 10% of the time. If in the future, default software configurations change or techniques are developed to improve the reliability of the exploit it should be elevated back to the original rating.

Alternate Keywords

Sometimes none of the above severity ratings apply to a bug because it is not a vulnerability itself, but nonetheless is security-sensitive for other reasons and needs to be kept private. These keywords apply to those.

While we request that only the security team assign sec-high and similar ratings, we encourage you tag things sec-want and sec-audit if you feel it applies.

Alternate Keywords & Examples

sec-other sec-other is used for bugs that are not themselves exploitable security issues but may contain information about other security-sensitive issues that needs to be kept confidential. Note: if the private information is not related to security issues the bug should use "employee confidential" or some other group instead of "security-sensitive" sec-other Examples: Gaps in fuzzing coverage to be addressed Meta bugs tracking a group of related security issues A non-security bug where an independent security issue was discovered during the investigation. The separate security issue should be addressed in a new bug, but the original issue needs to remain hidden until the security issue is resolved. sec-audit Bugs marked sec-audit are typically for tasks to investigate a particular component of concern, or pattern of concern. It should NEVER be used for an actual, identified vulnerability. Either a sec-audit bug should cause additional security bugs to be opened for specific instances, or a specific bug should cause a sec-audit bug to be opened for investigating variants of the original. sec-audit Examples: Look for pattern x in library y Audit file z for string buffer abuse. sec-vector Flaws not in Mozilla controlled software, but can cause security problems for Mozilla users. sec-vector Examples: Bugs in plugins Bugs in system libraries used by Firefox sec-want New features or improvement ideas related to security. As with sec-audit, it should NEVER be applied to an actual vulnerability; but a sec-want may cause new bugs to be opened for specific vulnerabilities, or a vulnerability may spawn a follow-up bug tagged sec-want. sec-want Examples: User interface refinements Security-relevant standards improvements or implementation Support for new types of authentication Code refactoring / cleanup

A historical keyword is sec-incident, which is no longer used.

Additional Security Keywords, Whiteboard Tracking Tags & Flags

In addition to characterizing the severity of an issue with the sec- keywords, we also have sub-type keywords, whiteboard tags (standardized string), and flags we can use to further characterize a security issue.

csectype- Keywords

csectype- keywords are assigned to bugs to indicate the type of a vulnerability. Ideally these would be assigned to every vulnerability, but frequently they are not. While we request that only the security team assign sec-high and similar ratings, if you feel you can identify the type of a security bug we encourage you to classify it yourself.

Code	Description
csectype-bounds	client security issues due to incorrect boundary conditions (read or write)
csectype-clickjacking	client security issues due to techniques that cause a user to unintentionally click or tap on a browser control, either by obscuring the true target of the click or by causing the target to appear by surprise in place of the item the user intended to click or tap
csectype-disclosure	client issues that cause disclosure of sensitive user data or personal information (see also csectype-side-channel and csectype-sop)
csectype-dos	client Denial of Service issues (use wsec-dos for web server denial of service as these tend to be more severe)
csectype-framepoisoning	client crashes caused by dereferencing a poisoned (deleted) nsIFrame object (presumed to be limited to a Denial of Service)
csectype-intoverflow	client security issues due to integer overflow
csectype-jit	client security issues due to JIT miscompilation or similar
csectype-mitigation-bypass	client security issues that allow malicious content to evade protections provided by web security features like CSP and <iframe sandbox>, or user-abuse protections like the popup blocker
csectype-nullptr	client crashes due to a guaranteed null dereference (do not use for near-null crashes with a content-controlled offset)
csectype-oom	client crashes or hangs that occurs in Out Of Memory conditions
csectype-other	client security issues that don't fit into other categories
csectype-priv-escalation	client privilege escalation security issues
csectype-race	client security issues due to a race condition
csectype-sandbox-escape	client security issues where a low-privilege process can cause memory corruption or arbitrary code execution in a higher-privilege processs (for example, through malformed IPC messages or Shared Memory)
csectype-side-channel	Disclosure of sensitive information or state through side-effects (typically, timing)
csectype-sop	violations of the client Same Origin Policy including Universal-XSS (see also csectype-side-channel for less severe "leaks")
csectype-spoof	client security issues due to UI Redress attacks or manipulation of the browser UI to fool users into taking the wrong action (excluding csectype-clickjacking issues)
csectype-uaf	client security issues due to a use-after-free
csectype-undefined	client security issues—or potential issues—due to undefined compiler behavior
csectype-uninitialized	client security issues due to use of uninitialized memory
csectype-wildptr	client security issues due to pointer misuse not otherwise covered (see csectype-uaf, csectype-uninitialized, csectype-intoverflow, csectype-bounds)

Whiteboard Tags

Code	Description
[bad-ram?]	This indicates crashes identified that have no apparant cause and fit the profile of potential bit-flips caused by bad memory.
[pixel-stealing]	This indicates vulnerabilities related to side-channel attacks on cross-origin resources.
[fingerprinting]	This indicates user privacy concerns relating to fingerprinting, or web breakage detected from fingerprinting defenses.

Flags

Flag	Description	Settings
sec-bounty	Shows the status of a bug with regards to a bounty payout per our bounty guidlines	Setting Description '?' Bug is nominated for review by the bounty committee '+' Bug has been accepted and a payment will be made '-' Bug does not meet criteria and a payment will not be made
sec-bounty-hof	Shows the status of a bug with regards to a bounty hall of fame entry	Setting Description '?' Bug is nominated for review by the bounty committee '+' Bug has been accepted and an entry in the hall of fame will occur '-' Bug does not meet criteria and a hall of fame entry will not be made