CISA Known Exploited Vulnerabilities (KEV)

CISA KEV, the Known Exploited Vulnerabilities catalog (often called the KEV list), is the U.S. Cybersecurity and Infrastructure Security Agency's list of CVEs with reliable evidence of exploitation in the wild. Each entry carries a required action and a due date that federal civilian agencies must meet under Binding Operational Directive 26-04. Everyone else uses it as a prioritization signal.

As of catalog version 2026.10.16, released October 16, 2026, the KEV catalog lists 1,748 CVEs. That is a deliberately small set. The catalog holds 189 CVE IDs from 2025, against 48,185 CVEs published in 2025, under 0.4%. CISA adds a CVE only when three conditions hold: it has a CVE ID, there is reliable evidence of exploitation in the wild, and there is a clear remediation action such as a vendor update. Scanning, security research, and proof-of-concept code do not count as exploitation. In CISA's words, "the public availability of a PoC does not automatically indicate the vulnerability has been or will be exploited."

Our position: the KEV catalog is the best free signal that a published CVE needs attention now, and the wrong tool for open source supply chain attacks. It keys on CVE IDs and measures remediation against a due date, which fits a flawed VPN appliance and does not fit a malicious package. We found six compromised open source packages, GitHub Actions, and developer tools in the catalog. The median one was listed 11 days after its first malicious release, long after its payload had run in CI and on laptops. Use KEV to rank vulnerabilities your code can reach. Use install-time malware detection for the attacks KEV was never built to see.

The CISA KEV catalog is a public, machine-readable list that turns "exploited somewhere" into a federal patching obligation. CISA launched it on November 3, 2021, together with Binding Operational Directive (BOD) 22-01, with 287 entries. Each entry is a CVE ID plus what a patch team needs: vendor, product, a one-line description, a required action, and a due date. The catalog does not include the exploitation evidence itself. The notes field links the vendor advisory and the NVD record instead.

The directive binds only Federal Civilian Executive Branch agencies. Everyone else, including most security tools, reads the KEV catalog as an input to prioritization. CISA publishes it under a CC0 public domain license, so anyone can mirror, join, and redistribute it.

The KEV catalog is weighted heavily toward commercial products. Microsoft accounts for 390 entries, Cisco for 101, and Apple for 95. Open source libraries are rare. Log4Shell (CVE-2021-44228) is the best-known one. The systeminformation package for Node.js (CVE-2021-21315) is listed under the vendor name "Npm package", which tells you how little the schema knows about package ecosystems.

This is the newest entry in catalog version 2026.10.16, with every field CISA published:

{
  "cveID": "CVE-2026-102764",
  "vendorProject": "BeyondTrust",
  "product": "Remote Support",
  "vulnerabilityName": "BeyondTrust Remote Support Authentication Bypass by Spoofing Vulnerability",
  "dateAdded": "2026-10-16",
  "shortDescription": "BeyondTrust Remote Support contains an authentication bypass by spoofing vulnerability that could allow a remote attacker to perform file operations on the appliance.",
  "requiredAction": "Apply mitigations in accordance with vendor instructions, ensuring compliance with CISA’s BOD 26-04 Prioritizing Security Updates Based on Risk (see URL in Notes) guidance and CISA’s “Forensics Triage Requirements” (see URL in Notes). Follow applicable BOD 26-04 guidance for cloud services or discontinue use of the product if mitigations are unavailable. Stakeholders are responsible for evaluating each asset's internet exposure and ensuring adherence to BOD 26-04 patching guidelines.",
  "dueDate": "2026-10-19",
  "knownRansomwareCampaignUse": "Unknown",
  "forensicTriage": "Yes",
  "notes": "https://www.beyondtrust.com/trust-center/security-advisories/bt26-05 ; ; BOD 26-04: https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk ; Forensics Triage Requirements: https://www.cisa.gov/news-events/directives/bod-26-04-implementation-guidance-prioritizing-security-updates-based-risk ; https://nvd.nist.gov/vuln/detail/CVE-2026-102764",
  "cwes": ["CWE-290"]
}

Every field is a string or a list of strings, and only eight are required by the published JSON schema. The table below is what each field means in practice.

