Red Hat Customer Portal

Skip to main content

Severity Ratings

Understanding Red Hat security ratings

Red Hat Product Security rates the impact of security issues found in Red Hat products using a four-point scale (Low, Moderate, Important, and Critical), as well as Common Vulnerability Scoring System (CVSS) base scores. These provide a prioritized risk assessment to help you understand and schedule upgrades to your systems, enabling informed decisions on the risk each issue places on your unique environment.

The four-point scale tells you how serious Red Hat considers an issue to be, helping you judge the severity and determine what the most important updates are. The scale takes into account the potential risk based on a technical analysis of the exact flaw and its type, but not the current threat level; a given rating will not change if an exploit or worm is later released for a flaw, or if one is available before the release of a fix.

  Severity Rating Description
Critical impact This rating is given to flaws that could be easily exploited by a remote unauthenticated attacker and lead to system compromise (arbitrary code execution) without requiring user interaction. These are the types of vulnerabilities that can be exploited by worms. Flaws that require an authenticated remote user, a local user, or an unlikely configuration are not classed as Critical impact.
Important impact This rating is given to flaws that can easily compromise the confidentiality, integrity, or availability of resources. These are the types of vulnerabilities that allow local users to gain privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication, allow authenticated remote users to execute arbitrary code, or allow remote users to cause a denial of service.
Moderate impact This rating is given to flaws that may be more difficult to exploit but could still lead to some compromise of the confidentiality, integrity, or availability of resources, under certain circumstances. These are the types of vulnerabilities that could have had a Critical impact or Important impact but are less easily exploited based on a technical evaluation of the flaw, or affect unlikely configurations.
Low impact This rating is given to all other issues that have a security impact. These are the types of vulnerabilities that are believed to require unlikely circumstances to be able to be exploited, or where a successful exploit would give minimal consequences.

A Red Hat security advisory can contain fixes for more than one vulnerability and for packages for more than one product (such as both Red Hat Enterprise Linux 5 and 6). Each issue in an advisory has an impact rating for each product. The overall severity of an advisory is the highest severity out of all the individual issues, across all the products the advisory targets. For simplicity, advisories only show the overall severity (except for kernel advisories, which list the severity of each issue). The advisories contain links to the relevant entries in Red Hat's bug-tracking system, where you can examine individual impacts and additional commentary.

When a technology—enabled and most likely used by default—completely blocks the exploitation of a particular vulnerability across all architectures, we will adjust the severity level. When a technology reduces the risk of a vulnerability, we may adjust the severity level and give an explanation of the decision in the bug-tracking entry.

Common Vulnerability Scoring System (CVSS)

Common Vulnerability Scoring System (CVSS) base scores provide additional guidance about a vulnerability, giving a detailed severity rating by scoring the constant aspects of a vulnerability: Access Vector, Access Complexity, Authentication, Confidentiality, Integrity, and Availability.

CVSS version 2 base metrics are available for all vulnerabilities from 2009 onwards, as well as selected earlier vulnerabilities. In 2016 Red Hat adopted the CVSS v3 standard, and all vulnerabilities going forward will use version 3 for scoring. These scores are found on the CVE pages (linked to from the References section of each Red Hat Security Advisory) and also from our Security Measurements page.

This information is very useful, but Red Hat does not solely use the CVSS rating to determine the priority with which flaws are fixed. It is used as a guideline to identify key metrics of a flaw, but the priority for which flaws are fixed is determined by the overall impact of the flaw using the aforementioned four-point scale.

CVSS v3 Base Metrics

The CVSS v3 base metrics group covers the constant aspects of a vulnerability:

  • Attack Vector (AV) - Expresses the "remoteness" of the attack and how the vulnerability is exploited.
  • Attack Complexity (AC) - Speaks to how hard the attack is to execute and what factors are needed for it to be successful. (The older Access Complexity metric is now split into Attack Complexity and User Interaction.).
  • User Interaction (UI) - Determines whether the attack require an active human to participate or if the attack can be automated.
  • Privileges Required (PR) - Documents the level of user authentication required for attack to be successful (replaces older Authentication metric).
  • Scope (S) - Determines whether an attacker can affect a component that has a different level of authority.
  • Confidentiality (C) - Determines whether data can be disclosed to non-authorized parties and, if so, to what level.
  • Integrity (I) - This measures how trustworthy the data is and how far it can be trusted to not be modified by unauthorized users.
  • Availability (A) - This metric is concerned with data or services being accessible to authorized users when they need to access it.

