What Is a KEV? Understanding CISA's Known Exploited Vulnerabilities Catalog

A KEV — Known Exploited Vulnerability — is a vulnerability that attackers are exploiting right now. When Apache Log4Shell (CVE-2021-44228) surfaced in December 2021, it took CISA just days to add it to the Known Exploited Vulnerabilities Catalog. That single listing told every organization in the world: this is not theoretical — patch now. The KEV catalog, maintained by the Cybersecurity and Infrastructure Security Agency, is the authoritative registry of CVEs with confirmed active exploitation. While CVE databases catalog all publicly known flaws and CVSS scores estimate theoretical severity, the KEV catalog answers a more urgent question: is this vulnerability being exploited right now?

What Is the KEV Catalog?

The CISA KEV catalog is a curated list of CVE vulnerabilities that have reliable evidence of active exploitation. CISA launched the catalog in November 2021 alongside Binding Operational Directive (BOD) 22-01, which requires U.S. federal civilian executive branch (FCEB) agencies to remediate KEV-listed vulnerabilities within specified timeframes.

The catalog started with roughly 300 entries at launch, grew past 1,000 by late 2023, and contained approximately 1,500 entries as of early 2026. CISA adds new vulnerabilities multiple times per week as exploitation evidence is confirmed, and each entry includes:

• CVE ID identifying the vulnerability
• Vendor and product affected
• Vulnerability name and description
• Date added to the catalog
• Due date for federal agency remediation
• Required action (typically “Apply updates per vendor instructions”)
• Known ransomware campaign use (yes/no flag)

The catalog is freely available as a JSON feed, a CSV download, and through the CISA website.

KEV vs. CVE vs. CVSS: How They Work Together

These three systems are complementary, not competing. Each answers a different question in the vulnerability management process.

A CVE tells you a vulnerability exists. CVSS tells you how bad it could be. KEV tells you it is being exploited. Effective vulnerability prioritization uses all three signals together.

A Worked Example: Log4Shell

Consider CVE-2021-44228, the Log4Shell vulnerability in Apache Log4j:

• CVE ID: CVE-2021-44228 — assigned by MITRE, giving the flaw a unique, trackable identifier
• CVSS score: 10.0 (Critical) — the maximum possible score, reflecting remote code execution with no authentication required
• KEV status: Added to the KEV catalog on December 10, 2021, just days after public disclosure

All three systems describe the same vulnerability, but each contributes different information. The CVE provides a common name. The CVSS score quantifies theoretical severity. The KEV listing confirms that attackers were already exploiting it in the wild, making it an immediate priority rather than a theoretical risk.

Now consider two vulnerabilities, both with CVSS scores of 9.8 (Critical). One is listed in the KEV catalog; the other is not. The KEV-listed vulnerability should be patched first because there is confirmed evidence of active exploitation, whereas the other — while theoretically severe — may not have working exploits in circulation.

Beyond these three systems, EPSS (Exploit Prediction Scoring System) offers a forward-looking probability estimate of exploitation. Used alongside KEV, EPSS can help identify vulnerabilities that are likely to be exploited soon, even before CISA confirms active exploitation. For more on how CVSS and EPSS complement each other, see our CVSS scoring guide.

Binding Operational Directive 22-01

BOD 22-01 (“Reducing the Significant Risk of Known Exploited Vulnerabilities”) is the CISA directive that established the KEV catalog’s operational role. It covers over 100 federal civilian executive branch agencies and requires them to:

1. Review the KEV catalog on an ongoing basis
2. Remediate each KEV vulnerability by the due date specified in the catalog
3. Report their remediation status to CISA

While BOD 22-01 only legally binds federal civilian agencies, CISA strongly recommends that all organizations — including state and local governments, critical infrastructure operators, and private sector companies — use the KEV catalog as a prioritization input for their vulnerability management programs.

The remediation timelines in BOD 22-01 are aggressive. Vulnerabilities added to the KEV catalog since early 2022 typically carry a remediation deadline of 14 days from the date of addition, though some early entries in the catalog had longer windows of up to six months. This reflects the urgency: if a vulnerability is being actively exploited, delayed patching means continued exposure.

How the KEV Catalog Is Maintained

CISA adds vulnerabilities to the KEV catalog based on three criteria, all of which must be met:

