KEV (Known Exploited Vulnerabilities Catalog)

Criteria for inclusion

CISA adds a vulnerability to the catalog when it meets three criteria:

1. It has an assigned CVE ID.
2. It has been exploited or is under active exploitation. CISA defines this as reliable evidence that malicious code was executed on a system without the owner’s permission, and it counts attempted exploitation, such as an exploit that fails because the target is patched or is a honeypot, as well as successful exploitation. Scanning, security research, and proof-of-concept code on their own do not count.
3. There is clear remediation guidance, such as a vendor update to apply, or removing an end-of-life product that can’t be updated.

How easy a vulnerability would be to exploit, such as whether a proof of concept is public or whether it can be reached over a network without privileges, is not a criterion. A vulnerability with a modest CVSS score qualifies once it is being exploited, provided it also has a CVE ID and clear remediation guidance, and a Critical one does not qualify until it is. That makes KEV status evidence about likelihood, which a severity score alone does not provide.

Who must act on it

U.S. federal civilian executive branch agencies are required to remediate KEV vulnerabilities within timeframes set by Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk. Under that directive, a KEV vulnerability gets three days or 14 days, depending on whether the affected asset is publicly exposed, whether exploitation can be automated, and whether it gives partial or total control. A forensic triage, to check whether the system was already compromised, is added when a KEV vulnerability gives total control of a system that is publicly exposed or whose exploitation can be automated. The clock starts when CISA adds the vulnerability to the catalog or when the agency finds it on an asset, whichever comes first. Other organizations, including state, local, tribal, and territorial governments and private industry, are not bound by the directive, but CISA strongly recommends that all organizations monitor the catalog and prioritize remediation of the vulnerabilities in it.

For example, CVE-2026-21962, a CVSS v3.1 10.0 vulnerability in Oracle HTTP Server and the Oracle WebLogic Server Proxy Plug-in, was added to the catalog on August 24, 2026, with a due date of August 27, 2026.

What an entry contains

Each entry records the CVE ID, the vendor and product, a short description, the date CISA added it, the due date for federal agencies, the required action, and whether the vulnerability is known to have been used in ransomware campaigns, and whether a forensic triage of affected systems is required. The catalog is published as a web page and as CSV and JSON files, so it can feed a vulnerability management process automatically. As of catalog version 2026.10.16, it listed 1,748 vulnerabilities, 361 of them marked as known to have been used in ransomware campaigns.

The catalog is not a complete list of every vulnerability being exploited. It covers what CISA has evidence for, and CISA accepts nominations from anyone with evidence of an exploited vulnerability that isn’t listed yet.

History

• November 3, 2021: CISA established the catalog under Binding Operational Directive 22-01, Reducing the Significant Risk of Known Exploited Vulnerabilities. The earliest entries carry this date added.
• June 10, 2026: CISA issued BOD 26-04, which superseded BOD 22-01 and BOD 19-02, carried forward its KEV criteria, and combined KEV status with other factors, such as whether an asset is publicly exposed, to set remediation timelines.

Sources

• Reducing the Significant Risk of Known Exploited Vulnerabilities, CISA. Retrieved October 20, 2026.
• Known Exploited Vulnerabilities Catalog, version 2026.10.16 (JSON feed), CISA. Retrieved October 20, 2026.
• BOD 26-04: Prioritizing Security Updates Based on Risk, including Table 1: Remediation Timelines, CISA. Retrieved October 20, 2026.