Why CVSS Scores Don't Tell You What to Patch

The organisation that scores vulnerabilities has stopped scoring most of them

On 15 April 2026, NIST announced that the National Vulnerability Database would no longer attempt to enrich every submitted CVE.

The reasoning was volume. CVE submissions rose 263% between 2020 and 2025. The first quarter of 2026 ran nearly a third higher than the same quarter of 2025. NIST enriched close to 42,000 CVEs in 2025 — 45% more than in any previous year — and that was not enough to keep pace.

What replaced universal coverage is a triage rule, and its content is the interesting part. NIST now prioritises three categories: vulnerabilities in CISA's Known Exploited Vulnerabilities catalogue, targeted for enrichment within one business day; vulnerabilities affecting federal government software; and vulnerabilities in critical software as defined by Executive Order 14028. Everything else remains listed in the database but is marked "Lowest Priority — not scheduled for immediate enrichment."

Read that as a signal rather than as an administrative notice. The institution responsible for maintaining severity data concluded that severity data alone could not be produced at the required scale, and chose evidence of exploitation as its first filter.

That is the same decision a defender has to make, for the same reason.

Six per cent

The underlying arithmetic is stark. Research conducted by the Cyentia Institute with FIRST examined 237,687 published CVEs against more than 8.6 million observations of daily exploitation activity drawn from a global contributor network. Roughly 6% had ever been observed with exploitation activity in the wild.

The distribution within that 6% is narrower still. Half of all exploited CVEs never reached more than 0.02% of organisations. Fewer than 5% affected more than 10% of firms globally. Exploitation is not merely rare; it is concentrated.

Set the two figures together. A severity-driven programme treats a population of which 94% will never be touched as though the only question is how bad each member would be. The sorting criterion is orthogonal to the outcome being sorted for.

What CVSS measures, and what it does not

CVSS is a scoring system for the intrinsic characteristics of a vulnerability: how it is accessed, what it requires of the attacker, and what an attacker gains if they succeed. It answers the question how severe is this flaw.

It does not answer will anyone exploit this. Nothing in the base metric group estimates attacker interest, exploit availability, or observed activity — those are properties of the world, not of the vulnerability, and they change after the score is assigned.

This is not a defect. It is a scope decision, and the specification distinguishes severity from risk explicitly. The failure is in usage: treating a severity ranking as a work queue, which assumes that the worst-if-exploited vulnerabilities are the most-likely-to-be-exploited ones. They are not correlated in the way that assumption requires.

The practical consequence is measurable. Prioritising by CVSS 9 and above achieves roughly 37% risk coverage. For the same level of remediation effort, prioritising by EPSS achieves 93% — nearly three times the coverage for equivalent work.

The two signals that do help

The KEV catalogue records vulnerabilities for which CISA has reliable evidence of active exploitation. It is a high-precision, low-recall instrument. Inclusion is strong evidence that something is being used against real targets; absence is weak evidence of anything, because it requires evidence to have reached CISA and been validated. There is lag, there is coverage bias, and its operational remit is US federal agencies.

Used correctly, KEV is a floor rather than a plan. Anything in the catalogue that you run should already be remediated. Nothing follows about the rest.

EPSS takes the opposite approach. Rather than recording confirmed exploitation, it estimates the probability that a vulnerability will be observed being exploited within the next 30 days, publishing both a probability and a percentile rank.

The published performance data is worth quoting precisely. Prioritising vulnerabilities with an EPSS score of 0.1 or above achieves 80% risk coverage at 50% precision — meaning half of what you remediate would have been exploited, which is an extraordinary hit rate in this domain. Against a CVSS 7-and-above strategy, EPSS reaches equivalent coverage at one-sixth of the effort.

EPSS has its own limits, and they should be stated. It is a probability of exploitation, not a measure of risk: it says nothing about consequence. It is trained on observed activity, so it inherits the coverage biases of its sensor network. And a probability is not a prediction — a low score on something you expose to the internet is not permission to ignore it indefinitely.

What none of these signals know

KEV, EPSS and CVSS share a blind spot: none of them know what you run.

A vulnerability under heavy global exploitation in software you do not deploy is not your problem. A moderately-scored vulnerability in an internet-facing service you do deploy, with weak authentication in front of it, may be your most urgent item. Neither catalogue can make that distinction, because neither has an inventory of your estate.

This is why prioritisation is a two-factor problem rather than a better-scoring problem. Exploitation evidence tells you what attackers are using. Exposure tells you what they could use against you. Only the intersection is a work queue.

The practical sequence:

1. Anything in KEV that you run and expose. Immediate.
2. High EPSS, exposed, internet-facing. This week.
3. High EPSS, internal only. Normal cycle, with compensating controls noted.
4. High CVSS, low EPSS, not in KEV. Normal cycle. This is where most of the volume sits, and where severity-driven programmes spend most of their effort.

Exploitation telemetry, and its own blind spots

Sensor and honeypot data adds something catalogues cannot: it observes attempts as they happen, rather than after an incident has been investigated and reported. Where a catalogue tells you that something was exploited somewhere at some point, telemetry can indicate that something is being probed this week.

Its biases are equally structural and should be acknowledged by anyone selling it. Internet-facing sensors observe internet-facing attacks. They systematically under-observe exploitation that occurs after initial access — lateral movement, privilege escalation, anything requiring a foothold. They see opportunistic scanning better than targeted activity. And their geographic and infrastructural placement shapes what they record.

Telemetry is a complement to the catalogues, not a replacement. The honest framing is that each source has a different shape of blind spot, and the useful position is the overlap.

What this means in practice

Stop using severity as the queue. Keep CVSS for what it measures — how bad this would be — and use exploitation evidence to decide sequence.

Treat KEV as a floor. Everything on it that you run should be closed. Do not infer safety from absence.

Use EPSS for the long tail. It is where the 94% that will never be exploited gets filtered out, and the published coverage-per-effort figures are substantial.

Bring exposure into the decision. No external signal knows your estate. The intersection of "being exploited" and "we run this, exposed" is the only genuinely prioritised list.

Expect the data itself to get patchier. NIST's April 2026 change means enrichment coverage for lower-priority CVEs will decline. Programmes that assumed complete, uniformly-enriched national vulnerability data need another plan.

The broader point is the one NIST made by acting on it. When the volume of published vulnerabilities grows faster than anyone's capacity to assess them, the only workable filter is evidence of use. That conclusion arrived at the national database in 2026. It applies to a security team with a patch window rather sooner.