1. The vulnerability has an assigned CVE ID. Only cataloged vulnerabilities with standard identifiers qualify.
2. There is reliable evidence of active exploitation. CISA draws this evidence from multiple sources: federal agency incident reports, industry partners, commercial and open-source threat intelligence feeds, and cybersecurity researchers.
3. A clear remediation action exists. Typically this means a vendor patch or mitigation is available. CISA does not add vulnerabilities for which there is no known fix, as doing so would disclose exploited flaws without offering a path to resolution.

A high CVSS score alone is not enough for KEV inclusion. A vulnerability can be rated Critical (9.0+) and still not appear in the KEV catalog if CISA lacks evidence of active exploitation. Conversely, a Medium-severity vulnerability can be added to the KEV catalog if attackers are exploiting it in the wild. The criterion is exploitation evidence, not theoretical severity.

Vulnerabilities are rarely removed from the KEV catalog once added — even after the remediation deadline passes. While CISA has removed entries in rare cases where evidence of exploitation was later found insufficient, the catalog serves primarily as a persistent historical record of exploitation activity.

Using the KEV Catalog for Patch Prioritization

Most organizations face far more vulnerabilities than they can patch simultaneously. The KEV catalog provides a practical prioritization signal that cuts through the noise. With approximately 245 KEVs added in 2025 alone — roughly 20% growth in a single year — the pace of confirmed exploitation is increasing, making principled prioritization more important than ever.

A Prioritization Framework

A common approach combines CVSS severity with KEV status and deployment context:

1. Critical + KEV-listed + Internet-facing — Patch immediately (within 24-48 hours)
2. Critical + KEV-listed + Internal — Patch within the BOD 22-01 deadline (typically 14 days)
3. Critical + Not KEV-listed — Patch within standard SLA (typically 30 days)
4. High + KEV-listed — Treat as critical; patch within 14 days
5. High + Not KEV-listed — Patch within standard SLA
6. Medium/Low + Not KEV-listed — Schedule for regular maintenance windows

This framework is a starting point. Organizations should adjust based on their risk tolerance, asset criticality, and compensating controls. Adding EPSS as a forward-looking signal can further refine prioritization: a vulnerability with a high EPSS score that is not yet in the KEV catalog may still warrant accelerated patching.

The Ransomware Flag

Since October 2023, CISA has included a “Known Ransomware Campaign Use” flag in KEV entries, as part of its Ransomware Vulnerability Warning Pilot (RVWP). This binary indicator (yes/no) signals whether the vulnerability has been used in ransomware operations. Vulnerabilities flagged for ransomware use warrant heightened urgency due to the potential for data encryption and operational disruption.

KEV and SBOMs: Automated Monitoring

The real power of the KEV catalog emerges when combined with SBOMs. An SBOM provides a machine-readable inventory of every component in your software. The KEV catalog provides a machine-readable list of actively exploited vulnerabilities. Connecting the two creates automated, continuous monitoring.

The logic is straightforward: you cannot check your components against the KEV catalog if you do not know what components you have. Without an SBOM, responding to a new KEV entry means manually investigating every application to determine whether it uses the affected library or product. With SBOMs, you can answer that question in seconds across your entire portfolio.

How It Works

1. Generate SBOMs for all your applications using tools from our SBOM generation guides
2. Ingest SBOMs into a management platform such as sbomify or OWASP Dependency-Track
3. Run vulnerability analysis — tools like Google OSV and Dependency-Track identify known CVEs in your SBOM components
4. Cross-reference with KEV — check which of those CVEs appear in the KEV catalog to identify actively exploited vulnerabilities
5. Prioritize remediation using the KEV due date and your deployment context

Because CISA adds new KEVs multiple times per week, building this cross-referencing into your workflow is important. The KEV catalog’s machine-readable formats make this feasible to automate. For a deeper look at building this pipeline, see our guide on SBOM scanning for vulnerability detection.

Integration Points

Several tools and data sources support KEV-SBOM workflows:

• sbomify — SBOM management platform with vulnerability analysis via Google OSV integration
• CISA KEV JSON feed — Machine-readable, updated as new KEVs are added
• OWASP Dependency-Track — Ingests SBOMs and performs vulnerability analysis using multiple data sources
• Grype — Command-line vulnerability scanner that can match against vulnerability data
• OSV — Google’s open source vulnerability database

For a comprehensive list of analysis tools, see our SBOM resources page.

KEV in the Compliance Context

The KEV catalog intersects with several compliance frameworks:

