Exploited, but Not 'Critical': What a Single-Signal Queue Buries

TL;DR — We start from the strongest public signal there is: CISA KEV, the 1,653 vulnerabilities the U.S. government records as observed exploited in the wild. Then we ask how each single-signal triage queue would rank them. A severity-first ("Critical only") queue buries 71.1% (1,175) of these known-exploited CVEs — they aren't rated CVSS Critical. A probability-first queue with an EPSS < 0.10 cutoff buries a different 23.8% (394). The two blind spots are not the same CVEs. No single signal surfaces everything known to be exploited — which is the entire argument for combining them.

The setup: ground truth first

Most prioritization studies start from the full CVE firehose and try to guess what matters. This one inverts that. We start from the vulnerabilities that are known to matter — KEV is a catalog of confirmed, in-the-wild exploitation — and check how well each single ranking signal would have surfaced them. If a signal is a good sole basis for triage, almost all of KEV should rank near the top of it. If a large slice of KEV sits below a signal's threshold, that signal, used alone, buries real exploited bugs.

We test the two signals teams actually triage on:

• Severity (CVSS) — the "work the Criticals first" policy.
• Exploitation probability (EPSS) — a threshold like "escalate anything above 0.10."

What we counted

• CISA KEV JSON catalog — version 2026.07.24, 1,653 entries (the ground-truth universe for this study).
• NVD CVE API 2.0 — used to establish which KEV entries are rated CVSS v3 Critical (base ≥ 9.0). Snapshot 2026-07-27.
• FIRST EPSS current scores — model v2026.06.15, score date 2026-07-26. Every one of the 1,653 KEV entries has an EPSS score, so the probability view is complete.

The result: two different blind spots

Single-signal queue	KEV entries it buries	Share of 1,653
Severity-first (not rated CVSS Critical, <9.0 or unscored)	1,175	71.1%
Probability-first (EPSS < 0.10)	394	23.8%

Only 478 (28.9%) of known-exploited vulnerabilities are rated CVSS Critical. So a team whose policy is "Criticals first" would never see 71% of confirmed in-the-wild exploitation in its top-priority bucket — those CVEs are High, Medium, or simply lack a v3 score, and a Critical-gated queue steps right past them.

The probability queue does much better on KEV — as it should, since EPSS is trained to predict exploitation — but it still leaves 394 known-exploited CVEs below a 0.10 cutoff. That's the catch: EPSS is a forecast. KEV is observation. About one in four things we can see being exploited, the forecast still rates as low-probability. Dropping KEV as an independent input would bury exactly those.

The two blind spots barely overlap in intent. Severity misses the exploited-but- not-severe; probability misses the exploited-but-not-predicted. The only queue that surfaces all of KEV is one that treats observed exploitation itself as a first-class signal, alongside severity and probability.

Why a prioritizer carries KEV as its own signal

This is why risk-based scoring keeps observed-exploitation as a separate, heavily weighted term rather than folding everything into severity or a single model. Zennoxa Shield's Priority Engine scores CVSS·0.30 + EPSS·0.30 + KEV·0.25 + reachability·0.15 — KEV is a full quarter of the weight because the data here shows neither severity nor probability alone catches what KEV catches. The connection is category-level and honest: the study is computed entirely from public data, names no vendor, and stands on its own. It measures the gap that a multi-signal design is built to close.

Reproduce it yourself

1. Download KEV: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json — pin catalogVersion; the CVE set is vulnerabilities[].cveID.
2. For CVSS: pull the NVD cvssV3Severity=CRITICAL universe and mark which KEV CVE IDs are in it; the complement is "not rated Critical."
3. For EPSS: download epss_scores-current.csv.gz, join on CVE ID, count KEV entries below 0.10.
4. Report each buried count over 1,653.

Limitations, stated plainly

• "Not Critical" bundles two cases: KEV entries scored below CVSS 9.0, and KEV entries with no CVSS v3 score at all (often older CVEs). Both are outside a Critical-gated queue, which is what the metric is about — but "not Critical" is not the same as "low severity" for the unscored subset.
• KEV is a floor. It captures confirmed exploitation; true exploitation is broader. That makes the severity-queue blind spot a lower bound, not an upper one.
• EPSS is a forecast, revised daily; the 23.8% figure is pinned to the stated model version and score date.

FAQ

If EPSS catches most of KEV, why keep KEV as a separate signal? Because "most" isn't "all" — 23.8% of known-exploited CVEs still fall below a 0.10 EPSS cutoff. KEV is observation; EPSS is prediction. Keeping observed exploitation as its own input means a confirmed-exploited bug is never demoted because a model underrated it.

Isn't 71% surprising — aren't exploited bugs usually severe? They're often serious, but "serious" and "CVSS ≥ 9.0" aren't the same. Plenty of actively-exploited vulnerabilities score in the 7–8 range or predate CVSS v3 scoring entirely, so a Critical-only queue simply doesn't include them.

Does this mean CVSS is useless? No. Severity measures impact and is a legitimate input. The finding is narrower: severity alone, used as a triage gate, buries most of what's known to be exploited — so it belongs in a blend, not as the sole sort key.

What data is this based on? The CISA KEV catalog, NVD CVSS v3 scores, and the FIRST EPSS current-scores file — all free and reproducible from the pinned snapshots above.