- A CVE record is an identifier and a description. It is not, on its own, a judgement about how urgent the vulnerability is for you.
- CVSS answers how bad exploitation would be, EPSS answers how likely exploitation is in the next 30 days, and CISA’s KEV catalog answers whether exploitation has actually been observed.
- Since 15 April 2026 the NVD no longer enriches most CVEs, so a missing severity score is now common and means nothing about severity.
- Read the three signals in order: confirmed exploitation first, then likelihood combined with exposure, then impact, then your own environment.
- Percentile is not probability, CVSS v4.0 scores are not comparable with v3.1 scores, and absence from KEV is not evidence that something is safe.
Open any vulnerability report and you will find the same cluster of numbers: a CVE identifier, a severity score out of ten, sometimes a probability expressed to five decimal places, and occasionally a flag saying the vulnerability is known to be exploited. Each of those numbers was produced by a different organisation, on a different schedule, to answer a different question. Read them as though they were interchangeable and you will patch the wrong things in the wrong order.
This is a reference for reading those numbers accurately, and for knowing what each one cannot tell you.
What a CVE record actually is
A CVE identifier is a catalogue number. It exists so that a vendor advisory, a scanner finding, a threat report and a patch note can all refer to the same flaw without ambiguity. The record is created by a CVE Numbering Authority, usually the affected vendor or a coordinating body, and it carries a description, the affected products and versions, and references.
What the identifier does not carry is a verdict. Assignment is not triage. Two records sitting next to each other in a scanner report can represent a trivially exploitable pre-authentication flaw on an internet-facing appliance and a local privilege escalation that requires an attacker to already be on the host. The CVE format treats them identically. Everything that helps you separate the two comes from the scoring and intelligence layers built on top.
The 2026 change to check before anything else
On 15 April 2026 the National Vulnerability Database moved to a risk-based enrichment model. NIST now prioritises three categories of CVE for full enrichment: those in CISA’s Known Exploited Vulnerabilities catalog, with a target of one business day, those affecting software used within the US federal government, and those affecting critical software as defined by Executive Order 14028. Everything else is published but labelled as lowest priority and not scheduled for enrichment. Unenriched records published before 1 March 2026 were moved into the same category with no committed timeline.
NIST was explicit about the reason. CVE submissions rose 263 percent between 2020 and 2025, and although NIST enriched close to 42,000 records in 2025, more than in any previous year, the backlog kept growing. NIST also stopped routinely adding a second severity score where the CVE Numbering Authority has already supplied one.
The practical consequence changes how you read a record. A CVE with no NVD severity score is now the normal case rather than a signal, so treat the blank as missing data and go to the CNA-supplied score, the vendor advisory, or CISA’s Vulnrichment enrichment data instead. Any internal rule that says “no score, no ticket” now silently drops the majority of new vulnerabilities, and any dashboard that sorts by NVD severity is sorting an increasingly unrepresentative slice of the corpus.
Check what your scanner does when NVD data is absent. Some tools fall back to the CNA score, some substitute their own rating, and some report the finding as unscored. Those three behaviours produce three different queues from the same input.
CVSS: how bad it would be
The Common Vulnerability Scoring System, maintained by FIRST, describes the intrinsic characteristics of a vulnerability and the impact of successful exploitation. Version 4.0 has been current since November 2023 and organises metrics into four groups: Base, Threat, Environmental and Supplemental.
Version 4.0 also introduced naming that makes the omissions visible. A base-only score is CVSS-B, base plus threat is CVSS-BT, base plus environmental is CVSS-BE, and the fully contextualised score is CVSS-BTE. Almost every score you will see quoted in an advisory or a scanner is CVSS-B, which is the version of the score that carries the least information about your situation. FIRST states the point directly in its own documentation: the base score measures severity, is independent of any threat activity or deployment context, and should not be used alone to assess risk.
| Base score | Severity rating |
|---|---|
| 0.0 | None |
| 0.1 to 3.9 | Low |
| 4.0 to 6.9 | Medium |
| 7.0 to 8.9 | High |
| 9.0 to 10.0 | Critical |
Three things trip people up. Scores from v4.0 and v3.1 are not directly comparable for the same vulnerability, so a fleet-wide average that mixes both is meaningless. The Supplemental group, which covers attributes such as whether exploitation is automatable and whether there is a safety impact, does not change the number at all, and is easy to miss for exactly that reason. And who produced the score matters: a CNA scoring its own product and an independent analyst scoring the same flaw can reasonably differ, so when two sources disagree, read the vector string rather than the number.
EPSS: how likely exploitation is
The Exploit Prediction Scoring System, also maintained by FIRST, estimates the probability that a vulnerability will show exploitation activity in the wild during the next 30 days. Scores run from 0 to 1, are recalculated every day, and have been produced by the fourth generation of the model since March 2025. A score of 0.42 means a 42 percent estimated probability, and nothing more than that.
Alongside the probability, EPSS publishes a percentile, and this is where most misreadings happen. A percentile of 0.97 does not mean a 97 percent chance of exploitation. It means the vulnerability scores higher than 97 percent of all scored CVEs, which, given how heavily the distribution is weighted towards very low probabilities, is entirely compatible with a probability of a few percent. If you set thresholds, set them on the probability and use the percentile only for ranking.
The reason to care is efficiency. FIRST publishes a worked comparison of prioritisation strategies against observed exploitation activity, and the gap between them is large.
![Bar chart comparing effort, coverage and efficiency for a CVSS 7.0 and above patching strategy against an EPSS 0.1 and above strategy](/wp-content/uploads/2026/07/cvss-vs-epss-strategy.webp")
Remediating everything scored 7.0 and above means touching 57.4 percent of published CVEs to catch 82.2 percent of the ones that were actually exploited, at an efficiency of 3.96 percent. Prioritising on an EPSS score of 0.1 and above means touching 2.7 percent of CVEs, catching 63.2 percent of exploited ones, at an efficiency of 65.2 percent. Neither is correct in isolation. The first is thorough and expensive, the second is cheap and leaves gaps, and the point of holding both numbers is that you can choose your position between them deliberately rather than by accident.
Two limits are worth stating plainly. EPSS is a population-level model, so it says nothing about whether your specific systems are targeted by an adversary with a specific interest in you. And EPSS sits upstream of threat intelligence: where there is direct evidence that a vulnerability is being exploited, that evidence supersedes the prediction.
KEV: what is confirmed exploited
CISA’s Known Exploited Vulnerabilities catalog is the evidence layer. A vulnerability is added only when it has an assigned CVE ID, reliable evidence of active exploitation in the wild, and clear remediation guidance. It is deliberately conservative, CISA removes entries only rarely and usually only to correct an error, and it holds roughly 1,600 CVEs against a published corpus well past 250,000. Under one percent.
That scarcity is the value. When a CVE appears in KEV, the question of whether attackers can exploit it has been settled by observation rather than estimated by a model, and prediction is no longer the relevant input.
The federal framing around KEV changed in 2026. Binding Operational Directive 26-04, issued on 10 June 2026, revoked BOD 19-02 and BOD 22-01 and replaced the old flat KEV deadline with a decision model built on four variables:
- Asset exposure: is the vulnerable asset reachable by unauthenticated or untrusted parties over a public network?
- KEV status: is the CVE listed in the catalog?
- Exploit automation: can an adversary automate exploitation?
- Technical impact: does exploitation yield total control of the asset, or partial?
Those four inputs map to remediation windows ranging from three days at the most urgent end, with a forensic triage requirement where the combination suggests compromise may already have occurred, through 14 and 60 day tiers, down to fixing on the next scheduled system upgrade. The clock starts when CISA adds the CVE to KEV or when the agency identifies the vulnerability on an asset, whichever happens first, and the tier moves as the facts move: take a system off the internet and the window relaxes, see the CVE added to KEV and it tightens.
The directive binds US federal civilian agencies and FedRAMP cloud service providers rather than everyone. It is still worth reading if you sit outside that scope, because it is a published, defensible worked example of exactly the reasoning this article is about: four signals, combined explicitly, producing a deadline that can be explained to an auditor.
Absence from KEV is not evidence of safety. The catalog reflects exploitation that CISA has been able to verify, so newly weaponised vulnerabilities and those exploited in narrow, targeted operations can be missing from it for some time, or permanently.
Reading the three together
The signals have a natural order, because each one is answering a question that only matters if the previous answer was inconclusive.
Start with KEV, because confirmed exploitation removes all uncertainty about capability. If the CVE is listed and the affected asset is exposed, the decision is made and the remaining work is scheduling and verification. If it is not listed, move to EPSS combined with exposure, since a high probability on an internet-facing system is a different proposition from the same probability on a segmented internal host. Then bring in CVSS, not as a queue-sorting number but for what the vector tells you about impact and attack requirements. Finally apply what only you know: whether the asset is business critical, whether compensating controls already break the attack path, and whether patching carries operational risk of its own.
Run the same sequence in reverse, which is what sorting a scanner report by severity does, and you will spend most of your capacity on high-scoring vulnerabilities that nobody is exploiting while a medium-rated flaw on an exposed edge device waits its turn.
- Check whether your vulnerability tooling ingests EPSS and KEV, or only severity scores. If it only carries severity, your prioritisation is running on one of the three signals.
- Test what your pipeline does with an unenriched CVE, now that most new records will arrive without an NVD score.
- Rewrite any SLA that is defined purely on CVSS bands so that confirmed exploitation and public exposure can override the band.
- Set EPSS thresholds on probability, never on percentile, and write the chosen threshold down alongside the coverage you are accepting.
- Subscribe to KEV additions as an operational feed rather than checking the catalog after an incident.
Six common misreadings
- Treating percentile as probability. A 99th percentile CVE may still carry a low single-digit probability.
- Reading a missing CVSS score as low severity. Since April 2026 it usually means nobody at NIST was scheduled to look at it.
- Averaging v3.1 and v4.0 scores. They are different scales measuring the same thing differently.
- Quoting a base score as risk. CVSS-B deliberately excludes threat activity and your environment, which is where risk lives.
- Treating EPSS as a forecast about your organisation. It is a population estimate, not a targeting assessment.
- Treating KEV as the complete list of exploited vulnerabilities. It is the verified list, which is a smaller thing.
None of these three signals was designed to be used alone, and the organisations that publish them say so in their own documentation. The skill is not in finding a single number to sort by. It is in knowing which question each number answers, and which question you are actually asking.