BOD 26-04 replaced BOD 22-01 as the authority behind the KEV catalog on June 10, 2026, and replaced fixed patch windows with risk-based ones. The kev-data README now says CISA's requirements for adding entries rely "on the authority of BOD 26-04." Under BOD 22-01, the rule was two weeks for CVEs assigned in 2021 or later and six months for older ones. In practice CISA settled on three weeks: 1,025 of the catalog's 1,748 due dates fall exactly 21 days after listing.

BOD 26-04 scores each vulnerability on four yes-or-no questions. Is the asset reachable from the public internet? Is the CVE in KEV? Can exploitation be automated? Does it give an attacker total control of the system? The last three are decision points from Stakeholder-Specific Vulnerability Categorization (SSVC), and CISA's Vulnrichment program publishes them per CVE, including for all 131 KEV entries added since the directive. Exposure is the one answer only the asset owner has. The worst combinations get three days. Vulnerabilities that meet none of the four criteria can wait for the next scheduled upgrade.

The shift is visible in the data. We grouped every KEV entry by the gap between dateAdded and dueDate:

Every entry added since the directive took effect has a 3-day or 14-day deadline. 87 of those 131 entries also carry forensicTriage: Yes, and all 87 are 3-day entries. Forensic triage means checking whether the asset was compromised before the patch landed, because patching closes the hole and does nothing about an attacker already inside. You can reproduce the split from the catalog file:

$ jq -r '
  def days: (.dueDate   | strptime("%Y-%m-%d") | mktime)
          - (.dateAdded | strptime("%Y-%m-%d") | mktime) | . / 86400;
  [.vulnerabilities[] | select(.dateAdded >= "2026-06-10")
   | {d: days, t: .forensicTriage}]
  | group_by([.d, .t]) | .[]
  | "\(.[0].d) days  forensicTriage=\(.[0].t)  \(length)"' known_exploited_vulnerabilities.json
3 days  forensicTriage=No  21
3 days  forensicTriage=Yes  87
14 days  forensicTriage=No  23

The BeyondTrust entry above shows the inputs. Its Vulnrichment record, published 34 minutes after that catalog release, rates it as actively exploited, automatable, and total in technical impact. CISA gave it a 3-day deadline and required forensic triage.

{
  "type": "ssvc",
  "content": {
    "id": "CVE-2026-102764",
    "role": "CISA Coordinator",
    "options": [
      { "Exploitation": "active" },
      { "Automatable": "yes" },
      { "Technical Impact": "total" }
    ],
    "version": "2.0.3",
    "timestamp": "2026-10-16T17:50:04.760178Z"
  }
}

Do not try to recompute KEV deadlines from those values. We joined all 131 post-directive entries to their Vulnrichment records. 14 entries rated Technical Impact "total" still received 14 days and no forensic triage. Exposure assumptions or later rescoring could explain the difference, and the catalog does not say which. Treat dueDate and forensicTriage as published decisions, not as a formula.

The deadlines bind agencies on a schedule. Agency policies had to support the new model by August 7, 2026, and agencies must remediate on BOD 26-04 timelines starting December 7, 2026, according to FedRAMP's notice on the directive. FedRAMP also requires cloud providers to remediate KEVs on the BOD 26-04 timelines, which pulls many commercial vendors into the same clock.

The CISA KEV catalog has no fixed update schedule. CISA adds entries whenever it confirms exploitation, almost always on weekdays. In 2026 through October 16, CISA added 264 entries on 121 separate days, a median of 2 entries per update. 41 of the year's first 42 weeks had at least one addition, and only two updates landed on a weekend. The largest single-day batch in 2026 was 8 entries, on April 20. In 2025, CISA added 245 entries on 116 days.

CISA publishes the catalog as JSON and CSV at cisa.gov/kev, with a JSON schema. Since January 2025, the official kev-data mirror on GitHub has carried the same files plus a commit for every change. Its README says the two sources are "synchronized within minutes of each other." CISA retired its RSS feeds for KEV updates on May 12, 2025, which left email as the only official push channel. For automation, poll the JSON and diff it yourself:

$ curl -sS -o kev-new.json \
    https://raw.githubusercontent.com/cisagov/kev-data/main/known_exploited_vulnerabilities.json
$ jq -r '[.catalogVersion, .count] | @tsv' kev-new.json
2026.10.16	1748

