CISA KEV catalog

What the catalog is and what gets listed

The KEV catalog is kept by the US Cybersecurity and Infrastructure Security Agency (CISA). CISA describes it as an authoritative source of vulnerabilities exploited in the wild and tells organizations to use it as an input to their vulnerability management prioritization. According to the BOD 26-04 implementation guidance, a CVE is added when it:

• has an assigned CVE ID;
• has reliable evidence of active exploitation in the wild;
• has clear remediation or mitigation available;
• carries significant risk to US government information systems.

Each entry records the vendor and product, a name and short description, the date added, a required action, a due date, whether the flaw is known to be used in ransomware campaigns, and whether forensic triage is required. In the 2026.10.21 release the feed held 1,754 entries, 361 of them flagged as used in ransomware campaigns.

Downloading and filtering the feed

CISA publishes the catalog as JSON, as CSV, and with a JSON schema. The JSON has a header (title, catalogVersion, dateReleased, count) and a vulnerabilities array with these fields: cveID, vendorProject, product, vulnerabilityName, dateAdded, shortDescription, requiredAction, dueDate, knownRansomwareCampaignUse, forensicTriage, notes and cwes.

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

# one CVE
jq --arg id CVE-YYYY-NNNN '.vulnerabilities[] | select(.cveID==$id)' kev.json

# added in the last 7 days (GNU date)
jq -r --arg since "$(date -d '7 days ago' +%F)" '.vulnerabilities[]
  | select(.dateAdded >= $since) | [.cveID,.vendorProject,.product,.dueDate] | @tsv' kev.json

# products you run
jq -r '.vulnerabilities[] | select((.vendorProject+" "+.product) | test("nginx|openssh|docker";"i"))
  | [.cveID,.dateAdded,.dueDate,.product] | @tsv' kev.json

Vendor and product names are not normalized, so match loosely and then confirm against what is installed. One download a day is plenty.

Who the due dates bind, and what KEV does not tell you

The original directive, BOD 22-01, was issued on 3 November 2021 for federal civilian agencies. It required remediation within two weeks, or six months for CVEs assigned before 2021. It has since been revoked and superseded by BOD 26-04 (10 June 2026), where the due date depends on risk: CISA derives dueDate from whether the asset is publicly exposed, and recent entries in the feed carry 3 or 14 days.

These directives bind US federal civilian systems only. For everyone else a due date is guidance, though CISA tells all organizations to use the catalog for prioritization.

Limits to remember:

• A CVE that is not listed is not proven safe: the catalog only holds entries that met CISA's criteria.
• Listing says nothing about whether you run the affected product or version.
• It is not a patch tracker: confirm the fix against your own package.

Checking KEV as part of your patch routine

Add one step to the weekly patch review: pull the feed, list entries added since the last check, and match them against everything you run, including packages, containers, control panels and appliances. A match belongs on the emergency path, not the routine backlog, because exploitation is already confirmed. Install the fix or apply the vendor mitigation on a faster track than your normal cycle, and use CVSS to order the rest.

Treat the forensicTriage field as a hint. When it is Yes, CISA expects federal agencies to check the asset for compromise as well as patch it. On an internet-facing service of your own, do the same, and follow the breach response guide if anything looks off.

A worked example is in the KEV priority guide, the October additions that touch Linux servers are in the October 2026 KEV review, and the surrounding process is in the server patch management guide.

Related terms: Patch management, CVSS, N-day exploit, Zero-day exploit, Incident response.