Severity Ratings

Explanation of Red Hat security ratings

Red Hat Product Security rates the impact of security vulnerabilities found in Red Hat products. We use a Severity Rating scale with four levels:

  • Low
  • Moderate
  • Important
  • Critical

We have based this rating on the Common Vulnerability Scoring System (CVSS) base scores. Our scoring method provides a prioritized risk assessment to help you understand and schedule upgrades to your systems. With Red Hat Product Security, you are able to make informed decisions on the risks different issues place on your unique environment.

The four-level Security Rating scale tells you how severe Red Hat considers an issue to be. This rating helps you judge the severity of the problem and determine the most important updates to do and steps to take. The scale considers the potential risk based on a technical analysis of the exact flaw and its type, but not the current threat level. A given rating does not change after the release of an exploit or worm, or if available before the release of a fix.

  Severity Rating Description
Critical impact
  • This rating applies to flaws that remote unauthenticated attackers can easily exploit.
  • These flaws can lead to system compromise (arbitrary code execution) and do not require user interaction. Attackers can exploit these flaws with worms.
  • Flaws that require an authenticated remote user, a local user, or an unlikely configuration do not have a Critical impact rating.
Important impact
  • This rating applies to flaws that can easily compromise the confidentiality, integrity, or availability of resources, and can lead to the following issues:
  • Allow local users to gain privileges
  • Allow unauthenticated, remote users to view resources that authentication should protect
  • Allow authenticated remote users to execute arbitrary code
  • Allow remote users to cause a denial of service.
Moderate impact
  • This rating applies to flaws that, under certain circumstances, could compromise the confidentiality, integrity, or availability of resources.
  • Attackers cannot easily exploit these flaws because of the following reasons:
  • They affect unlikely configurations.
  • We have evaluated them already.
  • They could have had a Critical or Important impact rating in the past.
Low impact
  • This rating applies to all remaining issues that have a security impact and tend to have the following characteristics:
  • They require unlikely circumstances for attackers to exploit them
  • Their successful exploitation has minimal consequences for the user.

A Red Hat security advisory outlines the following information:

  • One or more fixes for all vulnerabilities, even if there is only one.
  • Packages with at least one product (such as both Red Hat Enterprise Linux 7 and 8).
  • An impact rating for each product that contains the same issue.
  • One overall severity of an advisory, which is the highest severity among all individual issues and across all the products that the advisory targets. Only the kernel advisories list the severity of each issue and not solely an overall severity rating.
  • The advisories contain links to the relevant entries in the Red Hat CVE database, where you can examine individual impacts and find additional commentary.

In order to help protect your systems, Red Hat uses several security technologies, such as SELinux and Svirt, . These technologies completely prevent attackers from exploiting some vulnerabilities. Red Hat assumes that you have these security technologies in your system by default and that you use them, When this occurs, we adjust the severity level accordingly and add an explanation in the bug-tracking entry decision and the CVE database.

Common Vulnerability Scoring System (CVSS)

Common Vulnerability Scoring System (CVSS) is a worldwide open framework that defines the characteristics and severity of software vulnerabilities. The base scores provide additional guidance about a vulnerability by giving a detailed severity rating. This rating scores the following constant aspects of a vulnerability:

  • Access Vector
  • Attack Complexity
  • Privileges Required
  • User Interaction
  • Confidentiality Impact
  • Integrity Impact
  • Availability Impact

CVSS version 2 base metrics are available for all vulnerabilities between 2009 and 2016, and for some earlier vulnerabilities. In 2016 Red Hat adopted the CVSS v3 standard, therefore all vulnerabilities going forward use version 3 for scoring with, with version 3.1 beginning use in 2016. You can find these scores on the CVE pages and also in our Security Measurements page.

  • Red Hat uses both CVSS and Severity Rating for distinct purposes: CVSS serves us as a guideline to identify the key metrics of a flaw which helps in the determination of the Severity Rating.
  • Our four-level Severity Rating scale determines the priority with which we fix flaws based on their overall impact.

List of CVSS v3 base metrics

The CVSS v3 base metrics group covers the constant aspects of a vulnerability that examine the following Exploitability and Impact metrics:

  • Attack Vector (AV) - Refers to the "remoteness" of the attack and how attackers exploit this vulnerability.
  • Attack Complexity (AC) - Refers to the difficulty of executing the attack and the factors that the attack must have to succeed. 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 an attack to be successful. -This replaces the former Authentication metric.
  • Scope (S) - Determines whether an attacker can affect a component that has a different level of authority.
  • Confidentiality (C) - Determines whether unauthorized parties can access data and to what extent.
  • Integrity (I) - Measures how trustworthy the data is so that unauthorized users cannot modify it.
  • Availability (A) - Refers to the 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 the Common Vulnerability Scoring System v3.1: User Guide for detailed descriptions of the base metrics.

Uses of CVSS v3 base Metrics at Red Hat

We aim to comply with the CVSS v3 standard when allocating base scores.

Red Hat scores reflect how a vulnerability affects our products specifically.

We do not use the Qualitative Severity Rating Scale in the CVSS v3.1 User Guide and that scoring does not automatically display for qualitative ratings. Among other factors, however, we base our four-point impact rating on the CVSS base metrics and the severity of the security issues).

Examples of vulnerabilities and their Red Hat Scoring

1. Libraries

We do not always know how third-party applications use libraries, which diminishes the accuracy of CVSS v3 base metrics for flaws in system libraries. When rating these flaws, we consider two factors:

  • How the applications that we ship use the libraries
  • Whether popular software may use the library in a way that would increase the severity of the issue. We then adjust the score appropriately.

2. Web browsers and associated plug-ins

One class of flaws in web browsers and their plug-ins 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.

3. Flaws where a local, unprivileged user can cause a kernel to crash, which is denial of service, typically score 6.5 (for example, CVE-2020-10701).

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

5. Cross-site scripting flaws generally receive the following scores:

  • Low impact for Integrity
  • Low or no impact for Confidentiality or Availability. This score is in line with that of other vendors and NVD. A typical score for these flaws is 6.1 (for example, CVE-2020-7015).

Base score variations across products

It is common for a given CVE-named vulnerability to have several different CVSS base metrics. These metrics depend on the product, version, and architecture of the vulnerabilities. Look at the following vulnerability examples to better understand the factors that affect their metrics :

  • A vulnerability that only affected some architectures. For example, CVE-2019-15031) only affected PowerPC.
  • A vulnerability that affected more than one application. For example, CVE-2020-14060) affected a library in both OpenShift and OpenStack. The severity to OpenStack was lower (a Low) as compared with OpenShift (a Moderate).

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 following factors:

  • Version the vendors ship
  • How they ship it
  • The platform in which they ship the softwareHow the software is compiled

This makes scoring vulnerabilities difficult for third-party vulnerability databases, such as the National Vulnerability Database (NVD). The NVD can give only a single CVSS base score to each vulnerability. See the National Vulnerability Database) for more information regarding NVD Security Ratings.

These differences can cause the scores to vary widely. 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 we need to.