# Diff whole entries, not just IDs: CISA also updates entries after listing
$ diff <(jq -c '.vulnerabilities[]' kev-old.json | sort) \
       <(jq -c '.vulnerabilities[]' kev-new.json | sort)

Diffing only cveID values misses edits to existing entries. The kev-data README describes updates as "new or updated KEV entries," so an entry you already ingested can change later. The catalogVersion string is a date, so a version check tells you whether to fetch, not what changed.

Checking open source dependencies against the CISA KEV catalog requires a join through an advisory database, because KEV identifies vulnerabilities only by CVE ID. A lockfile gives you package names and versions. KEV gives you CVE IDs and free-text product names. The bridge is an advisory record, from the GitHub Advisory Database or OSV, that maps a package version range to a CVE alias.

Here is that join for eslint-config-prettier 10.1.6, one of the versions published with malware in July 2025. npm's own advisory endpoint answers in GHSA identifiers and never mentions CVE or KEV:

$ curl -sS -X POST -H 'content-type: application/json' \
    https://registry.npmjs.org/-/npm/v1/security/advisories/bulk \
    -d '{"eslint-config-prettier":["10.1.6"]}' \
  | jq -c '.["eslint-config-prettier"][] | {url, title, vulnerable_versions}'
{"url":"https://github.com/advisories/GHSA-f29h-pxvx-f335","title":"eslint-config-prettier, eslint-plugin-prettier, synckit, @pkgr/core, napi-postinstall have embedded malicious code","vulnerable_versions":">=10.1.6 <=10.1.7"}
{"url":"https://github.com/advisories/GHSA-r568-chxc-crfm","title":"Malicious code in eslint-config-prettier (npm)","vulnerable_versions":"=10.1.6"}

# GHSA-f29h-pxvx-f335 lists CVE-2025-54313 as its alias. Now look that up in KEV:
$ jq -c '.vulnerabilities[] | select(.cveID == "CVE-2025-54313")
         | {cveID, dateAdded, dueDate, cwes}' known_exploited_vulnerabilities.json
{"cveID":"CVE-2025-54313","dateAdded":"2026-01-22","dueDate":"2026-02-12","cwes":["CWE-506"]}

Two advisories describe the same malicious version, and only one carries the CVE alias that KEV keys on. A scanner that deduplicates to the other record loses the KEV flag. The same pattern shows up for TanStack: the KEV entry's notes point at GHSA-g7cv-rxg3-hmpx, while npm also returns a second malware advisory for the same version. Alias handling, not the KEV file, decides whether your tool reports KEV status correctly.

Socket performs this join on its CVE alerts. The Socket dashboard shows a "Known Exploits" section with CISA KEV data on affected alerts (changelog), and security policy rules can match on a CISA KEV true or false field (rule conditions). A rule can block a dependency whose CVE is in KEV and leave the rest of the CVE queue to triage.

The CISA KEV catalog is one of four signals teams use to rank CVEs, and each answers a different question. They do not compete so much as fail in different ways.

Verdict: start with reachability analysis to discard CVEs your code never calls. Treat KEV as a hard override on what remains: reachable and in KEV means fix now. Use EPSS, which FIRST defines as the probability "that a published CVE will be exploited in the wild in the next 30 days" (FIRST), to order the long tail. Use CVSS to break ties. That ordering is the core of vulnerability prioritization, and it only covers vulnerabilities. None of these four signals tells you whether a package release is itself hostile.

The CISA KEV catalog lists six compromises of open source packages, GitHub Actions, or developer tools, and each one was listed after its payload had already run. We found them by filtering for CWE-506 (embedded malicious code) and by reading entry text, since the TanStack entry has no CWE at all. A CWE-506 filter alone returns eight entries, three of them proprietary software, and misses TanStack.

The figure plots, for each compromise, the days from the first malicious release to KEV listing and to the KEV due date. The same data:

The median gap from first malicious release to listing is 11 days. Malware does its work in minutes. The tj-actions/changed-files compromise printed CI secrets into the logs of every workflow that ran it, starting March 14, 2025. The reviewdog/action-setup compromise ran for under two hours, between 18:42 and 20:31 UTC on March 11, 2025, according to its advisory. By the time either reached KEV, the useful response was rotating every exposed credential, not applying an update before a due date.

