By Isaac Wuest, Principal Product Manager at HeroDevs.
When security professionals discuss end-of-life (EOL) open source software, the discussion typically revolves around a single point: patches stop coming.
That’s accurate, but it only tells part of the story — and likely the less risky part. There are two compounding issues that most teams don’t realize exist.
Issue One: The CVE System Doesn’t Examine What It Doesn’t Support
When a flaw is found in an open source project, maintainers identify which versions are impacted and submit a CVE with a specified affected range. Every vulnerability scanner, SBOM tool, and CVE feed in the industry relies on that range.
If your version sits outside it, you won’t get a warning. Not because you’re secure, but because nobody looked.
EOL versions sit outside that range almost automatically. The reason is simple: it’s a matter of scale. In just five years, the worldwide CVE count doubled while the number of unscored CVEs surged 37x, according to Sonatype’s 2026 State of the Software Supply Chain report.
Maintainers are already stretched thin investigating and fixing the versions they actively maintain, and as both CVE volume and the total number of package releases keep climbing, the research capacity needed to cover older release lines simply isn’t there.
Maintainers need to be practical about how far back in their own release history they can realistically go.
Sonatype’s research directly identified “EOL versions left out of advisories” as a source of false security confidence, contributing to the 167,286 false negatives — exploitable components that went completely undetected — they uncovered in 2025 alone.
HeroDevs’ EOL DS monitors end-of-life status across 12M+ package versions on npm, PyPI, Maven, NuGet, and every other major registry.
Upload an SBOM or run the CLI to uncover every EOL dependency in your stack, including the transitive ones your scanners can’t detect.
Get Your Free EOL Risk Report
What This Looks Like in the Real World
Two recent critical vulnerabilities in the Spring ecosystem illustrate this clearly.
CVE-2026-22732 — Spring Security (Critical, March 2026, CVSS 9.1)
This flaw causes security response headers — including Cache-Control, X-Frame-Options, Strict-Transport-Security, and Content-Security-Policy — to be silently dropped in certain servlet application configurations. The official affected range covers Spring Security 5.7.x through 7.0.x.
Spring Security 6.2.x isn’t listed. It reached EOL in December 2025. Spring Boot 3.2 ships with Spring Security 6.2. Any organization running Boot 3.2 — just one minor version behind the listed range — gets no scanner warning whatsoever.
HeroDevs has verified that Spring Security 6.2.x is affected and has backported a fix for NES customers. The upstream CVE record doesn’t reflect this.
How Frequently Does This Occur?
The Spring examples above aren’t exceptions. They represent a pattern HeroDevs sees regularly across its Never-Ending-Support practice.
When a new CVE is disclosed on a supported package, HeroDevs discovers it needs to patch an EOL version that the official CVE record doesn’t list as affected roughly 80% of the time. The true impact of any given vulnerability is consistently broader than what the record indicates.
To put it simply: for four out of every five CVEs disclosed on a supported version, there’s a strong chance that an EOL version you’re running is also vulnerable — and no scanner on the planet will alert you.
Issue Two: The Industry Is Measuring the Wrong EOL Software
The CVE investigation gap described above applies to EOL software that the community actually recognizes as EOL. That turns out to be a tiny fraction of the real problem.
The most commonly referenced source of EOL data is endoflife.date, which tracks roughly 350 actively maintained projects — major frameworks and runtimes where maintainers have explicitly published end-of-life dates.
Across those 350 projects, approximately 7,000 specific package versions are flagged as EOL. That’s the universe most scanners and security teams operate from.
Here’s the true scale of the problem.
In Sonatype’s 2026 State of the Software Supply Chain report, produced in partnership with HeroDevs, the data paints a different picture. Analyzing lifecycle status across 12 million package versions spanning npm, PyPI, Maven, NuGet, RubyGems, Go, Packagist, and crates.io, HeroDevs found that 5.4 million of those versions are end-of-life.
Yet the industry’s most comprehensive public source (endoflife.date) accounts for only ~7,000 of them.
The breakdown by ecosystem is eye-opening. Roughly 25% of npm package versions are EOL. NuGet sits at around 18%, Cargo at 13%, PyPI at 11%, and Maven Central at 10%. These are versions actively showing up in enterprise SBOMs today, with no CVE investigation coverage and no fix path available.
The Sonatype report found that 5–15% of components in enterprise dependency graphs are EOL, meaning EOL exposure exists even when teams believe they’re only using supported top-level libraries. Transitive dependencies — the packages your packages rely on — carry most of this hidden risk.
Most organizations are drastically underreporting their EOL exposure, and it’s not their fault. Their tools were never designed to detect abandonment at this scale.
HeroDevs has confirmed more than 81,000 EOL package versions with known CVEs and no available fix path — meaning these are CVEs that were actively investigated and verified.
Given that roughly 80% of CVEs on supported versions also affect EOL versions that were never officially examined, the true number is likely far higher. HeroDevs estimates the actual figure may be closer to >400,000 across all registries.
Why This Problem Is Accelerating
This dynamic isn’t new. What’s new is the speed at which it’s compounding.
The OSS ecosystem is growing faster than the security infrastructure built to monitor it. npm alone recorded over 838,000 releases tied to critical CVSS 9.0+ scores in 2025. PyPI download volume grew more than 50% year over year.
Every new package version that enters a registry becomes a future EOL version, and the EOL population keeps expanding, while the investigative capacity to cover it doesn’t.
The bigger driving force, however, may be AI.
In April 2026, Anthropic announced Project Glasswing alongside Claude Mythos Preview, documenting its ability to discover and exploit zero-day vulnerabilities across all major operating systems and browsers — including vulnerabilities that went undetected for decades.
The initiative is explicitly defensive, aimed at finding and fixing critical vulnerabilities before attackers can exploit them.
For software with active support, this is genuinely positive news. Vulnerabilities found at AI scale can be routed to engineers who can address them.
For EOL software, the equation changes. An AI that uncovers vulnerabilities across the entire codebase landscape will surface findings in versions no maintainer is monitoring. Those findings won’t be officially investigated against the EOL-affected ranges.
They won’t trigger scanner alerts for EOL users. No upstream patch will ever resolve them. The same capability that accelerates defense for supported software widens the exposure gap for everything already left behind.
Early signs of this shift are already visible. The full impact hasn’t hit yet.
How Much of Your Stack Is Already EOL?
You don’t know. Your scanner doesn’t know. Your CVE feed doesn’t know.
Sonatype’s data says 5–15% of components in a typical enterprise stack are EOL. For npm alone, it’s 25% of all package versions. Spring Boot 3.2 shipped Spring Security 6.2, EOL since December, no scanner alert.
What’s your number?
The HeroDevs EOL Dataset tells you in under five minutes. Upload an SBOM or run the CLI. We check it against 12M+ package versions across npm, PyPI, Maven, NuGet, and every other major registry, including the transitive dependencies your scanner missed. You get a report listing every EOL package in your stack. No sales call. No credit card.
As AI-assisted vulnerability research scales, the number of undisclosed vulnerabilities in uninvestigated EOL packages will only grow.
[Run My Free EOL Scan →]
Sponsored and written by HeroDevs.
