Most vulnerability signals are predictions or estimates. CISA KEV is neither — it's a record of what has actually happened.
What KEV is
The Known Exploited Vulnerabilities (KEV) catalog is maintained by the Cybersecurity and Infrastructure Security Agency (CISA). It lists CVEs with confirmed evidence of active exploitation in the wild — not vulnerabilities that are theoretically dangerous, not ones a model predicts will be exploited, but ones CISA has verified are already being used in real attacks.
Each entry includes the CVE ID, the affected product, a short description, the date it was added, and — for US federal civilian agencies — a required remediation deadline under Binding Operational Directive 22-01. Private-sector organizations aren't legally bound by those deadlines, but the deadline itself is a useful signal: CISA is telling you how urgently government systems are expected to be patched, which is a reasonable floor for anyone else's SLA on the same CVE.
As of 2025 the catalog holds over 1,200 entries and grows continuously as new exploitation is confirmed and reported to CISA by security researchers, vendors, and incident responders.
Why exploited-in-the-wild status matters more than severity
A CVSS score tells you how bad a vulnerability could be. KEV tells you it's not hypothetical — someone is already using it to break into networks. That distinction changes what "priority" should mean.
Consider two findings from the same Nessus scan, both scored CVSS 9.8:
- One is a remote code execution bug in a niche internal tool, published six months ago, no public exploit code, zero KEV entry.
- The other is CVE-2023-4966 ("Citrix Bleed"), a session-hijacking vulnerability in Citrix NetScaler that CISA added to KEV within weeks of mass exploitation by ransomware affiliates.
Both are CVSS 9.8. Only one of them is a fire that's actively spreading. If your remediation queue treats them identically because they share a CVSS bucket, you're deprioritizing the one that matters more by definition.
How security teams should use KEV alongside CVSS
KEV isn't a replacement for CVSS — it's a filter that sits on top of it. A practical way to use both together:
- Cross-reference every scan finding against the current KEV catalog. Anything that matches goes to the front of the queue, independent of its CVSS score. A KEV entry at CVSS 6.5 still outranks a non-KEV finding at CVSS 9.8, because exploitation is already happening on the former and only theoretically possible on the latter.
- Use CVSS to differentiate within the KEV set, not to decide whether something belongs there. If five KEV entries land in the same scan, CVSS can help you sequence them, but none of the five should be pushed to next quarter because their CVSS happens to be lower than a non-KEV finding elsewhere.
- Treat non-KEV Criticals as "high severity, unconfirmed urgency." They still need to be fixed — CVSS 9+ findings are not safe to ignore — but they shouldn't consume the same emergency-patching cycle time as a confirmed KEV entry.
- Re-check the catalog on a schedule, not once. KEV grows continuously. A finding that wasn't in KEV last week can be added this week if exploitation starts. A one-time cross-reference goes stale.
Practical examples
Log4Shell (CVE-2021-44228). Added to KEV within days of public disclosure in December 2021, as mass scanning and exploitation began almost immediately. This is the reference case for why KEV exists: a vulnerability that went from "published" to "actively weaponized across the internet" in under a week.
MOVEit Transfer (CVE-2023-34362). A SQL injection vulnerability exploited by the Cl0p ransomware group to exfiltrate data from hundreds of organizations in mid-2023. Added to KEV as soon as CISA confirmed active exploitation. Before the campaign was publicly known, this looked like an unremarkable high-severity finding in any given scan — the KEV entry is what separated it from the pile once real-world exploitation started.
A typical non-KEV finding: an outdated TLS configuration or a locally-exploitable privilege escalation bug. These can carry meaningful CVSS scores but rarely make KEV, because they either require conditions attackers don't commonly have (local access, non-default configuration) or simply haven't been picked up by opportunistic attack tooling. Real risk, but a different tier of urgency than a KEV entry.
How KEV should influence remediation priority
The simplest rule that holds up in practice: KEV membership should act as a floor, not just a factor. A finding in KEV shouldn't merely get a few extra points added to its score — it should be guaranteed a minimum priority tier regardless of what else is true about it. VulnPilot's scoring model implements this directly: KEV contributes 40 of the 100 possible points, and any KEV match forces the composite score to at least 75, overriding whatever CVSS, EPSS, or severity alone would have produced. The reasoning is simple — confirmed active exploitation is not something CVSS or internal severity ratings should be allowed to argue down.
KEV is one of three signals worth combining for real prioritization — see the full comparison in CVSS vs EPSS vs CISA KEV, or read about the complementary predictive signal in what an EPSS score represents.