KEV (Known Exploited Vulnerabilities)

The Known Exploited Vulnerabilities catalog is maintained by the Cybersecurity and Infrastructure Security Agency (CISA) and lists Common Vulnerabilities and Exposures (CVEs) that have been confirmed as actively exploited in real-world attacks. Known Exploited Vulnerability status significantly elevates the urgency of a vulnerability, as a CVE that attackers are actively using demands faster remediation than one that is merely disclosed. Black Kite surfaces KEV-tagged findings in vendor assessments.

KEV, short for Known Exploited Vulnerabilities, is the catalog CISA maintains of security flaws with reliable evidence of active exploitation in the wild. The CISA KEV catalog separates the vulnerabilities attackers are actually using from the tens of thousands disclosed each year, and in a vendor ecosystem it marks where third-party exposure is already weaponized.

The scale problem is what makes the catalog necessary. More than 48,000 CVEs were disclosed in 2025, and roughly 800 of them were exploited in the wild. KEV is the shortlist. Every entry represents a vulnerability where the theoretical debate is over, which is why security teams and vulnerability management programs treat the known exploited vulnerabilities catalog as the top of the cybersecurity queue.

What Puts a Vulnerability in the CISA KEV Catalog?

A vulnerability enters the CISA KEV catalog only when it meets all three of CISA's thresholds. The bar is deliberately narrow, because a KEV list that included everything plausible would be no more useful than the CVE feed it filters.

An assigned CVE ID. The vulnerability must be formally identified and tracked in the Common Vulnerabilities and Exposures system.
Reliable evidence of active exploitation. Not proof-of-concept code, not researcher speculation. Confirmed use in the wild by malicious cyber actors.
A clear remediation action. Usually a vendor-provided update. A flaw with no available fix doesn't qualify, because the catalog exists to drive rapid remediation rather than alarm.

That third criterion is the one people miss. KEV isn't a list of the most dangerous security flaws in existence. It's a list of dangerous known vulnerabilities you can do something about today, which is what makes it usable as a security prioritization tool rather than a threat feed.

What Kinds of Vulnerabilities End Up in the KEV Catalog?

Flaws that give an attacker control, access, or persistence with minimal effort. CISA describes catalog entries as frequent attack vectors, and the weakness classes that recur are the ones that convert a single exposed system into a foothold.

Remote code execution. The most consequential class, because remote code execution on an internet-facing service hands an attacker the host without credentials.
Improper authentication and authorization bypass. Flaws that let an unauthenticated request reach functions meant for administrators.
Deserialization of untrusted data. A frequent path to remote code execution in enterprise web platforms, and the mechanism behind several of the highest-profile KEV entries.
Path traversal and file upload flaws. Common in the file transfer platforms that sit between organizations and carry sensitive data in bulk.

The named entries are recognizable. Microsoft Windows components appear in the catalog repeatedly, as does Microsoft SharePoint, where the ToolShell chain exploiting CVE-2025-53770 produced a wave of third-party exposure in 2025. Black Kite's 2026 Ransomware Report documented an Oracle E-Business Suite campaign that exploited CVE-2025-61882 as a zero-day before any catalog could list it. Each new vulnerability of that kind joins the known exploited vulnerabilities list only after exploitation is confirmed, which is precisely the timing problem covered below.

How Is the CISA KEV Catalog Different From CVSS and EPSS?

CISA KEV records what has happened. CVSS scores how bad it could be. EPSS estimates how likely exploitation is. The three answer different questions, and using one where another belongs is the most common vulnerability prioritization mistake in security programs.

CVSS Measures Severity, Not Reality

CVSS rates the theoretical impact of a vulnerability if exploited, and those scores are published alongside CVE records in the National Vulnerability Database. A 9.8 describes what could happen, not whether anyone is trying. Severity is a cybersecurity judgment about impact, not an observation about behavior. Plenty of critical-rated flaws are never exploited, and plenty of medium-rated ones are exploited constantly, which is why severity alone is a poor queue.

EPSS Estimates Probability, KEV Confirms It

EPSS assigns a probability that a vulnerability will be exploited in the near future. It's predictive and useful for triage before anything happens, and it draws on exploitation threat intelligence rather than confirmed incidents. The KEV catalog is retrospective and binary. A vulnerability is on the list or it isn't, and if it is, prediction is no longer the question.

The Three Work as a Sequence

Mature vulnerability management uses all three in order. KEV catalog vulnerabilities go first because exploitation is confirmed. High-EPSS entries go next because exploitation is likely. CVSS then sorts what remains by potential damage. Skipping to CVSS is how security teams end up patching a theoretical critical while an actively exploited medium sits open. KEV is the only one of the three built on confirmed exploitation, which is why it anchors the sequence.

