Security teams tend to read the Known Exploited Vulnerabilities catalogue as a feed of new trouble. The 2026 data says something less comfortable. A sizeable share of what CISA adds is old, in some cases very old, and it is added because someone is still exploiting it successfully.
We counted entries in the CISA KEV JSON feed (catalogVersion 2026.11.04, released 4 November and pulled by us on 5 November). Since 1 January, CISA has added 284 vulnerabilities. Of those, 196 have 2026 CVE IDs and 38 have 2025 IDs. The remaining 50, or 18%, carry IDs from 2024 or earlier. Ten of those date from 2008 to 2012. Five date from 2015 or 2016.
Two caveats before we go further. The year in a CVE ID is when the identifier was assigned, not when the bug was disclosed or patched, so it is a rough proxy for age. A 2024-numbered CVE can describe a bug first found later, and a 2008 CVE can reach KEV for reasons unrelated to age. And KEV records that exploitation has been observed. It says nothing about how widespread the exploitation is.
What the old entries look like
The legacy group is not a handful of curiosities. Microsoft accounts for 12 of the 50, followed by Apple (4), Linux (3), and pairs from Red Hat, Cisco, Adobe, SimpleHelp and GitLab.
One batch makes the point. On 8 October CISA added CVE-2015-3306 (ProFTPD), CVE-2016-3081 (Apache Struts), CVE-2015-5477 (ISC BIND), CVE-2021-3199 (ONLYOFFICE Docs) and CVE-2023-22894 (Strapi) on a single day, each with a three-day deadline. These are not obscure products. They are the kind of software that gets installed once, works, and is never looked at again.
The latest example landed this week. CVE-2024-27834, an Apple pointer authentication bypass that needs an attacker with arbitrary read and write capability, was added on 4 November. NVD says Apple fixed it in May 2024. Sekoia’s 4 November report on a watering-hole campaign attributed with moderate to high confidence to APT29 lists it in an iOS 16.7 exploit chain. NVD’s references for the CVE include Sekoia’s post, and CISA added the CVE on the same day the report was published; the KEV entry itself does not mention Sekoia. We covered the campaign in our flash briefing. Sekoia’s own summary is that none of the chains use zero-days and that a fully updated device is not affected. The connection between Sekoia’s report and the KEV addition is plausible but not stated by CISA, and we do not claim it. Its KEV deadline is 14 days (due 18 November).
Why this matters more than the headline zero-days
Our assessment: a zero-day is a vendor problem until a patch ships, and a legacy n-day is an owner problem forever. The 50 older entries are, by CVE-ID year, bugs where a fix existed, often for years, and exploitation still pays. That points at the unglamorous parts of security: knowing what you run, owning it, and being able to change it.
Three patterns show up in the list.
Software nobody owns (our assessment). File servers, FTP daemons, internal document tools and CMS plug-ins sit outside the patch cycle because no team treats them as products. They are found by attackers’ scanners before they are found by asset inventories.
Devices that cannot update (our assessment). Sekoia’s chain only affects iPhones still below the fixed release (NVD lists iOS 16.7.8 and 17.5 as fixes). Our inference, which no source here confirms, is that fleets of phones, tablets, kiosks and industrial HMIs have a long tail of devices that can no longer take current patches. For these, “patch it” is not an available action.
Deadlines that gave age no extra time. Among the 50 legacy entries, 12 carry a three-day deadline, 22 carry 14 days, 15 carry 21 days and 1 carries two days. Pooled over the year, legacy entries are less likely to get three days (12 of 50) than all additions (151 of 284), but that comparison is confounded by timing. Before June, none of the 33 legacy entries had a three-day deadline and only 26 of 123 additions overall did. From June on, 12 of 17 legacy entries (71%) got three days, against 125 of 161 additions overall (78%). So since June, old bugs have been given close to the same short deadlines as new ones. Our inference is that CISA is not treating old as low priority; the feed does not state its intent. In the feed, 151 entries cite BOD 26-04 in their required action, the earliest added on 11 June 2026. We could not open the BOD page itself, so we say nothing about what it requires beyond that text. For context, see our earlier commentary on BOD 26-04.
What leaders should change
None of this is exotic, but it is often skipped.
- Match KEV by CVE, not by date. Run your scanner output against the whole catalogue every time it updates. A filter such as “added in the last 30 days” hides a 2015 bug that was added yesterday.
- Track end-of-life as a risk item. Software and devices that cannot take patches should have a named owner, a retirement date and compensating controls, such as network isolation or removing browsing from sensitive roles.
- Treat third-party scripts as part of your attack surface. The Sekoia case reaches visitors through a compromised analytics script. Organisations that embed third-party JavaScript inherit its risk, and so do their visitors.
- Ask a different board question. Instead of “how many criticals are open”, ask “what is the oldest KEV-listed vulnerability we are exposed to, and who owns it”.
What the data cannot tell us
The 18% figure rests on a proxy and a single snapshot. We have not tested whether the share is rising or falling across years, and one year of additions is not a trend. KEV is also a catalogue of confirmed exploitation reports that meet CISA’s criteria, so it undercounts legacy exploitation that nobody reported. Ransomware use is listed as “Unknown” for the October batch; that tells us nothing either way.
Still, the direction of the lesson is clear enough. The cheapest improvement for most organisations in 2026 is not a new tool. It is finding the forgotten software and retiring or patching it.