• Executive Order 14028 directs agencies to improve vulnerability management, and KEV provides the prioritization mechanism.
• CISA minimum elements recommend unique identifiers (like purl or CPE) in SBOMs, enabling automated matching against KEV entries.
• NIST SP 800-53 SI-5 requires receiving and acting on security alerts and advisories — the KEV catalog is a primary source for this control.
• EU CRA requires vulnerability handling processes, and KEV status is a valuable input for prioritizing which vulnerabilities to address first.

Notable KEVs and Real-World Impact

A few high-profile KEV entries illustrate why the catalog matters and how quickly confirmed exploitation can escalate.

Log4Shell (CVE-2021-44228) — Added to the KEV catalog in December 2021, Log4Shell was one of the most consequential vulnerabilities in the catalog’s early history. A remote code execution flaw in the ubiquitous Apache Log4j logging library, it affected hundreds of thousands of applications worldwide. Mass exploitation began within hours of public disclosure, and the vulnerability remains a common attack vector years later.

MOVEit Transfer (CVE-2023-34362) — Added in June 2023, this SQL injection vulnerability in Progress Software’s MOVEit Transfer file-sharing platform was exploited at scale by the Cl0p ransomware group. The campaign compromised over 2,500 organizations and exposed data belonging to tens of millions of individuals, making it one of the largest mass-exploitation events linked to a single KEV entry.

XZ Utils (CVE-2024-3094) — Added in April 2024, this was not a conventional exploit but a deliberate supply chain backdoor planted in the XZ compression library by a contributor who spent years building trust in the open-source project. It was discovered just before shipping in major Linux distributions, narrowly averting a widespread compromise. Its KEV listing underscored that the catalog also tracks supply chain threats when exploitation evidence is confirmed.

These cases share a common thread: each affected widely used software, each was exploited rapidly after (or even before) public disclosure, and each would have been easier to triage for organizations that maintained current SBOMs of their software components.

Frequently Asked Questions

What is a KEV?

A KEV (Known Exploited Vulnerability) is a CVE vulnerability that CISA has confirmed is being actively exploited in real-world attacks. The CISA KEV catalog lists these vulnerabilities along with remediation deadlines and required actions. Being listed in the KEV catalog means the vulnerability is not just theoretically dangerous — it is being used by attackers right now.

What is the KEV catalog?

The CISA Known Exploited Vulnerabilities Catalog is a curated, continuously updated list of CVE vulnerabilities with confirmed active exploitation. Established by Binding Operational Directive 22-01, it requires U.S. federal agencies to remediate listed vulnerabilities within specified timeframes. The catalog is freely available as JSON, CSV, and via the CISA website, and is widely used by both government and private sector organizations for patch prioritization.

How is KEV different from CVE?

CVE is a system for assigning unique identifiers to all publicly known vulnerabilities, regardless of whether they are being exploited. The KEV catalog is a curated subset of CVEs that have confirmed evidence of active exploitation. There are over 330,000 CVE entries but only about 1,500 KEV entries. A CVE tells you a vulnerability exists; a KEV listing tells you attackers are actively using it.

Who must comply with the KEV catalog?

BOD 22-01 legally requires U.S. federal civilian executive branch (FCEB) agencies to remediate KEV-listed vulnerabilities by the specified due dates. However, CISA strongly recommends that all organizations use the KEV catalog for prioritization. Many private sector organizations, state and local governments, and critical infrastructure operators have adopted KEV as a standard input to their vulnerability management programs.

How can I monitor the KEV catalog automatically?

Generate SBOMs for your applications, ingest them into a vulnerability management platform like OWASP Dependency-Track, and use vulnerability analysis to identify known CVEs in your components. Then cross-reference those CVEs against the KEV catalog. CISA publishes the KEV catalog as a machine-readable JSON feed that can be consumed by automated tools.

How often is the KEV catalog updated?

CISA updates the KEV catalog multiple times per week. New vulnerabilities are added as soon as CISA confirms reliable evidence of active exploitation and verifies that a remediation action exists. There is no fixed schedule — additions are driven by threat intelligence, so the catalog may see several updates in a single week or occasional pauses.

How many vulnerabilities are in the KEV catalog?

As of early 2026, the KEV catalog contains approximately 1,500 entries. The catalog launched with about 300 entries in November 2021, passed 1,000 in late 2023, and has been growing at roughly 20% per year. Despite this growth, the KEV catalog remains a small fraction of the 330,000+ CVEs in the broader vulnerability ecosystem — which is precisely what makes it useful for prioritization.