A formula translates these measurements into a single, numerical base score, ranging from 0.0 (no risk) to 10.0 (highest risk). Refer to Common Vulnerability Scoring System v3.0: User Guide for detailed descriptions of the base metrics.

How Red Hat Uses CVSS v3 Base Metrics

We aim to comply with the CVSS v3 standard when allocating base scores. There are circumstances where it may not be obvious why a particular score was chosen. The following are some common vulnerability types with our interpretation and typical scoring:


It is not always possible to know how third-party applications use libraries, making it difficult to give accurate CVSS v3 base metrics for flaws in system libraries. When rating these flaws, we take into account the way the library is used by applications that we ship, but also look at other popular software that may use the library in a way that would cause an issue to be of higher severity, and adjust the score appropriately.

Web Browsers (and associated plug-ins)

There is a class of flaws in web browsers and their plug-ins that can allow a malicious web page to execute arbitrary code when the victim accesses the page. We rate these flaws as having Critical severity, even though they need some user interaction. Scoring these issues using CVSS v3 gives a base score of 6.3 (for example CVE-2016-1953) with the base metrics of CVSS:3.0/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:L. Because the desktop is running as a non-privileged user, the CVSS v3 Confidentiality, Integrity, and Availability impacts are all rated as Low not High.

Other Common Scores

Flaws where a local, unprivileged user can cause a kernel to crash (denial of service) typically score 6.2 (for example, CVE-2014-8173).

Flaws that allow a local, unprivileged user to escalate their privileges to root typically score 8.4 (for example, CVE-2014-9322).

Cross-site scripting flaws are generally scored as having low impact to Integrity, with no impact to Confidentiality or Availability, in line with scoring from other vendors and NVD. A typical score for these flaws is 6.1 (for example, CVE-2009-0153).

Base Score Variations Across Products

It is common for a given CVE-named vulnerability to have several different CVSS base metrics, depending on the product, version, and architecture. Examples of this include:

  • A vulnerability that only affected some architectures. For example, CVE-2007-6694 only affected PowerPC.
  • A vulnerability that is mitigated by source code protection mechanisms on some platforms. For example, CVE-2009-1252 could have led to arbitrary code execution on Red Hat Enterprise Linux 4, but it is only a denial of service on Red Hat Enterprise Linux 5.
  • A vulnerability that affected more than one application. For example, CVE-2009-0352 affected both Firefox (web browser) and Thunderbird (mail reader), but had a lower CVSS score and severity for Thunderbird.

If CVSS v3 base scores are significantly different across products, we give them separately wherever possible. If we do not split the score, we report the metric that gives the highest CVSS v3 base score (the worst-case outcome).

Differences Between NVD and Red Hat Scores

For open source software shipped by multiple vendors, the CVSS base scores may vary for each vendor's version, depending on the version they ship, how they ship it, the platform, and even how the software is compiled. This makes scoring of vulnerabilities difficult for third-party vulnerability databases, such as NVD, who can give only a single CVSS base score to each vulnerability.

These differences can cause the scores to vary widely. For example, NVD rates Firefox flaws as having High impact metrics because the Firefox application is also available for Microsoft Windows, where it is common that the user is running Firefox with administrator privileges. For Red Hat Enterprise Linux, we use Low impact metrics, as Firefox is most likely to be run as an unprivileged user.

For these reasons, we recommend that, whenever possible, you use a CVSS base score provided by Red Hat in preference to a score from a third party. Please let us know if you believe we have given an incorrect CVSS v3 base score for a particular vulnerability. We are happy to discuss the severity and update it if needed.