CISA’s Known Exploited Vulnerabilities catalog is a short, deliberately curated list of CVEs that CISA has confirmed are being used by attackers right now, not a ranking of the most dangerous bugs in existence. It was created under Binding Operational Directive 22-01 in November 2021 to force US federal civilian agencies to patch a specific, evidence-backed set of vulnerabilities on fixed deadlines. Private organizations copy the list widely, but most teams that pull it into a scanner or ticketing system have never read the inclusion criteria that decide what makes it in, which is where most of the confusion about how to use it actually starts.
The three inclusion criteria a CVE must meet before CISA adds it
CISA does not add a CVE to KEV because it scored high on CVSS, because a proof-of-concept exists on GitHub, or because a vendor issued an urgent advisory. The catalog has exactly three gating criteria, and a CVE has to clear all three before it appears.
- The vulnerability has an assigned CVE ID. No ID, no listing. A vendor security bulletin describing a flaw without a CVE reference sits outside the process entirely until MITRE or a CNA assigns one.
- There is reliable evidence of active exploitation in the wild. This is the criterion people misread most often. CISA defines active exploitation as a threat actor executing malicious actions on a system by taking advantage of the vulnerability, sourced from incident response engagements, threat intelligence reporting, or vendor confirmation of observed abuse. A working exploit module in a penetration testing framework does not qualify on its own. Neither does a researcher’s blog post demonstrating a proof of concept in a lab.
- There is a clear remediation action. A patch, an official vendor mitigation, or a documented workaround has to exist. CISA generally will not list a flaw it cannot tell an agency how to fix, because the directive’s entire mechanism depends on there being an action to complete before the deadline.
The practical effect is that a CVSS 9.8 remote code execution bug with no observed exploitation stays off KEV indefinitely, while a CVSS 5.3 bug under active ransomware use gets added within days. Severity score and KEV membership are answering two different questions: one is about theoretical impact, the other is about confirmed, current attacker behavior.
Catalog anatomy: the fields in the JSON and CSV, and what each one is good for
CISA publishes the catalog as JSON and CSV at a stable URL, updated in place rather than versioned as dated snapshots. Each entry carries the same field set, and most of the operational value sits in fields teams tend to ignore.
| Field | What it tells you |
|---|---|
| cveID | The join key for matching against scanner output and your CMDB. |
| vendorProject / product | Coarse filtering when you need to know exposure for one vendor fast, for example during an active campaign against a specific VPN appliance. |
| dateAdded | The field to diff on for change detection. New rows here are your alert trigger, not the CVE’s original disclosure date. |
| shortDescription / requiredAction | Plain-language summary and the specific fix CISA expects, useful for populating a ticket body without writing it by hand. |
| dueDate | The federal remediation deadline. Not binding on a private company, but a useful anchor for setting your own internal SLA relative to it. |
| knownRansomwareCampaignUse | “Known” or “Unknown.” This is the single highest-signal field in the whole schema for prioritization, since it separates opportunistic exploitation from confirmed ransomware tooling. |
| cwes | The underlying weakness class, useful for spotting patterns across a year of additions, such as how often the list fills with the same authentication-bypass or deserialization pattern from a given vendor. |
A simple, durable pattern is a scheduled pull of the JSON feed, a diff against yesterday’s cveID list, and an automatic flag on any match against your asset inventory where knownRansomwareCampaignUse equals “Known.” That one field alone should be enough to interrupt a sprint.
Why KEV is small on purpose: evidence of exploitation, not suspicion of it
The catalog runs to a few thousand entries against a CVE namespace that has grown past a quarter million records. That gap is not a coverage gap CISA is racing to close, it is the design. KEV works as a forcing function precisely because it is narrow: if every critical-severity CVE qualified, the deadline mechanism in BOD 22-01 would apply to thousands of items at once and stop functioning as a priority signal for anyone.
The bar for evidence is intentionally higher than “exploitable.” Security research demonstrating that a bug can be weaponized is common and constant; confirmed field use against real victims is comparatively rare and takes real intelligence work to establish. CISA’s analysts pull from US government sources, vendor disclosures that explicitly state observed abuse, and third-party threat intelligence with enough corroboration to stand behind a federal mandate. A vulnerability can sit in a threat actor’s toolkit for a while before that evidence surfaces publicly and clears CISA’s bar, which is a lag worth remembering when you treat the list as a real-time feed rather than a confirmed-and-lagging one.
KEV as a floor, not a ceiling: what its absence does and does not mean
Absence from KEV tells you CISA has not yet confirmed active exploitation. It does not tell you a CVE is safe, unexploited, or low priority. There are at least three reasons a genuinely exploited CVE can be missing from the list: the evidence has not reached CISA yet, the evidence exists but is still working through their internal review, or the exploitation is happening in a way that has not been publicly attributed to a specific CVE at all.
Treat KEV membership as the minimum bar your patch program has to clear, not the whole prioritization model. Layer it with the Exploit Prediction Scoring System (EPSS) for a probability estimate on CVEs that have not crossed KEV’s confirmation threshold, and cross both against your own exposure data: whether the affected asset is internet-facing, whether compensating controls already sit in front of it, and how critical the asset is to the business. A CVE with a high EPSS percentile and direct internet exposure deserves urgency close to a KEV entry even before CISA lists it. Platforms that combine KEV membership, EPSS percentile, and asset exposure into a single working score, SITEY among them, exist specifically to stop teams from treating “not on KEV yet” as equivalent to “not urgent.” That combined view belongs in the same place your team already tracks vulnerability lifecycle status, so a finding’s KEV state changes its priority automatically rather than waiting for someone to re-check the feed by hand.
Update cadence, backfilled entries, and the rare removals
CISA does not publish on a fixed schedule. Additions happen whenever evidence clears review, which in practice means anywhere from zero to several updates in a week, with same-day additions during active, high-profile campaigns. There is no monthly batch to wait for.
Backfilling happens more often than people expect. CISA sometimes adds a CVE from several years back once new intelligence establishes it was exploited earlier than anyone confirmed at the time. This matters for audit trails: a finding your team closed two years ago as “patched, low severity” can reappear on your radar as a KEV entry, and you need the historical remediation record to show you were never actually exposed, or that you closed it before the KEV listing existed. Keep patch and retest evidence rather than deleting closed tickets.
Removals are rare and almost never happen because exploitation “stopped.” The usual cause is a CVE ID getting rejected, merged, or otherwise invalidated by its numbering authority, which occasionally forces CISA to pull or correct an entry. The notes field is where these corrections tend to show up first.
Because there’s no fixed release window, the only reliable way to stay current is to pull the feed on a schedule of your own, daily is reasonable for most teams, and diff on dateAdded rather than assuming a weekly digest will catch everything.
Operationalizing KEV for a private company that is not bound by US federal deadlines
BOD 22-01’s due dates apply to federal civilian agencies, not to a private company, but the deadline structure is worth adapting rather than discarding. A concrete internal SLA gives your team a decision rule instead of a debate every time a new entry lands.
| Condition | Suggested action window |
|---|---|
| KEV-listed, internet-facing asset | Patch or apply the vendor mitigation within 48 hours |
| KEV-listed, internal-only asset | Patch within 7 days |
| KEV-listed with knownRansomwareCampaignUse = Known | Same-day compensating control (isolate the host, disable the exposed service, add a targeted WAF or IPS rule) even if the full patch takes longer |
| High EPSS percentile, not yet on KEV, internet-facing | Treat as KEV-equivalent for scheduling purposes |
Wire the match into your ticketing pipeline rather than a manual review: when a scanner finding’s CVE ID matches a KEV entry, auto-open a priority ticket and tag it with the ransomware-use flag so triage doesn’t have to look it up separately. This is also where triage logic earns its keep, since a KEV hit should override a generic severity score rather than compete with it in a queue.
Compliance auditors under PCI DSS, SOC 2, and ISO 27001 increasingly ask whether an organization tracks KEV as part of a documented, risk-based patch process, so mapping your KEV-driven SLA table directly to the relevant control language is a low-effort way to produce that evidence during an audit; a compliance mapping view that ties specific findings to specific framework clauses saves the manual cross-referencing that usually happens the week before an assessment.
One more detail worth building into the workflow: closing a KEV-tagged finding on “patch deployed” status alone is weaker evidence than it looks, because this is the exact subset of vulnerabilities attackers are provably using today. A verified re-test against the same target after the patch job reports success, the kind of check that belongs in a dedicated retest and closure step feeding your patch management record, catches the case where a patch script exits cleanly but the service was never restarted or the fix didn’t actually apply. Platforms that automate this phase, such as SITEY, re-test the specific finding instead of trusting the patch command’s exit code, which matters most precisely on the findings your KEV-driven SLA marked urgent in the first place.
About SITEY
SITEY is an autonomous vulnerability management platform. It discovers, validates, prioritizes, remediates and re-tests vulnerabilities through an eight-phase automated pipeline, unifying output from 17 integrated scanners. SITEY is self-hosted: it runs in your own infrastructure and your findings are stored there. Outbound connections are limited to licence activation and the optional services you enable, such as an AI provider, CVE enrichment and patch catalogues. Pricing is 599 USD per month or 5,999 USD for a perpetual lifetime license. See pricing or how the platform works.