[ Common Vulnerabilities and Exposures ]
KEV Catalog: how it works, why you need it, and how to integrate it
Summarize with AI
What is the Known Exploited Vulnerabilities (KEV) Catalog?
The Known Exploited Vulnerabilities (KEV) Catalog is a list maintained by the Cybersecurity and Infrastructure Security Agency (CISA). It contains software and hardware vulnerabilities for which there is evidence of exploitation in real-world attacks. Unlike vulnerability databases that list flaws based mainly on technical severity, KEV focuses on vulnerabilities that attackers have actually exploited.
Security teams can use the catalog to prioritize remediation. Each KEV entry identifies the affected product and vulnerability, provides a short description, and specifies a required remediation action and due date for U.S. federal civilian agencies. Organizations outside the federal government can also use KEV as an input to vulnerability management, helping them prioritize exploited vulnerabilities alongside factors such as asset exposure, business impact, and available mitigations.
You can access the official KEV Catalog here.
This is part of a series of articles about common vulnerabilities and exposures.
How does a vulnerability get added to the KEV Catalog?
CISA adds a vulnerability to the KEV Catalog when it meets specific criteria. The process is designed to distinguish vulnerabilities that pose a theoretical risk from those that attackers have actually exploited.
1. The vulnerability must have a CVE ID
The vulnerability must have an assigned Common Vulnerabilities and Exposures (CVE) identifier. A CVE ID provides a standardized reference that allows CISA, vendors, security tools, and vulnerability databases to refer to the same flaw consistently.
Having a CVE ID does not mean a vulnerability will automatically appear in KEV, because the ID only establishes the vulnerability’s identity. The vulnerability must also satisfy CISA’s other criteria for inclusion.
2. Evidence of active exploitation must exist
CISA requires reliable evidence that the vulnerability has been exploited in real-world conditions. A proof-of-concept exploit or demonstration that exploitation is technically possible is not enough by itself.
Evidence may come from incident response findings, security researchers, vendors, government partners, or other trusted sources. The key requirement is evidence showing that an attacker has used the vulnerability against a real system rather than only testing it in a controlled environment.
3. Clear remediation guidance must be available
CISA must be able to identify a clear action that organizations can take to address the vulnerability. This commonly means applying a vendor-provided patch or update.
When a patch is unavailable or insufficient, the required action may involve applying vendor mitigations or discontinuing use of the affected product. KEV entries specify the action organizations should take rather than simply identifying the vulnerability.
Related content: Read our article about vulnerability mitigation stages and strategies
4. How CISA verifies known exploitation
CISA evaluates available evidence before classifying a vulnerability as known to be exploited. It can use information from incident investigations, vendors, security researchers, government agencies, and trusted industry partners.
CISA does not need to publicly disclose every technical detail behind its determination, since some of the evidence may contain sensitive incident or victim information. As a result, a KEV entry indicates that CISA has determined exploitation occurred, even when the underlying evidence is not publicly available.
What information does the KEV Catalog include?
Each KEV entry contains standardized information that helps security teams identify the vulnerability, affected product, and required remediation:
- CVE ID: The unique CVE identifier assigned to the vulnerability.
- Vendor and product: The vendor and affected software, hardware, or service.
- Vulnerability name and description: A short name and summary of the vulnerability and its potential impact.
- Date added to the catalog: The date CISA added the vulnerability to KEV.
- Required remediation action: The action organizations should take, such as applying an update or vendor mitigation.
- Remediation due date: The deadline by which U.S. Federal Civilian Executive Branch agencies must complete the required action.
- Known use in ransomware campaigns: Indicates whether the vulnerability is known to have been used in ransomware attacks.
- CWEs: The Common Weakness Enumeration (CWE) categories that describe the type of weakness behind the vulnerability, such as improper input validation.
Below is the KEV Catalog entry for a well-known vulnerability, the Log4j remote code execution (RCE) flaw known as Log4Shell.
| Field | Value |
|---|---|
| CVE ID | CVE-2021-44228 |
| Vendor and product | Apache Log4j2 |
| Vulnerability name | Apache Log4j2 Remote Code Execution Vulnerability |
| Description | Apache Log4j2 contains a vulnerability where JNDI features do not protect against attacker-controlled JNDI-related endpoints, allowing for remote code execution. |
| Date added to the catalog | December 10, 2021 |
| Required remediation action | Apply updates or remove affected assets from agency networks. CISA’s recommended temporary mitigations are only acceptable until updates are available. |
| Remediation due date | December 24, 2021 |
| Known use in ransomware campaigns | Known |
| CWEs | CWE-20 (improper input validation), CWE-400 (uncontrolled resource consumption), CWE-502 (deserialization of untrusted data) |
KEV Catalog vs. CVE database vs. CVSS vs. EPSS
The CVE database provides standardized identifiers for publicly disclosed vulnerabilities. A CVE ID makes it possible to reference the same vulnerability across security tools, vendor advisories, and databases. However, a CVE ID does not indicate how severe a vulnerability is or whether attackers are exploiting it.
CVSS measures the technical severity of a vulnerability. Its score considers factors such as attack complexity, required privileges, user interaction, and potential impact. A high CVSS score can indicate serious technical consequences, but it does not mean the vulnerability is being exploited.
EPSS estimates the probability that a published vulnerability will be exploited in the next 30 days. It uses data-driven models to produce an exploitation probability. Unlike KEV, EPSS is predictive, so a high score indicates increased likelihood rather than confirmed exploitation.
The KEV Catalog identifies vulnerabilities for which CISA has evidence of real-world exploitation. This makes KEV an important prioritization signal because it shows that exploitation is no longer theoretical. Security teams can combine KEV with CVSS, EPSS, asset exposure, and business impact to decide which vulnerabilities require the fastest remediation.
All four signals describe the vulnerability and what attackers are doing with it somewhere in the world. None of them can tell you whether the vulnerability can be exploited on a specific asset in your environment, because that depends on conditions only your environment can answer, such as whether the vulnerable feature is enabled, the affected component is actually running, or the service can be reached at all.
| Signal | What it tells you | What it does not tell you |
|---|---|---|
| CVE | Provides a standardized identifier for a publicly disclosed vulnerability | How severe it is or whether it’s being exploited |
| CVSS | Measures the technical severity and potential impact of a vulnerability | Whether attackers are exploiting it |
| EPSS | Estimates the probability of exploitation in the next 30 days | Whether exploitation has been confirmed in real attacks |
| KEV | Confirms evidence of real-world exploitation | Full technical severity, business impact, or whether it can be exploited in your environment |
Why is the KEV Catalog important for vulnerability management?
The KEV Catalog is important for vulnerability management because it helps organizations identify vulnerabilities with confirmed real-world exploitation and prioritize remediation based on actual threat activity, not severity scores alone. By combining KEV data with asset exposure, business impact, and existing security controls, teams can focus limited resources on the vulnerabilities most likely to create immediate risk.
- Identifies actively exploited vulnerabilities: KEV includes vulnerabilities that CISA has evidence have been exploited in the wild, helping teams distinguish confirmed threats from theoretical risk.
- Improves prioritization beyond CVSS: KEV adds exploitation context that CVSS does not capture, helping teams prioritize vulnerabilities that present more immediate operational risk.
- Reduces reliance on severity alone: KEV provides an additional risk signal that can be combined with CVSS, EPSS, asset exposure, exploit availability, and business impact.
- Focuses remediation resources: Teams can map KEV entries to asset inventories and prioritize fixes for affected systems based on exposure, importance, and compensating controls.
- Provides actionable deadlines: KEV entries include required actions and due dates for federal agencies, which other organizations can use as a reference for internal remediation SLAs.
How to integrate the KEV Catalog into vulnerability management
Continuously match asset inventories against KEV entries
Regularly compare vulnerabilities associated with assets in the inventory against current KEV entries. CISA updates the catalog as new evidence of exploitation becomes available, so a vulnerability that was previously treated as lower priority may require faster action after it is added to KEV.
The matching process should run automatically whenever possible and cover servers, endpoints, network appliances, cloud workloads, applications, and other managed technology. Accurate software versions and asset inventories are important because incomplete data can prevent teams from identifying affected systems.
Teams should also trigger a new comparison whenever KEV data changes. This allows an organization to identify existing findings that have just gained known-exploited status without waiting for the next full vulnerability scan.
Add KEV status to vulnerability scanner findings
Add KEV status as a field, tag, or enrichment attribute in vulnerability scanner results. Analysts can then see whether a CVE is in KEV alongside its CVSS score, affected asset, software version, network exposure, and available remediation.
This enrichment also makes KEV data available to other parts of the vulnerability management process. Dashboards can show the number of open KEV findings, queries can isolate affected internet-facing systems, and reports can track remediation progress separately from other vulnerabilities.
Where scanners do not provide native KEV integration, teams can ingest CISA’s machine-readable catalog and match entries using CVE IDs. The enriched results can then be passed to ticketing, security orchestration, or risk management systems.
Related content: Learn more in our guide to vulnerability management tools
Automatically increase priority for KEV vulnerabilities
Configure prioritization rules so a KEV match increases the priority of a vulnerability finding. Confirmed exploitation provides stronger evidence of an immediate threat than technical severity alone, making KEV status a useful factor in risk-based prioritization.
However, KEV should be considered together with the context of the affected asset. Internet exposure, business criticality, privileges available to an attacker, existing security controls, and the potential impact of compromise can all change the urgency of remediation.
For example, the same KEV vulnerability may exist on an internet-facing production server and an isolated development system. Both require attention, but their exposure and potential business impact can justify different remediation timelines.
The best programs go one step further and check whether the vulnerability can be exploited on each asset at all. Every vulnerability needs certain conditions to be exploited, such as a specific configuration, an enabled module, a running process, or a reachable code path. A KEV entry tells you attackers have met those conditions somewhere, while checking your own environment tells you whether they’re met on your systems. When a key condition is missing, the finding still belongs on the remediation plan, but it shouldn’t compete for the same urgent slot as a KEV vulnerability that can be exploited today.
Create remediation SLAs based on exploitation status
Define remediation service-level agreements (SLAs) that explicitly account for known exploitation. KEV vulnerabilities can receive shorter remediation windows than comparable vulnerabilities for which no real-world exploitation has been confirmed.
Organizations can make these SLAs more specific by considering asset type and exposure. A KEV affecting an externally accessible system or critical business service might receive a shorter deadline than the same vulnerability on an isolated, lower-impact asset.
The SLA process should also define how exceptions are handled. When immediate patching is not possible because of compatibility, availability, or operational constraints, teams should document the reason, implement available compensating controls, and establish a date for permanent remediation.
Route KEV findings to the appropriate asset owners
Connect vulnerability data with asset ownership records so KEV findings are automatically assigned to the team responsible for remediation. Depending on the affected technology, this could be an endpoint, infrastructure, application, network, or cloud operations team.
Remediation tickets should contain enough information for the owner to act without repeating the initial investigation. Useful fields include the CVE ID, affected assets, vulnerable versions, KEV status, vendor advisory, required remediation, target completion date, and relevant mitigation instructions.
Escalation rules can address tickets that remain unassigned or exceed their remediation deadline. This prevents critical findings from remaining open simply because ownership information is missing or responsibilities are unclear.
Track remediation until closure
Track each KEV finding from detection through remediation and validation. Changing a ticket to resolved should not be sufficient evidence that the vulnerability has actually been removed from the affected asset.
After patching or mitigation, rescan the system or use another technical validation method to confirm that the vulnerable condition no longer exists. Validation is particularly important when fixes require configuration changes, service restarts, firmware upgrades, or several deployment steps.
Teams should also monitor overdue KEV findings, approved exceptions, compensating controls, and assets that repeatedly fail remediation. Metrics such as open KEV findings, average remediation time, SLA compliance, and reopened findings can help identify weaknesses in the vulnerability management process.
Related content: Read our article about CVE remediation in practice
Prioritizing and fixing exploitable vulnerabilities with Maze
KEV tells you which vulnerabilities attackers have exploited somewhere in the world, and Maze tells you which of them can actually be exploited in your environment. Maze is built from the ground up so its AI can gather the context it needs, reason through each vulnerability, and make decisions the way your best security engineer would. Maze Cloud investigates the vulnerabilities your existing scanners find in the workloads running in your cloud, and Maze Code uses AI to find the vulnerabilities in your code and open-source dependencies, so a KEV entry like Log4Shell gets the same investigation whether it sits in a container image or a library your application imports.
While working with security teams, Maze’s founders kept seeing the same problem. Those teams could see which vulnerabilities were on the KEV list and which scored high on CVSS, but their tools couldn’t gather the context needed to tell which ones could be exploited on their own systems, so engineers spent their time chasing findings that turned out not to apply. Maze was built to give every vulnerability the investigation those teams never had time to run, with AI that works out what context each finding needs and gathers it from your code, your build, and your cloud instead of applying static rules.
Key capabilities of Maze:
- Investigate every vulnerability in your backlog: Maze investigates every finding your scanners report, across cloud and code, instead of a sample or only the criticals, so the thousands of vulnerabilities sitting in your backlog each get a verdict with evidence rather than waiting for someone to have time.
- Unified findings from existing scanners: Maze Cloud pulls findings from the scanners you already run, whether that’s Wiz, Orca, or AWS Inspector, removes duplicates across them, and maps your cloud and containers to separate what is running from what isn’t, so every finding carries the context of your environment.
- Sensorless runtime context: Maze connects through a read-only cloud role and an API connection to your scanners, so it gathers runtime context, like which images are deployed and how each service is configured, without a sensor on your machines.
- Exploitability investigation: Maze’s AI researches the conditions each vulnerability needs in order to be exploited, whether that’s a particular configuration, a loaded module, or a reachable network path, and checks whether those conditions exist in your environment. Every verdict, including not exploitable, comes with the evidence and reasoning behind it.
- Prioritization beyond CVSS, EPSS, and KEV: Exploitable vulnerabilities are ranked by how likely they are to be exploited and how much harm they would do to the business. Known exploitation like a KEV listing raises the likelihood, while the investigation decides whether the vulnerability can be exploited on your systems in the first place.
- AI-SCA for your dependencies: Maze uses AI to trace the path from an entry point to the vulnerable function in each open-source dependency, however many hops deep, and then checks whether that code survives the build and runs exposed in your cloud. If you already run something like Dependabot, Maze investigates and deduplicates those findings too.
- Zero-day sweeps: When a new vulnerability is disclosed, Maze picks it up in near real time and checks every affected instance across your code and cloud with the same investigation it applies to every other finding.
- Fixes where your developers work: Maze traces each exploitable vulnerability to its root cause, writes a fix that matches your code, and sends it to the team that owns it, whether that’s a pull request, a Jira ticket, or a handoff to a coding agent like Claude Code or Cursor. When there’s no patch yet, Maze recommends a mitigation instead.
Learn more about how Maze investigates and fixes cloud vulnerabilities
