Red Hat rates flaws on a four point scale, Critical, Important, Moderate and Low, and publishes a CVSS score next to it. The four point rating drives Red Hat's fix priority. CVSS is a guideline, so the two can differ, and Red Hat's own scores are preferred over third party ones.
The four labels
Red Hat's classification page defines them in terms of how a flaw can be used:
| Rating | Meaning in Red Hat's words, summarised |
|---|---|
| Critical | Could be easily exploited by a remote unauthenticated attacker and lead to system compromise |
| Important | Can easily compromise confidentiality, integrity or availability, such as local privilege escalation or remote denial of service |
| Moderate | May be harder to exploit or affect unlikely configurations, but could still lead to some compromise |
| Low | Believed to require unlikely circumstances to be exploited |
A flaw that needs authentication, local access or an unlikely configuration does not qualify as Critical. That is why many serious looking kernel bugs show up as Important.
How this relates to CVSS
CVSS gives a base score from 0.0 to 10.0. Red Hat publishes it, but says it does not use the qualitative severity scale from the CVSS v3.1 user guide to rate severity. It uses CVSS as a guideline and the four point scale decides priority. Red Hat uses CVSS v3.1 for vulnerabilities from 2016 onward, and CVSS v2 for issues from 2009 to 2016.
Because CVSS scores can differ by product, Red Hat prefers its own scores over third party scores. A public database may score the same CVE higher, because it scores the flaw in the abstract, while Red Hat scores it for how its packages are built and configured. The same effect is covered for other distributions in why a Linux distro rates a CVE differently than CVSS.
Using it in a patch policy
- Take the vendor rating as the first input for packages from that vendor.
- Add exposure: is the service reachable from the internet, or only from a trusted network?
- Add exploitation evidence, using a source like EPSS and KEV.
- Set a deadline per tier. Do not use the vendor label as the deadline on its own.
A Moderate flaw in an exposed parser can deserve a faster fix than a Critical flaw in a service that is switched off.
Seeing it on the host
The updateinfo views in DNF show severity next to each advisory. See dnf upgrade with the security flag or a full upgrade.
An example of how the two can differ
Imagine a flaw that scores high on a generic scale because it allows code execution, but only for a local user who already has an account. Red Hat's definition keeps that out of Critical, since Critical requires easy remote exploitation without authentication. It would likely be rated Important. If your hosts are shared by many untrusted users, such as a build server, Important may still deserve urgent attention. If they are single purpose servers with no local users, it may not. Context decides.
Quick check
Is a Red Hat Important rating the same as a CVSS High?
No. Red Hat says it does not use the CVSS qualitative scale to rate severity, so do not map the labels one to one.
Whose score should I trust for a Red Hat package?
Red Hat states that its own scores are preferred over third party scores, because CVSS can differ by product.
Safeguard shows reachability analysis alongside severity, so you can see whether a flagged library is actually called by your code. Try a free scan at gold.safeguard.sh/scan.
Sources
Last reviewed: 19 October 2026.
