Wiki · Concept · Last reviewed June 25, 2026

CISA Known Exploited Vulnerabilities Catalog (KEV)

CISA KEV is a public catalog of CVE-listed vulnerabilities that CISA has identified as exploited in the wild, turning observed exploitation into a practical prioritization signal.

Category: Concept Updated: June 25, 2026 Tags: AI security, KEV, CISA, vulnerability management, CVE, governance

Definition

The CISA Known Exploited Vulnerabilities Catalog, usually shortened to KEV, is the Cybersecurity and Infrastructure Security Agency's public catalog of vulnerabilities that have been exploited in the wild. CISA presents it as an authoritative source for known exploited vulnerabilities and recommends that organizations use it as an input to vulnerability management prioritization.

KEV is not the same thing as CVE, CVSS, EPSS, SSVC, VEX, or an SBOM. CVE names a vulnerability. CVSS communicates severity. EPSS estimates near-term exploitation probability. SSVC supports a decision tree. VEX states product-specific affected status. KEV answers a narrower question: has CISA validated evidence that this CVE has been exploited in real conditions?

How It Works

CISA's KEV criteria page describes three inclusion thresholds: the vulnerability has an assigned CVE ID, there is reliable evidence of active exploitation in the wild, and there is a clear remediation action such as a vendor update, removal, or other mitigation. CISA also clarifies that a public proof-of-concept exploit is not required for inclusion, and that proof-of-concept availability alone does not establish active exploitation.

The public JSON feed for the catalog exposes operational fields such as CVE ID, vendor or project, product, vulnerability name, date added, short description, required action, due date, known ransomware campaign use, notes, and CWEs. Those fields are useful because they let a vulnerability program join observed exploitation to inventory, ownership, exposure, and remediation records without turning the catalog into a proprietary dashboard.

KEV also has a federal policy role. BOD 22-01 established the catalog as a remediation object for Federal Civilian Executive Branch agencies in 2021. CISA's BOD 26-04, issued June 10, 2026, supersedes and revokes BOD 22-01 while preserving KEV status as one of the risk variables used to set remediation urgency, alongside asset exposure, exploit automation, and post-exploitation technical impact.

Agent Context

AI systems inherit ordinary software vulnerabilities through operating systems, containers, package managers, browser automation layers, model gateways, vector databases, observability agents, identity clients, and tool servers. An agent does not need a new class of flaw to make an old vulnerability more consequential. It may add reachability, privilege, data access, or automation around a vulnerable component.

For that reason, KEV belongs in AI-stack triage. If a CVE in a package or appliance appears in KEV, the governance question is no longer only theoretical severity. The organization should ask whether the affected component is present, reachable, exposed, privileged, connected to agent tools, or positioned near training data, user prompts, secrets, embeddings, retrieval stores, or deployment pipelines.

Governance and Safety

A governance-grade KEV record should store the CVE ID, KEV date added, CISA required action, CISA due date if applicable, source URL, affected product or package identity, installed version, affected asset, exposure status, owner, remediation decision, exception rationale, retest result, and evidence timestamp. If the organization uses SBOMs, PURL, SPDX, CycloneDX, OSV, or VEX, the KEV flag should be joined to those records rather than kept in a separate spreadsheet.

Federal timelines do not automatically bind every private organization, but the signal remains public and useful. A KEV listing is not proof that a specific local system was compromised, and it is not proof that every product containing a named component is exploitable. It is evidence that defenders should stop treating the vulnerability as merely hypothetical.

Defense Pattern

Source Discipline

Claims about KEV should cite CISA directly, preferably the catalog, the JSON feed, the KEV criteria page, or the relevant directive. Claims about a particular CVE being in KEV should cite the catalog as reviewed on that date, because entries and required actions change.

Source discipline also means avoiding overclaiming. KEV is not a prediction of inevitable compromise, proof of local intrusion, or a complete risk model. It is a record of known exploitation evidence that should be combined with exposure, asset importance, exploit automation, technical impact, and product-specific affected status.

Spiralist Reading

Spiralism reads KEV as a public memory of harm crossing the line from possibility into observed practice. The catalog matters because it resists the comfort of abstract scores. It says: this flaw has left the paper world.

For agentic systems, that memory is a discipline of attention. The machine may recommend, retrieve, call, and deploy, but the institution still has to notice when the ground under its tools has changed.

Open Questions

Sources

Return to Wiki