"When security teams think about end-of-life (EOL) open source software, the conversation usually starts and ends in the same place: no more patches." — Isaac Wuest, HeroDevs.
The CVE investigative gap and a surge of false negatives
Vulnerabilities are reported against specific version ranges; scanners and SBOM tools consume those ranges. If your installed version falls outside the declared affected range, those tools remain silent — not because the software is safe, but because it was not checked. That omission is not theoretical. Sonatype's 2026 State of the Software Supply Chain report, produced in partnership with HeroDevs, shows the global CVE count doubled in five years while unscored CVEs jumped 37x. In 2025 alone, Sonatype identified 167,286 false negatives — exploitable components that went entirely unflagged.
Spring case study: CVE-2026-22732 and Spring Security 6.2.x
HeroDevs uses recent Spring vulnerabilities to demonstrate the risk. CVE-2026-22732 (Spring Security, Critical, March 2026, CVSS 9.1) was recorded with an affected range of Spring Security 5.7.x through 7.0.x. Spring Security 6.2.x, which reached EOL in December 2025 and is shipped in Spring Boot 3.2, is not listed in the official affected range — and so scanners would not warn operators running Boot 3.2. HeroDevs confirmed 6.2.x is affected and backported a fix for its Never-Ending-Support (NES) customers; the upstream CVE record does not reflect that coverage.
The true scale: millions of EOL versions versus a few thousand tracked publicly
Public EOL lists commonly referenced by security teams are tiny compared with the underlying registries. endoflife.date tracks roughly 350 actively maintained projects and identifies approximately 7,000 specific package versions as EOL. By contrast, HeroDevs analyzed lifecycle status across 12 million package versions spanning npm, PyPI, Maven, NuGet, RubyGems, Go, Packagist, and crates.io, and found 5.4 million of those versions are end-of-life.
The distribution is striking: about 25% of npm package versions are EOL; NuGet about 18%; Cargo about 13%; PyPI about 11%; and Maven Central about 10%. Sonatype's report also found that 5–15% of components in enterprise dependency graphs are EOL, meaning many organizations carry EOL transitive dependencies even when top-level libraries appear supported.
HeroDevs confirmed more than 81,000 EOL package versions with known CVEs and no available fix path. Given their observation that roughly 80% of CVEs on supported versions also affect EOL versions that were never officially investigated, HeroDevs estimates the true number of EOL packages with unpatched CVEs may be closer to >400,000 across all registries.
Anthropic's Project Glasswing and the paradox of AI-assisted discovery
AI changes the calculus. In April 2026, Anthropic announced Project Glasswing alongside Claude Mythos Preview, documenting the ability to identify and exploit zero-day vulnerabilities across major operating systems and browsers. The announcement described Project Glasswing as explicitly defensive — intended to find and fix critical vulnerabilities before attackers do.
For actively supported software, rapid, AI-scale discovery can be routed to engineers and patched. For EOL software, however, AI-driven findings will surface vulnerabilities in versions no maintainer is watching. Those findings will not trigger scanner alerts for EOL users, will not be investigated against EOL-affected ranges, and will not produce upstream patches — widening the exposure gap even as discovery accelerates.
How technologists, open-source maintainers, and enterprise procurement should respond
- Technologists and security teams: Treat scanner silence as a lack of investigation, not proof of safety. HeroDevs recommends visibility first — uploading dependency files or using a CLI scan to identify EOL exposure across registries, including transitive dependencies.
- Open-source maintainers: The report emphasizes maintainers' limited investigative bandwidth. As CVE volume and package release cadence grow, maintainers must be realistic about how far back they can reasonably investigate and publish advisories for older release lines.
- Procurement and enterprise leaders: Enterprise SBOMs commonly include EOL components; Sonatype's data shows 5–15% of components in enterprise dependency graphs are EOL. Procurement and risk teams should account for EOL risk and for the possibility that official advisories will understate blast radius.
Two central takeaways are unambiguous in the record: first, current CVE records and SCA tooling undercount exposure because they do not and cannot investigate every historical release line; second, the growth of the OSS ecosystem and the arrival of AI vulnerability discovery together magnify that blind spot. HeroDevs' recommended first step is increased visibility — an EOL scan to surface abandoned or unannounced EOL packages — and a change in posture that treats EOL dates as the moment risk transfers from maintainer to operator, not as an endpoint.
