Writing

KEV vs CVE: which vulnerabilities to patch first

Published 24 September 2026

A CVE identifies a publicly disclosed vulnerability. A CISA KEV entry says there is reliable evidence attackers have exploited that CVE in the wild. KEV should raise patch urgency, but it does not replace the two checks that decide your actual risk: whether you run an affected version and whether an attacker can reach it.

KEV vs CVE in one table

SignalWhat it tells youWhat it does not tell you
CVEA shared identifier and record exist for a disclosed vulnerability.Whether it affects your estate, is easy to exploit, or is being exploited.
CVSSThe technical severity implied by a defined set of characteristics.Your business risk or the current likelihood of attack.
CISA KEVCISA has reliable evidence of active exploitation and has published a remediation action.Whether your particular asset is exposed, critical, or already compromised.

These are layers, not competing databases. A KEV item is still a CVE. The CVE gives teams and tools a common name; enrichment such as CVSS describes characteristics; KEV adds evidence that exploitation has crossed from possibility into observed attacker behaviour.

What is a CVE?

The Common Vulnerabilities and Exposures program assigns an identifier such as CVE-2026-12345 to one publicly disclosed vulnerability. A CVE record is deliberately compact: an identifier, a description, affected product information and references supplied through the CVE program's network of numbering authorities.

The National Vulnerability Database enriches those records with information such as product mappings, weakness categories and severity metrics. That enrichment is useful, but neither a CVE ID nor a red "critical" badge proves a vulnerable product is present in your environment. Inventory and version evidence still come first.

What is CISA KEV?

The Known Exploited Vulnerabilities catalog is CISA's living list of CVEs with reliable evidence of exploitation in the wild. Each row names the vendor and product, describes the vulnerability, gives a required action, and carries a date added and remediation due date. Some entries also note known ransomware use.

The due dates are mandatory for US Federal Civilian Executive Branch agencies under Binding Operational Directive 22-01. They are not a legal deadline for every private organization. The underlying signal still applies everywhere: attackers are not waiting for your annual patch cycle.

KEV means exploited, not universally affected. If the vulnerable feature is disabled, the product version is not affected, or the appliance was retired, the catalog entry does not create exposure. Prove applicability before opening an emergency change, but do that proof quickly.

Why CVSS alone creates the wrong patch queue

CVSS describes technical severity. NIST explicitly warns that CVSS is not a measure of risk. A 9.8 vulnerability in software you do not run is not your emergency; a lower-scored vulnerability actively exploited against an internet-facing gateway may be.

This is why a queue sorted only by descending base score becomes both large and strangely static. It treats exploitability as a property frozen on publication day and gives no special weight to evidence arriving later. KEV changes that ordering with a factual question: has someone used this vulnerability against real systems?

The shift is now visible in the infrastructure around CVEs. In April 2026, NIST said KEV entries would be among the first records selected for NVD enrichment as CVE volume outgrew the old process. In June, NVD added CISA's Stakeholder-Specific Vulnerability Categorization data alongside CVSS. The direction is operationally sensible: severity remains useful, but priority needs threat and context too.

A patch order that survives contact with production

  1. Match the asset and version. Confirm the vulnerable product, release and feature are actually present. Do not turn a fuzzy scanner match into an emergency outage.
  2. Check reachability. Internet-facing management planes, VPN gateways and email appliances deserve different treatment from a lab host behind two control layers.
  3. Overlay KEV. A matching KEV entry moves the item into the exploited-now lane. Read the required action and vendor advisory; "apply updates" and "discontinue use" are not equivalent instructions.
  4. Look for compromise, not just a missing patch. If the vulnerable system was exposed during active exploitation, patching closes the door but does not prove nobody already entered.
  5. Add business consequence. Identity systems, perimeter devices, hypervisors and backup infrastructure can turn one exploit into a much larger event.
  6. Record the exception. If remediation is delayed, name the compensating control, owner, expiry date and evidence that will close the exception.

That process belongs in a vulnerability-response playbook, because every finding branches on exposure and consequence. The distinction between that decision tree and a fixed patch procedure is the same one covered in runbook vs playbook vs MOP.

Automating the catalog without automating the decision

CISA publishes the catalog as JSON and CSV, so the useful automation is mechanical: fetch the current feed, join CVE IDs to the asset inventory, flag new matches, and preserve the catalog's date, required action and due date. The output should be a smaller review queue, not an unattended patch command. 

curl -fsS \
  https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json \
  -o known_exploited_vulnerabilities.json

jq -r '.vulnerabilities[] |
  [.cveID, .vendorProject, .product, .dateAdded, .dueDate] |
  @tsv' known_exploited_vulnerabilities.json

Keep the source timestamp and alert only on additions or changed matching rows. Reopening every KEV ticket on every poll creates the same fatigue as an anomaly detector that treats every deviation as an incident: the failure mode described in AI in networking.

The two mistakes to avoid

First, do not treat "not in KEV" as "safe." CISA needs reliable evidence before listing an item, and evidence can lag the first attack. Vendor advisories, observed scanning, asset exposure and your own telemetry still matter. KEV is a high-confidence escalation signal, not a complete universe of exploited flaws.

Second, do not treat every KEV match as permission to patch blindly. An emergency change that removes a critical service can produce the outcome it was meant to prevent. Validate the package, dependencies, backout path and service check. Urgency shortens the decision window; it does not erase change control.

Sources

Catalog fields and NVD process changes were checked on 24 September 2026.