Known Exploited Vulnerabilities catalog (KEV)

What is the KEV catalog?

The KEV catalog is CISA's authoritative list of vulnerabilities known to be exploited in the wild. Where CVSS rates severity and EPSS forecasts exploitation, KEV records a fact: someone has actually used this flaw against a real system. It began in November 2021 and, as of late September 2026, contains over 1,700 entries. It is published as human-readable pages and as a machine-readable JSON and CSV feed, and it is free for anyone.

How does a vulnerability get onto KEV?

CISA adds an entry only when all three of these hold:

1. The vulnerability has an assigned CVE ID.
2. There is reliable evidence of active exploitation in the wild.
3. There is a clear remediation action, such as a vendor update or a defined mitigation.

"Active exploitation" is specific. CISA counts both attempted and successful exploitation where the actor's intent is to compromise a real target, but it explicitly excludes scanning, security research, and the existence of a public proof-of-concept. A published PoC is not exploitation, and a PoC is not required for listing. This is why KEV is a high-signal list: absence of a PoC does not keep a flaw off it, and presence of one does not put it on.

The directive behind the due dates

KEV was created under Binding Operational Directive 22-01 (November 3, 2021), which required U.S. federal civilian executive branch (FCEB) agencies to remediate listed vulnerabilities on a fixed schedule: six months for CVEs assigned before 2021, and two weeks for everything else.

On June 10, 2026, CISA issued BOD 26-04, which supersedes and revokes BOD 22-01. It keeps the KEV catalog but replaces the flat two-week rule with a risk-based timeline. The urgency of each vulnerability is now derived from four variables CISA publishes: whether the asset is publicly exposed, whether the CVE is in KEV, whether an adversary can automate exploitation, and whether exploitation grants partial or total control. The remediation deadline is looked up from a 16-row table. For a KEV-listed, internet-exposed, automatable flaw granting total control, agencies have 3 calendar days and must perform a forensic triage of the asset; less urgent combinations extend to 14 days, 60 days, or "fix on next system upgrade". The clock starts when CISA adds the CVE to KEV or when the agency first identifies it on an asset, whichever is earlier.

These deadlines bind federal agencies, but CISA strongly encourages every organization to remediate KEV entries as part of its own vulnerability management.

The fields in the catalog

Each entry in the JSON feed is one object. Here is a real one, from CISA's feed:

{
  "cveID": "CVE-2023-4966",
  "vendorProject": "Citrix",
  "product": "NetScaler ADC and NetScaler Gateway",
  "vulnerabilityName": "Citrix NetScaler ADC and NetScaler Gateway Buffer Overflow Vulnerability",
  "dateAdded": "2023-10-18",
  "shortDescription": "Citrix NetScaler ADC and NetScaler Gateway contain a buffer overflow vulnerability that allows for sensitive information disclosure when configured as a Gateway or AAA virtual server.",
  "requiredAction": "Apply mitigations and kill all active and persistent sessions per vendor instructions OR discontinue use of the product if mitigations are unavailable.",
  "dueDate": "2023-11-08",
  "knownRansomwareCampaignUse": "Known",
  "forensicTriage": "No",
  "notes": "https://support.citrix.com/article/CTX579459 ; https://nvd.nist.gov/vuln/detail/CVE-2023-4966",
  "cwes": ["CWE-119"]
}

The fields worth knowing:

• cveID, vendorProject, product, vulnerabilityName: what and whose.
• dateAdded / dueDate: when CISA listed it and the FCEB remediation deadline. Here the gap is three weeks, a BOD 22-01-era entry; entries added under BOD 26-04 use the risk-based timeline above.
• requiredAction: the specific fix or mitigation, or removal if none exists.
• knownRansomwareCampaignUse: Known or Unknown, flagging whether the flaw has been seen in a ransomware campaign. Unknown means CISA lacks confirmation, not that it is safe.
• forensicTriage: Yes or No, added for BOD 26-04, marking entries whose remediation must be accompanied by a forensic triage of the asset.
• cwes: the associated CWE identifiers.

The top-level object also carries catalogVersion, dateReleased and count.

How do you use KEV in prioritization?

KEV is the strongest single prioritization signal available for free, because it is confirmed history rather than a score or a forecast.

1. Cross-reference your asset inventory against the KEV feed daily. Any match is a vulnerability an attacker is actively using somewhere.
2. Put KEV matches at the top of the queue, ahead of higher-CVSS flaws that show no exploitation. When a CVE is on KEV, KEV takes precedence over its EPSS forecast, even if that forecast is low.
3. For the vulnerabilities not on KEV, rank by EPSS probability and by exposure in your environment.
4. Use knownRansomwareCampaignUse and, for FCEB systems, forensicTriage to escalate within the KEV set.

What KEV absence does not mean

A vulnerability missing from KEV is not proven safe. KEV lists only what CISA has reliable evidence of being exploited, so it lags real-world activity, omits exploitation that has not been observed or reported, and cannot cover flaws with no clear fix. A brand-new zero-day is exploited before it is listed. KEV is a floor for prioritization, the set you cannot defer, not a complete picture of what is dangerous. Pair it with EPSS for forecasting and with testing for whether a flaw is reachable in your own systems.

Written by Parameter · Last reviewed September 27, 2026