The eslint-config-prettier compromise is the outlier. A phished maintainer token was used to publish four malicious versions. The npm registry still records when they were published, even though the versions themselves are gone:

$ npm view eslint-config-prettier time --json \
  | jq 'with_entries(select(.key | test("^(8\\.10\\.1|9\\.1\\.1|10\\.1\\.[5-8])$")))'
{
  "10.1.5": "2025-05-09T04:15:08.605Z",
  "9.1.1": "2025-07-18T15:51:53.590Z",
  "8.10.1": "2025-07-18T16:09:40.069Z",
  "10.1.6": "2025-07-18T16:12:58.175Z",
  "10.1.7": "2025-07-18T16:13:43.007Z",
  "10.1.8": "2025-07-18T18:40:08.244Z"
}

$ npm view eslint-config-prettier versions --json | jq -c 'map(select(test("^10\\.1\\.")))'
["10.1.0","10.1.1","10.1.2","10.1.3","10.1.4","10.1.5","10.1.8"]

All four malicious versions went out within 22 minutes on July 18, 2025. The GitHub advisory with the CVE alias was published the next day. CISA added CVE-2025-54313 to the KEV catalog on January 22, 2026, 188 days after the first malicious publish. The advisory existed for six months before KEV listed it.

The 2026 cases moved faster but followed the same pattern. The Trivy GitHub Actions compromise force-pushed 75 of 76 version tags of aquasecurity/trivy-action on March 19, 2026, and reached KEV a week later. In the TanStack compromise, part of the Mini Shai-Hulud campaign, Socket flagged all 84 malicious package artifacts within six minutes of publication. KEV listed the CVE 16 days later. Those versions were authenticated through TanStack's own OIDC trusted publisher binding, which is why the KEV entry describes malware published "under a trusted identity." Valid provenance said nothing about intent. Credentials stolen from an Nx contributor in that attack were then used to publish a malicious Nx Console extension on May 18, 2026, which was live for under 40 minutes according to Nx's postmortem. The Nx Console compromise reached KEV nine days later.

All six entries were added before BOD 26-04, so all six carry forensicTriage: No and a requiredAction to "apply mitigations per vendor instructions." For a malicious package, triage and credential rotation are most of the response. Whether the next malware entry gets forensic triage under BOD 26-04 depends on how CISA scores technical impact for a credential stealer, and no post-directive malware entry exists yet to show that.

The CISA KEV catalog's biggest limitation is that absence proves nothing. CISA requires evidence it can rely on, so the catalog trails the real set of exploited CVEs. When NIST narrowed NVD enrichment in April 2026, our coverage of NIST's decision to stop enriching most CVEs cited 1,559 CVEs in KEV against more than 7,000 with known exploitation in one commercial vulnerability database. A CVE missing from KEV may simply not have met CISA's evidence bar yet.

Most supply chain attacks can never enter the catalog at all. A typosquat or a purpose-built malicious package rarely gets a CVE, and without a CVE ID it fails KEV's first criterion. Even high-profile compromises with wide reach are missing. The xz backdoor, CVE-2024-3094, is not in the catalog. Neither is the axios compromise of March 31, 2026, in which two axios releases pulled in a malicious dependency.

KEV listing does not guarantee usable metadata either. Since April 2026, the National Vulnerability Database (NVD) enriches KEV CVEs first and leaves most others "Not Scheduled." A federal audit still found that NVD enrichment was late for 34% of 226 KEV CVEs added between February 2024 and December 2025, as we reported in our coverage of the Commerce OIG audit. A KEV entry can arrive before the CPE and CVSS data that scanners match on.

Finally, dateAdded is when CISA listed the CVE, not when exploitation began, and the deadlines encode one federal operator's risk tolerance. The catalog cannot know whether your instance faces the internet. Your own exposure, compensating controls, and reachability still decide whether a KEV entry is a 3-day problem for you or not a problem at all.

The open problem is that the CISA KEV catalog was built to answer a question about vulnerabilities: has someone been attacked through this flaw? For a malicious release, the answer is yes the moment anyone installs it, and the useful response is to block the install and rotate whatever the payload could reach. The catalog's machinery of CVE IDs, required actions, and due dates turns that into a remediation deadline measured in days or weeks. There is still no exploited-malware catalog keyed on package URLs and published in minutes, so for supply chain attacks KEV remains a record of what was already stolen.