What Is the CISA Known Exploited Vulnerabilities Catalog?

Every week, tens of thousands of open vulnerabilities compete for the same limited remediation capacity. Only a small fraction of them will ever be used in a real attack, and for years security teams had no authoritative, public way to tell which ones. The CISA Known Exploited Vulnerabilities Catalog was created to close that gap.

What Is the CISA Known Exploited Vulnerabilities Catalog?

The CISA Known Exploited Vulnerabilities (KEV) catalog is a public list of vulnerabilities that have been confirmed as exploited in the wild. It is maintained by the U.S. Cybersecurity and Infrastructure Security Agency (CISA).

CISA launched the catalog in November 2021 with around 300 entries. It has grown steadily since then, with new vulnerabilities added as evidence of exploitation emerges. The catalog is free to use and available on CISA’s website as a searchable list, as CSV and JSON downloads, and through an email subscription for new additions.

The core idea is simple. A KEV entry isn’t a prediction that a vulnerability might be exploited. It confirms that attackers are already exploiting it.

Why CISA Created the KEV Catalog

Most vulnerability programs have traditionally prioritized by severity, usually CVSS scores. The problem is that severity describes how bad a vulnerability could be in theory, not whether anyone is actually using it. Teams end up with backlogs full of “criticals” that pose little real-world threat, while actively exploited vulnerabilities wait in the same queue.

The KEV catalog shifts the focus from theoretical severity to observed attacker behavior. It launched alongside Binding Operational Directive (BOD) 22-01, which requires U.S. federal civilian agencies to remediate KEV-listed vulnerabilities by set due dates.

The directive only binds federal agencies, but CISA strongly recommends that every organization use the catalog as an input to its vulnerability prioritization framework. In practice, it has become a widely used baseline across both the public and private sectors.

How a Vulnerability Makes the List

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

1. It has an assigned CVE ID. Every entry maps to a specific, publicly tracked vulnerability.
2. There is reliable evidence of active exploitation. Attackers must have exploited the vulnerability, or attempted to, in the wild. A published proof-of-concept or mass scanning activity doesn’t qualify on its own.
3. There is clear remediation guidance. A vendor patch, mitigation, or workaround must exist, so organizations have a concrete action to take.

This high bar is what makes the catalog useful. Because every entry is confirmed and actionable, a KEV listing is a strong signal with very little noise.

What’s Included in Each KEV Entry

Each entry in the catalog contains a consistent set of fields:

• CVE ID, vendor, and product: identifies exactly what’s affected, which makes it possible to match entries against your environment.
• Vulnerability name and short description: a brief summary of the flaw and its impact.
• Date added: when CISA added the vulnerability to the catalog.
• Required action: what to do about it, usually applying vendor updates, following mitigation guidance, or discontinuing use of the product if no fix is available.
• Due date: the remediation deadline for federal agencies under BOD 22-01.
• Known ransomware campaign use: whether the vulnerability has been linked to ransomware activity.
• Notes: links to vendor advisories and other references.

For non-federal organizations, the due date and ransomware fields are especially useful. The due date offers a ready-made benchmark for remediation timelines. The ransomware flag helps separate the most urgent entries from the rest, even within an already high-priority list.

Who Should Use It, and How

Although BOD 22-01 applies only to federal agencies, the catalog is relevant to any organization running common enterprise software, network devices, or cloud services. Practical ways to put it to work include the following:

• Match KEV entries against your environment. Cross-reference the catalog with scanner findings and your asset inventory to find which listed vulnerabilities you’re actually exposed to. Doing this by hand in spreadsheets doesn’t scale, so automate it wherever possible.
• Treat a KEV listing as an escalation trigger. Any finding that appears in the catalog should move to the top of the queue, especially on internet-facing or business-critical assets.
• Use BOD 22-01 timelines as an SLA reference point. Federal deadlines provide a defensible starting point for internal remediation SLAs, which you can then tighten or relax based on asset criticality.
• Plan for vulnerabilities you can’t patch. When a fix isn’t immediately possible, apply mitigations or compensating controls, and document the decision.
• Monitor continuously. New entries are added regularly, and older CVEs are sometimes added years after disclosure once exploitation is confirmed.

Limitations to Keep in Mind

The KEV catalog is a valuable signal, but it has limits worth understanding:

• It isn’t comprehensive. CISA only lists vulnerabilities that meet all three criteria and that it can verify, so some exploited vulnerabilities are missing or added after exploitation begins. Alternatives such as VulnCheck KEV aim to provide broader and faster coverage.
• It doesn’t know your environment. A KEV entry on an isolated test machine carries very different risk than the same entry on a production server exposed to the internet.
• It doesn’t cover what hasn’t happened yet. The catalog reflects confirmed exploitation, so it says little about vulnerabilities likely to be targeted next. That’s where predictive signals like EPSS come in.

For these reasons, the catalog works best as one input among several. Combining it with exploit prediction, broader vulnerability threat intelligence, and business context gives a far more accurate picture of real risk.

How Seemplicity Uses KEV Data

Seemplicity aggregates findings from across your security tools, then normalizes and deduplicates them into a single view. Each finding is automatically enriched with KEV status, along with VulnCheck KEV, EPSS, and business context. As a result, actively exploited vulnerabilities on critical assets rise to the top without manual cross-referencing.

From there, Seemplicity’s AI Analysts triage findings, and prioritized fixes are routed to the right owners and tracked through to closure.

Using KEV as Your Starting Point, Not Your Whole Strategy

The CISA Known Exploited Vulnerabilities Catalog answers one of the most important questions in vulnerability management: which of these weaknesses are attackers actually using? It’s free, authoritative, and easy to build into existing processes.

On its own, though, a list doesn’t reduce risk. The value comes from matching it to your environment, layering in context, and making sure every KEV-listed finding reaches someone who can fix it on time.