Usually not. Red Hat states that the risk level of a flaw does not change if an exploit or worm is later released, or if one exists before a fix. The rating is re-evaluated only if new technical details emerge. That is why exploitation status needs its own signal beside severity.
What a vendor rating measures
Red Hat Product Security rates issues on a four-point scale: Low, Moderate, Important and Critical, and also publishes a separate CVSS base score. The company describes the scale as a technical analysis of the exact flaw and its type.
| Rating | Red Hat's description, shortened |
|---|---|
| Critical | Easily exploited by a remote unauthenticated attacker, leading to system compromise without user interaction. The kind of flaw a worm could use |
| Important | Easily compromises confidentiality, integrity or availability, for example local privilege escalation or remote denial of service |
| Moderate | Harder to exploit, or limited to unlikely configurations, but could still cause some compromise |
| Low | Requires unlikely circumstances or gives minimal consequences |
Notice what the definitions are built from: how easily the flaw can be exploited and what it allows. They describe the flaw, not the news about it.
Why the rating stays fixed
A rating that jumped every time a proof of concept landed would be noisy, and hard to compare across time. Red Hat's choice is to keep the rating a stable technical judgement. That is a reasonable design, but it creates a gap for operations. If your queue is sorted by rating alone, an Important flaw that attackers are using this week sits below a Critical one nobody has touched.
Fill the gap with exploitation signals
Add a second column to your triage sheet: exploitation evidence. Good sources are:
- The CISA Known Exploited Vulnerabilities catalog. CISA adds an entry when there is reliable evidence of active exploitation, a CVE ID and clear remediation guidance.
- The vendor's own advisory text, which sometimes says exploitation is known.
- Your own telemetry, such as blocked requests that match the vulnerable path.
Then sort by the pair. A simple policy:
- Exploited in the wild and the product is present: act now, whatever the vendor rating says.
- Critical or Important with no exploitation evidence: patch in the next accelerated window.
- Moderate or Low: patch with routine updates unless exposure raises it.
Revisit on a schedule
Because exploitation changes after the rating is set, revisit open items. Re-check your Important and Critical backlog against the KEV catalog weekly, or automate the match. Our post on using CISA KEV as a trigger for an urgent rescan shows one way.
A note on other vendors
Other vendors set ratings differently, and some do revise. Do not assume Red Hat's rule applies elsewhere. Read each vendor's rating page once, write down whether exploitation moves the rating, and note it in your runbook.
Try it yourself
Click through it at your own pace, or open it full screen.
Watch how a new disclosure shows up next to what you run, separate from any severity label.
Safeguard offers zero-day discovery, reachability analysis and policy gates that can use exploitation status as a rule. Start with a free scan.
Quick check
If a vendor rates a flaw Moderate, can I ignore it when an exploit appears?
No. The rating describes the flaw, not exploitation news. Check exploitation sources and your exposure.
Does Red Hat publish CVSS scores too?
Yes. It publishes a separate CVSS base score alongside its four-point rating.
Sources
- Red Hat, Severity ratings
- CISA, Known Exploited Vulnerabilities
Last reviewed: 19 October 2026.
