Severity ratings

Understanding Red Hat security ratings

Red Hat Product Security rates the severity of security issues found in Red Hat products using a four-point scale (Low, Moderate, Important, and Critical), as well as including a separate Common Vulnerability Scoring System (CVSS) base score. These scoring systems 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 the most important updates. The scale takes into account the potential risk based on a technical analysis of the exact flaw and its type. The risk level of a flaw does not change if an exploit or worm is later released for a flaw, or if one is available before the release of a fix. A flaw will only be re-evaluated if new technical details emerge.

The following table provides severity ratings for Red Hat products and systems. For flaws specific to AI models, see Red Hat security ratings for AI models.

Severity ratings Security flaw 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, or easily cause system compromise via inference end points on AI systems. Flaws that require authentication, local or physical access to a system, or an unlikely configuration are not classified as Critical impact. These are the types of vulnerabilities that can be exploited by worms.
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 or authenticated users to gain additional privileges, allow unauthenticated remote users to view resources that should otherwise be protected by authentication or other controls, allow authenticated remote users to execute arbitrary code, allow remote users to cause a denial of service, or can cause system compromise via inference end points on AI systems.
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. It is also given to flaws that could be exploited to cause denial of service-like conditions on AI systems via an inference end point, or allow attackers to steal other users’ data from the AI system without authorization. These are the types of vulnerabilities that could have had a Critical or Important impact but are less easily exploited based on a technical evaluation of the flaw and/or affect unlikely configurations.
Low impact This rating is given to all other issues that may 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. This includes flaws that are present in a program’s source code but to which no current or theoretically possible, but unproven, exploitation vectors exist or were found during the technical analysis of the flaw.

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 7 and 8). Each issue in an advisory has a severity 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. The advisories contain links to the relevant entries in Red Hat's bug-tracking system, where you can examine individual severity ratings and additional commentary, as well as links to the relevant pages in Red Hat’s CVE database.

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  and CVE database entries.

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: Attack Vector, Attack Complexity, User Interaction, Privileges Required, Scope, Confidentiality, Integrity, and Availability.

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

Red Hat does not solely use the CVSS rating to determine the priority with which flaws are fixed, or to determine the severity rating of the vulnerability. It is used as a guideline to identify and describe key metrics of a flaw, however the priority for which flaws are fixed is determined by the overall severity of the flaw using the aforementioned four-point scale.  CVSS is meant to help customers prioritize the order in which they remediate flaws.

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 the difficulty of executing an attack and what factors are needed for it to be successful. (Along with User Interaction, Attack Complexity was formerly part of the Access Complexity metric.).
  • User Interaction (UI) - Determines whether the attack requires an active human to participate or if the attack can be automated.

  • Privileges Required (PR) - Documents the level of user authentication required for the attack to be successful. (This replaces the former Authentication metric.).
  • Scope (S) - Determines whether an attacker can impact a component beyond its security scope/authority.
  • Confidentiality (C) - Determines whether unauthorized parties can access data and to what extent.
  • Integrity (I) - Measures the impact to the trustworthiness and veracity of data.
  • Availability (A) - Refers to the impact to accessibility of data or services for authorized users.

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.1: User Guide for detailed descriptions of the base metrics. It is important to note that the CVSS base metrics were designed to be used with the other CVSS metric groups, notably the Temporal and Environmental metrics, to provide an accurate representation of risk in customer environments.  Alone, the Base metrics offer a shallow view of the vulnerability itself without accounting for deployment or the environment.

How Red Hat Uses CVSS v3 Base Metrics

We aim to comply with the CVSS v3 standard when assigning base scores, and Red Hat uses base metrics that reflect how a vulnerability affects our products specifically.  In addition, we do not use the Qualitative Severity Rating Scale in the CVSS v3.1 User Guide to rate severity, and our severity ratings are always based on the aforementioned four-point scale.  In some circumstances, it may not be obvious why a flaw received a particular score. The following are some common vulnerability types with our interpretation and typical scoring:

Libraries

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, and 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.

Other Common Scores

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

Flaws that allow a local, unprivileged user to escalate their privileges to root typically score 7.8 (for example, CVE-2019-18634).

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

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-2019-15031 only affected PowerPC.
  • A vulnerability that is mitigated by source code protection mechanisms on some platforms. For example, CVE-2018-1125 could have led to arbitrary code execution on Red Hat Enterprise Linux, but it is only a denial of service because it was compiled with FORTIFY protections.
  • A vulnerability that affected more than one product.  For example, CVE-2020-14060 affected a component in both OpenShift and OpenStack.  The severity to OpenStack was lower (Low) as compared to OpenShift (Moderate) based on its usage; the overall vulnerability itself was rated Important.


If CVSS v3 base scores are significantly different across products, we note that 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 vulnerabilities difficult for third-party vulnerability databases, such as NVD, who can give only a single CVSS base score to each vulnerability, or when comparing to other vendors who score based on the characteristics of use in their own products. See the National Vulnerability Database for more information regarding NVD security ratings.

These differences can cause the scores to vary widely. Other reasons may include how the source code was compiled with certain compiler flags or hardening technologies that reduce or eliminate the security severity of a flaw, or how the software is used within the product. Software running standalone may suffer from a flaw, but its use within a product may preclude the vulnerable code from ever being used in a way that could be exploited. 

For example, NVD may rate a flaw in a particular service as having High Impact on the CVSS CIA Triad (Confidentiality, Integrity, Availability) where the service in question is typically run as the root user with full privileges on a system. However, in a Red Hat product, the service may be specifically configured to run as a dedicated non-privileged user running entirely in a SELinux sandbox, greatly reducing the immediate impact from compromise, resulting in Low impact.

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 and update if needed.