Who Is Required to Act on CISA KEV Entries?

Federal civilian executive branch agencies, known as FCEB agencies, are bound to remediate CISA KEV entries under Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk," issued in June 2026 to replace the earlier BOD 22-01 that established the catalog. Deadlines are no longer uniform across the catalog. They range from three days to sixty, set by whether the affected asset is publicly exposed, whether exploitation can be automated, whether it grants full system control, and whether active exploitation is confirmed. A KEV listing satisfies that last criterion, so a single CISA Known Exploited Vulnerability entry can still drive emergency patching across hundreds of federal systems.

Everyone else is strongly encouraged rather than required. CISA urges state, local, tribal, and territorial governments along with private sector organizations to fold the CISA KEV list into their vulnerability management and wider cybersecurity programs. In practice that encouragement has become a de facto standard. Contracting requirements, cyber insurance underwriting, and vendor security questionnaires increasingly reference KEV vulnerabilities directly, which pulls it into the private sector through commercial pressure rather than regulation. Any mature third party risk management program now treats KEV as a baseline expectation of its vendors, and organizations subject to government risk management requirements typically inherit federal remediation timelines through their contracts.

Why Does a Vendor's KEV Exposure Become Your Problem?

Because an actively exploited vulnerability on a vendor's internet-facing system is an open door into a network you depend on. Your own remediation efforts say nothing about the security posture of the vendors holding your sensitive information, processing your payments, or administering your systems. Most organizations run a disciplined internal security program and have no equivalent visibility one step outside it.

The exposure is widespread rather than exceptional. Black Kite's 2026 Wholesale and Retail Cyber Risk Report found 46% of mapped supply chain vendors carrying at least one KEV catalog vulnerability, with 165 unique KEV entries across a single mapped supply chain and 24 of them already used in ransomware campaigns. For organizations with hundreds of vendors, that is a standing security exposure nobody owns.
Attribution is thinner than most organizations assume. The 2026 Supply Chain Vulnerability Report found that of 245 CISA KEV additions in 2025, only 24 were explicitly attributed to known ransomware campaigns while 221 remained unattributed. Treating an unattributed KEV entry as lower priority is a bet that threat intelligence hasn't yet connected the exploitation to a named threat actor, which is a very different thing from nobody using it. Malicious actors don't wait for attribution.
Compromise doesn't close the exposure either. Among organizations that suffered ransomware attacks, 30.8% still carried known exploited vulnerabilities when rescanned afterward. A breached vendor is not a remediated vendor, and the security controls that were absent before an incident are frequently still absent after it. Organizations that assume a post-incident vendor has hardened itself are usually wrong.

How Should Security Teams Use the CISA KEV Catalog Across a Vendor Ecosystem?

By treating it as a matching problem rather than a reading problem. The known exploited vulnerabilities catalog is public and free. The difficulty was never knowing which vulnerabilities are exploited. It's knowing which of your vendors are running them, and on what. That gap is a security problem no amount of internal patching closes, and it's where vendor threat intelligence becomes operational rather than informational.

Three practices separate programs that use the KEV catalog well from programs that merely subscribe to it.

Map entries to vendors, not to products. A KEV entry naming a software package is only actionable once you know which vendors expose it and which specific assets are affected. That requires continuous monitoring of the vendor attack surface rather than a periodic review.
Set vendor remediation expectations against the federal clock. Borrowing BOD 26-04 deadlines gives contractual conversations a defensible security standard rather than an arbitrary one, and most organizations find vendors accept a government timeline more readily than a bespoke one.
Don't wait for the catalog. The 2026 Supply Chain Vulnerability Report found vulnerabilities being exploited an average of seven days before public disclosure, according to Mandiant's M-Trends 2026. A KEV addition is a confirmation, not an early warning, so patch management expectations for critical vendors have to run ahead of it.

That last point is where KEV monitoring meets vendor-level cyber risk intelligence. Black Kite assigns FocusTags® to the vendors affected by a high-impact vulnerability and pairs them with vulnerability intelligence that weighs EPSS, CVSS, KEV, LEV, and exploitability scores together to show how reachable each instance actually is, delivered per vendor as a Vulnerability Intelligence Brief (VIB).Historically, Black Kite applies a FocusTag® to 95.2% of OSINT-discoverable vulnerabilities before they are added to the CISA KEV catalog or within 24 hours of their addition which turns threat intelligence about a new vulnerability into a vendor list before the catalog confirms it.