Category: Vulnerability Management

Known Exploited Vulnerabilities

Also known as: KEV, Known Exploitable Vulnerabilities, KEV Catalog entries

Simply put

Known Exploited Vulnerabilities are security weaknesses in software, hardware, or systems that have been confirmed to be actively used by attackers in real-world incidents. They are tracked in a catalog maintained by CISA (the Cybersecurity and Infrastructure Security Agency) to help organizations prioritize which vulnerabilities to fix first. Because these vulnerabilities have demonstrated real-world exploitation, they typically represent a higher and more immediate risk than vulnerabilities that are only theoretical.

Formal definition

A Known Exploited Vulnerability (KEV) is a documented security weakness in software, hardware, or firmware that threat actors have demonstrably exploited, as confirmed through threat intelligence, incident reports, or interagency collaboration. CISA maintains the authoritative KEV Catalog, and a vulnerability is added only when exploitation has been verified through such evidence. The KEV designation appears on NVD vulnerability detail pages when a CVE is included in CISA's catalog. The KEV Catalog serves as a prioritization mechanism for vulnerability management programs, signaling that a given CVE poses a confirmed, active risk rather than a purely theoretical one. It is important to note that the KEV Catalog does not represent all exploited vulnerabilities; it reflects only those that have met CISA's specific inclusion criteria, meaning that absence from the catalog does not imply a vulnerability is unexploited.

Why it matters

Organizations face an overwhelming volume of disclosed vulnerabilities each year, making it impractical to remediate every issue simultaneously. The Known Exploited Vulnerabilities (KEV) Catalog provides a critical prioritization signal by identifying vulnerabilities that threat actors have demonstrably used in real-world attacks. Because these vulnerabilities carry confirmed exploitation evidence rather than theoretical risk, they typically warrant accelerated patching timelines and heightened attention from security teams.

For federal agencies, CISA's Binding Operational Directive 22-01 mandates remediation of KEV Catalog entries within specified timeframes, giving the catalog direct regulatory weight. Even outside the federal government, many private-sector organizations have adopted the KEV Catalog as a prioritization input for their vulnerability management programs, treating KEV inclusion as a strong indicator that a vulnerability poses immediate, actionable risk.

It is important to recognize, however, that the KEV Catalog does not represent the full universe of exploited vulnerabilities. It reflects only those that have met CISA's specific inclusion criteria, meaning that a vulnerability's absence from the catalog does not imply it is unexploited. Organizations should use the KEV Catalog as one prioritization input alongside other threat intelligence sources, severity scores, and asset-context information rather than as a sole decision-making tool.

Who it's relevant to

Vulnerability Management Teams

KEV Catalog entries serve as a high-confidence prioritization signal for teams responsible for triaging and remediating vulnerabilities across an organization's infrastructure. Integrating KEV data into scanning and ticketing workflows helps ensure that confirmed-exploited issues receive accelerated attention.

CISOs and Security Leadership

The KEV Catalog provides a defensible, evidence-based framework for communicating risk prioritization decisions to executive stakeholders and boards. It helps justify resource allocation toward vulnerabilities with demonstrated real-world impact.

Federal Government Agencies

Under CISA's Binding Operational Directive 22-01, federal civilian executive branch agencies are required to remediate KEV Catalog entries within mandated timeframes, making the catalog a direct compliance obligation.

Software Supply Chain Security Practitioners

Teams responsible for evaluating third-party software, open-source dependencies, or vendor risk can use KEV data to assess whether components in their supply chain carry vulnerabilities with confirmed exploitation, informing procurement and dependency management decisions.

Application Security Engineers

AppSec teams can cross-reference KEV Catalog entries against application dependencies and libraries identified through SCA tools or SBOMs, helping to prioritize remediation of actively exploited vulnerabilities within the application stack.

Threat Intelligence Analysts

The KEV Catalog provides a curated, authoritative dataset of vulnerabilities with confirmed exploitation activity, which analysts can use to enrich threat models, track adversary tooling trends, and correlate with observed attack campaigns.

Inside KEV

CVE Identifiers

Each entry in a Known Exploited Vulnerabilities (KEV) catalog references a specific Common Vulnerabilities and Exposures (CVE) identifier, providing a standardized way to track and cross-reference the vulnerability across tools and databases.

Evidence of Active Exploitation

Inclusion in a KEV catalog requires confirmed evidence that the vulnerability has been exploited in real-world attacks, distinguishing these entries from theoretical or proof-of-concept-only vulnerabilities.

Affected Products and Vendors

Each KEV entry typically identifies the specific vendor and product or component affected by the vulnerability, enabling organizations to determine whether the vulnerability is relevant to their environment.

Remediation Due Dates

In authoritative KEV catalogs such as the one maintained by CISA, entries include required remediation deadlines that federal agencies must meet, and that serve as strong guidance for private sector organizations.

Vulnerability Description

A brief description of the vulnerability, including the nature of the flaw (such as remote code execution, privilege escalation, or authentication bypass) and its potential impact when exploited.

