Pulp sci-fi illustration of a chrome wrench and glowing patch plate bolted onto a cracked circuit vault under a red work lamp

What a CISA KEV listing means and how to use it

Home » Training & Awareness » What a CISA KEV listing means and how to use it

A CVE lands on CISA’s Known Exploited Vulnerabilities Catalog and the room jumps. Some teams patch everything by the federal due date. Others shrug because they are not a US agency. Both miss the point. A KEV listing is evidence that someone is already using the flaw in the wild. Here is what that label means, what it does not mean, and how to act on it without burning the weekend on the wrong systems.

What the KEV Catalog is

The Known Exploited Vulnerabilities Catalog (opens in a new tab) is CISA’s public list of CVEs with confirmed exploitation. Each row carries the CVE identifier, vendor and product, a short vulnerability name, the date added, a required action, a due date for federal civilian agencies, and notes. CISA adds entries when it has reliable evidence of active use, not when a proof-of-concept appears on GitHub or a CVSS score looks scary.

CISA will not list a CVE unless three criteria are met: an assigned CVE ID; reliable evidence of active exploitation in the wild; and clear remediation guidance (typically a vendor update or documented mitigation). “Exploitable in theory” or a public proof-of-concept alone is not enough.

That distinction matters. Thousands of CVEs publish every year. Only a fraction ever see real attacks. The KEV is CISA’s answer to prioritisation: if it is on this list, treat exploitation as a fact, not a forecast. Our Alert Tracker flags KEV status alongside EPSS so you can see that signal next to the stories we cover.

What a listing does and does not mean

  • It means exploitation has been observed. Someone, somewhere, used the vulnerability against a real target. That can be mass scanning, a ransomware affiliate, or a quieter intrusion set.
  • Check the ransomware field. Catalogue rows carry knownRansomwareCampaignUse as Known or Unknown. Known means CISA associates the CVE with ransomware campaigns; Unknown is not a clean bill of health — treat exploitation as confirmed either way, and let the field sharpen urgency and reporting.
  • It does not mean every internet host is on fire. Exposure, authentication requirements, and how widely the product is deployed still decide your urgency.
  • It does not replace asset context. A KEV on software you do not run is noise. A KEV on an internet-facing appliance you do run is a page-the-on-call event.
  • Federal due dates are for US FCEB agencies. Binding Operational Directive timelines bind those agencies. For everyone else they are a useful benchmark, not a legal clock.

Since June 2026, BOD 26-04 (opens in a new tab) has replaced the older flat “patch every KEV” rule with a risk table. Many new catalogue entries also carry a forensic-triage flag. We unpacked that change in BOD 26-04 and the KEV: what forensic triage means. The short version: for the highest-risk cell, agencies get three calendar days and must triage the asset for compromise before they declare the job done.

How to use a KEV listing in practice

Treat every new KEV as a mini-incident until you prove you are not exposed.

  • Map it to assets in the first hour. Search CMDB, EDR, vulnerability scanners and cloud inventories for the named product and version range. Prefer authenticated discovery over banner grabs.
  • Decide internet exposure next. Public-facing and VPN/edge appliances jump the queue. Internal-only builds still matter if the CVE enables lateral movement after phishing.
  • Preserve before you patch when triage is flagged. If the KEV row or BOD 26-04 table calls for forensic triage, collect volatile evidence first. Patching through an active intrusion can wipe the only proof you had.
  • Patch, or fence if you cannot. Apply the vendor fix on the due-date mindset even when you are not federal. If no patch exists, follow the fence-and-monitor pattern in When there’s no patch: how to find and fence unfixed flaws.
  • Hunt with the vendor and CISA notes. Recent Alerts such as PHP2Shell and Oracle EBS CVE-2026-101767 show the pattern: patch, then look for the webshell, the odd child process, or the reconnaissance that arrived first.

How KEV sits next to CVSS and EPSS

CVSS answers “how bad is this flaw in the abstract?”. EPSS answers “how likely is exploitation in the next 30 days?”. KEV answers “has exploitation already happened?”. A Critical CVSS with a tiny EPSS and no KEV entry can wait behind a High CVSS that is already on the catalogue. Use all three: KEV for confirmed exploitation, EPSS for near-term probability, CVSS for impact once an attacker is in. We walk through the scoring side in How to read a CVSS score (and EPSS) without panicking.

A simple operating rhythm

  • Subscribe to CISA’s KEV feed or CSV and to vendor advisories for your top 20 internet-facing products.
  • Review new KEVs daily in change advisory or the vulnerability board; do not leave them in a weekly backlog.
  • Record decisions. “Not in estate”, “patched”, “fenced” and “triaged clean” should be auditable answers, not Slack folklore.
  • Retire the myth that KEV is only for Americans. Ransomware crews and initial-access brokers do not check your jurisdiction before they scan.

A KEV listing is a smoke alarm, not a full fire report. Hear it, check the room, preserve what matters, then put the fire out. That is how the catalogue earns its keep.

Sources

Follow Cyber-Threat.net RSSFeedly (opens in a new tab)X (opens in a new tab)Bluesky (opens in a new tab)LinkedIn (opens in a new tab)