How do you read a CVE and decide whether it needs fixing now?

A CVE record is a numbered label and short description for a publicly disclosed flaw, not a verdict on your risk. To decide whether to fix it now, read what is affected, then combine severity (CVSS), evidence of attacks (CISA KEV), likelihood (EPSS) and whether your system actually uses the vulnerable code.

What is a CVE, and what is it not?

A CVE identifier, such as CVE-2026-12345 in the usual format, gives one vulnerability a shared name so that scanners, advisories and patches can refer to it. It does not say how severe the flaw is in your environment, whether anyone exploits it, or whether a fix exists. Those facts come from other sources, which is why one number is never enough.

What should you read first?

Start with the description and the affected versions. Does your product use the named component? Is your version in the vulnerable range? Many alerts end here, because the scanner matched a name and not a version, or the vulnerable feature is one you do not use.

Then check whether a fixed version exists and what upgrading means for you.

What do the scores tell you?

CVSS from FIRST describes technical severity. CVSS version 4.0 groups metrics into base, threat, environmental and supplemental groups. The base score describes the flaw itself, such as how it is reached and what it affects. Threat and environmental metrics adjust for exploit maturity and your own setting. Most published scores are base scores only, so they say little about your case.

CISA KEV is the Known Exploited Vulnerabilities catalog. A listing means there is evidence of exploitation in the wild. That is a strong signal for prompt action, and for federal agencies the catalog carries due dates.

EPSS, the Exploit Prediction Scoring System, estimates the probability that a published CVE will be exploited in the wild in the next 30 days. FIRST publishes a score between 0 and 1 every day for every CVE. It is a probability, not a severity, and FIRST describes it as a way to focus limited remediation effort where attacks are most likely.

Each answers a different question: how bad, is it happening, and how likely.

A constructed example

Two findings arrive on the same morning. Finding A is a critical flaw, base score 9.8, in a library your service includes, but only in a parser for a file type your service never loads, and it does not appear in KEV. Finding B is a medium flaw, base score 6.5, in your VPN gateway, and it appears in KEV. Sorted by score alone, A goes first. Sorted by evidence and exposure, B goes first, and A moves into the next planned upgrade.

What about reachability?

Scanners report what is present. They do not say whether your code ever calls the vulnerable function. Reachability analysis checks whether a path exists from your code to the flawed code, and it can remove a large share of noise. Safeguard offers reachability analysis for this purpose, and it works best as one input alongside KEV and EPSS, not as a replacement.

What should you do with the rest?

Not everything needs an emergency. Group findings into three queues: fix now, fix in the normal cycle, and accept with a written reason and review date. Record the reason, because an accepted risk with no note looks like an ignored one later.

How to check or apply this

1. Confirm the component and version are in use and in the affected range.
2. Check for a fixed version and note what the upgrade involves.
3. Look up the CVE in the KEV catalog. If it is listed, treat it as urgent.
4. Check its EPSS score and note the trend over a few days.
5. Read the CVSS vector, not only the number, and adjust for your exposure.
6. Test whether your code reaches the vulnerable function.
7. Assign a queue and a date, and write down the reason for any decision to wait.

Quick check

Sources

• FIRST, Common Vulnerability Scoring System
• FIRST, CVSS v4.0
• FIRST, Exploit Prediction Scoring System
• CISA, Known Exploited Vulnerabilities Catalog
• NIST National Vulnerability Database

Last reviewed: 18 October 2026.