# CISA Known Exploited Vulnerabilities (KEV) > CISA KEV is the U.S. government's catalog of CVEs with confirmed exploitation in the wild, each with a federal remediation due date under BOD 26-04. Also known as: CISA KEV, KEV catalog, KEV list, Known Exploited Vulnerabilities catalog Source: https://socket.dev/glossary/cisa-kev Last updated: 2026-10-20 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](https://socket.dev/blog/cve-volume-surges-past-48k-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](https://www.cisa.gov/known-exploited-vulnerabilities), "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. ## What is the CISA KEV catalog? The CISA KEV catalog is a public, machine-readable list that turns "exploited somewhere" into a federal patching obligation. [CISA](https://socket.dev/glossary/cybersecurity-and-infrastructure-security-agency-cisa) launched it on November 3, 2021, together with Binding Operational Directive (BOD) 22-01, with 287 entries. Each entry is a [CVE](https://socket.dev/glossary/common-vulnerabilities-and-exposures-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. ### Anatomy of a KEV entry This is the newest entry in catalog version 2026.10.16, with every field CISA published: ```json { "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](https://github.com/cisagov/kev-data/blob/main/known_exploited_vulnerabilities_schema.json). The table below is what each field means in practice. | Field | What it holds | What to watch for | | --- | --- | --- | | cveID | The CVE identifier, and the only key | No package name, ecosystem, or affected version range | | vendorProject, product | Free-text names chosen by CISA | Inconsistent for open source: "Npm package", or "Prettier" as the vendor of eslint-config-prettier | | dateAdded | The day CISA listed the CVE | Not the day exploitation started | | dueDate | The federal remediation deadline | The window changed on June 10, 2026 | | requiredAction | Free-text instruction | Written for patching, even on malware entries | | knownRansomwareCampaignUse | "Known" or "Unknown" | 361 of 1,748 entries are Known. Unknown means unconfirmed, not ruled out | | forensicTriage | "Yes" or "No" under BOD 26-04 | New in 2026. All 1,617 entries listed before June 10, 2026 say No | | cwes | CWE IDs | Can be empty: the TanStack entry has none | | notes | Semicolon-separated references | Vendor advisory and NVD links, sometimes a GHSA link | ## What does BOD 26-04 change about KEV deadlines? 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](https://github.com/cisagov/kev-data) 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](https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk) 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)](https://socket.dev/glossary/stakeholder-specific-vulnerability-categorization), and CISA's [Vulnrichment](https://github.com/cisagov/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: | Listed | Entries | 3 days | 14 days | 21 days | 181 to 184 days | Other | | --- | --- | --- | --- | --- | --- | --- | | Nov 3, 2021 to Jun 9, 2026 (BOD 22-01) | 1,617 | 31 | 254 | 1,025 | 257 | 50 | | Jun 10 to Oct 16, 2026 (BOD 26-04) | 131 | 108 | 23 | 0 | 0 | 0 | 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: ```bash $ 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. ```json { "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](https://www.fedramp.gov/notices/0014/). FedRAMP also requires cloud providers to remediate KEVs on the BOD 26-04 timelines, which pulls many commercial vendors into the same clock. ## How often is the CISA KEV catalog updated? 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](https://socket.dev/blog/cisa-brings-kev-data-to-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](https://socket.dev/blog/cisa-kills-off-rss-feeds-for-kevs-and-cyber-alerts), which left email as the only official push channel. For automation, poll the JSON and diff it yourself: ```bash $ 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. ## How do you check open source dependencies against KEV? 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](https://socket.dev/glossary/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: ```bash $ 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](https://socket.dev/changelog/alert-modal-now-displays-known-exploited-vulnerabilities-kev)), and security policy rules can match on a CISA KEV true or false field ([rule conditions](https://docs.socket.dev/docs/rule-conditions)). A rule can block a dependency whose CVE is in KEV and leave the rest of the CVE queue to triage. ## KEV, EPSS, CVSS, and reachability answer different questions 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. | Signal | Question it answers | Coverage | Updated | Main failure mode | | --- | --- | --- | --- | --- | | CVSS base score | How bad is this if exploited, in the abstract? | Most CVEs, when someone scores them | Rarely after publication | Severity is not likelihood | | EPSS | How likely is exploitation in the next 30 days? | Every published CVE | Daily | A probability from observed activity, not proof of exploitation | | CISA KEV | Has this CVE been exploited, with evidence CISA accepts? | 1,748 CVEs as of Oct 16, 2026 | Most weekdays | Conservative, lagging, CVE-only, product-centric | | Reachability | Does your code call the vulnerable function? | Your own dependency graph | Every scan | Says nothing about attacker interest. Analysis can be incomplete for dynamic code | Verdict: start with [reachability analysis](https://socket.dev/glossary/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](https://socket.dev/glossary/exploit-prediction-scoring-systems-epss), which FIRST defines as the probability "that a published CVE will be exploited in the wild in the next 30 days" ([FIRST](https://www.first.org/epss/)), to order the long tail. Use CVSS to break ties. That ordering is the core of [vulnerability prioritization](https://socket.dev/glossary/vulnerability-prioritization), and it only covers vulnerabilities. None of these four signals tells you whether a package release is itself hostile. ## Supply chain compromises reach KEV after the damage is done 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. > Days from the first malicious publish to KEV listing and to the KEV due date for six open source compromises 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: | Compromise | CVE | First malicious release | Added to KEV | Days to listing | KEV due date | Days to due date | | --- | --- | --- | --- | --- | --- | --- | | reviewdog/action-setup | CVE-2025-30154 | Mar 11, 2025 | Mar 24, 2025 | 13 | Apr 14, 2025 | 34 | | tj-actions/changed-files | CVE-2025-30066 | Mar 14, 2025 | Mar 18, 2025 | 4 | Apr 8, 2025 | 25 | | eslint-config-prettier | CVE-2025-54313 | Jul 18, 2025 | Jan 22, 2026 | 188 | Feb 12, 2026 | 209 | | Trivy and trivy-action | CVE-2026-33634 | Mar 19, 2026 | Mar 26, 2026 | 7 | Apr 9, 2026 | 21 | | TanStack | CVE-2026-45321 | May 11, 2026 | May 27, 2026 | 16 | Jun 10, 2026 | 30 | | Nx Console | CVE-2026-48027 | May 18, 2026 | May 27, 2026 | 9 | Jun 10, 2026 | 23 | The median gap from first malicious release to listing is 11 days. Malware does its work in minutes. The [tj-actions/changed-files compromise](https://socket.dev/blog/github-actions-supply-chain-attack-puts-thousands-of-projects-at-risk) 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](https://osv.dev/vulnerability/GHSA-qmg3-hpqr-gqvc). 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](https://socket.dev/blog/npm-phishing-campaign-leads-to-prettier-tooling-packages-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: ```bash $ 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](https://socket.dev/supply-chain-attacks/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](https://socket.dev/blog/tanstack-npm-packages-compromised-mini-shai-hulud-supply-chain-attack), part of the [Mini Shai-Hulud](https://socket.dev/supply-chain-attacks/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](https://nx.dev/blog/nx-console-v18-95-0-postmortem). The [Nx Console compromise](https://socket.dev/blog/npm-invalidates-tokens-mini-shai-hulud) 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. ## What the CISA KEV catalog does not tell you 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](https://socket.dev/blog/nist-officially-stops-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](https://socket.dev/glossary/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](https://socket.dev/blog/how-to-use-socket-to-find-out-if-you-were-affected-by-the-backdoored-xz-package), CVE-2024-3094, is not in the catalog. Neither is the [axios compromise](https://socket.dev/blog/axios-npm-package-compromised) 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)](https://socket.dev/glossary/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](https://socket.dev/blog/federal-audit-finds-nist-wasted-funds-with-no-plan-to-clear-nvd-backlog). 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.