Date Added

The date on which the vulnerability was added to the KEV catalog, which provides context on the recency of confirmed exploitation activity and helps organizations prioritize response timelines.

Common questions

Answers to the questions practitioners most commonly ask about KEV.

Does the KEV catalog include all vulnerabilities that have ever been exploited in the wild?

No. The KEV catalog maintained by CISA represents a curated subset of vulnerabilities with confirmed, active exploitation. Many vulnerabilities that have been exploited historically or in limited contexts may not appear in the catalog. Inclusion requires evidence of active exploitation and the existence of a remediation action, so the catalog should not be treated as an exhaustive list of all exploited vulnerabilities.

If a vulnerability is not on the KEV list, does that mean it is safe to deprioritize?

Not necessarily. Absence from the KEV catalog does not indicate that a vulnerability is unexploited or low risk. The catalog has specific inclusion criteria, and exploitation may be occurring without meeting those criteria or without sufficient evidence being reported to CISA. Organizations should use KEV as one prioritization signal among others, such as CVSS scores, EPSS probabilities, and asset-specific context, rather than as a sole basis for deprioritization.

How should organizations integrate KEV data into their vulnerability management workflows?

Organizations typically integrate KEV data by cross-referencing it against their software bill of materials (SBOM) or vulnerability scan results. When a detected vulnerability matches a KEV entry, it can be automatically escalated in priority within ticketing or patch management systems. Many scanning and SCA tools now support KEV enrichment natively, allowing teams to flag KEV-listed vulnerabilities during triage without manual lookups.

What remediation timelines should organizations target for KEV-listed vulnerabilities?

CISA's Binding Operational Directive 22-01 requires federal agencies to remediate KEV-listed vulnerabilities within specified due dates, typically ranging from two weeks to a few months depending on the entry. While non-federal organizations are not bound by this directive, many adopt similar aggressive timelines as a best practice. The specific due date for each vulnerability is published in the catalog alongside the CVE entry.

Can KEV data be used effectively alongside EPSS for vulnerability prioritization?

Yes, and this is a common approach. EPSS provides a probability score estimating the likelihood of exploitation in the near term, while KEV confirms that exploitation has already been observed. Using both together allows organizations to prioritize confirmed exploited vulnerabilities (KEV) while also surfacing high-probability threats that may not yet be on the KEV list. Vulnerabilities appearing in both KEV and with high EPSS scores typically warrant the most urgent attention.

How frequently is the KEV catalog updated, and how should teams monitor for changes?

CISA updates the KEV catalog on a rolling basis as new evidence of exploitation is confirmed, with no fixed schedule for additions. Organizations should monitor the catalog through automated means, such as subscribing to CISA's update feeds, using the KEV JSON or CSV data downloads in automated pipelines, or relying on vulnerability management tools that pull KEV data regularly. Manual periodic checks are typically insufficient given the frequency of updates.

Common misconceptions

If a vulnerability is not in the KEV catalog, it is not being actively exploited.

The KEV catalog, most notably CISA's, includes only vulnerabilities for which there is sufficient confirmed evidence of exploitation. Many vulnerabilities may be actively exploited in the wild but have not yet been added due to evidence thresholds, reporting delays, or scope limitations of the catalog maintainer.

KEV entries only matter for federal agencies bound by CISA's Binding Operational Directives.

While CISA's KEV catalog carries mandatory remediation requirements for U.S. federal civilian agencies, the catalog is widely used by private sector organizations as a high-confidence signal for vulnerability prioritization. The presence of a vulnerability in the KEV catalog indicates real-world risk regardless of regulatory obligation.

Addressing all KEV entries is sufficient for a strong vulnerability management program.

The KEV catalog represents a subset of high-priority vulnerabilities with confirmed exploitation. A mature vulnerability management program must also address vulnerabilities with high exploitability scores, critical severity ratings, or relevance to the organization's specific threat landscape, even if those vulnerabilities have not yet appeared in a KEV catalog.

Best practices

Integrate the CISA KEV catalog as a prioritization input into your vulnerability management workflow, using it alongside CVSS scores, EPSS probabilities, and asset criticality to triage remediation efforts.

Automate monitoring of KEV catalog updates so that newly added vulnerabilities trigger immediate assessment against your software inventory, including both deployed infrastructure and third-party dependencies in your software supply chain.

Cross-reference KEV entries with your Software Bill of Materials (SBOM) to quickly determine whether any known exploited vulnerabilities affect components in your applications or their transitive dependencies.

Establish internal remediation SLAs for KEV-listed vulnerabilities that are comparable to or stricter than CISA's recommended timelines, even if your organization is not subject to Binding Operational Directives.

Use KEV data to inform risk acceptance decisions: vulnerabilities with confirmed active exploitation should typically not be accepted as residual risk without compensating controls in place.

Incorporate KEV catalog checks into CI/CD pipelines and dependency scanning processes so that builds or releases can be flagged when they include components affected by known exploited vulnerabilities.