Written by Isaac Wuest, Principal Product Supervisor at HeroDevs.
When security groups take into consideration end-of-life (EOL) open supply software program, the dialog often begins and ends in the identical place: no extra patches.
That is true, nevertheless it’s solely half the story, and arguably the much less harmful half. There are two compounding issues most groups are unaware of.
Downside One: The CVE Ecosystem Would not Examine What It Would not Help
When a vulnerability is found in an open supply undertaking, maintainers decide which variations are affected and file a CVE with an outlined affected vary. Each vulnerability scanner, SBOM device, and CVE feed within the business consumes that vary.
In case your model falls outdoors it, you get no alert. Not since you’re protected, however as a result of nobody checked.
EOL variations fall outdoors that vary nearly by default. The reason being easy: it is a scale downside. In simply 5 years, the worldwide CVE depend doubled whereas the variety of unscored CVEs elevated 37x, in accordance with Sonatype’s 2026 State of the Software program Provide Chain report.
Maintainers are already overwhelmed investigating and patching the variations they actively assist, and as each CVE quantity and the whole variety of bundle releases proceed to develop, the investigative bandwidth required to cowl older launch traces merely would not exist.
Maintainers should be lifelike about how far again in their very own launch historical past they will moderately go.
Sonatype’s analysis explicitly named “EOL variations omitted from advisories” as a driver of false security confidence, contributing to the 167,286 false negatives, exploitable elements that went solely unflagged, they recognized in 2025 alone.
HeroDevs’ EOL DS tracks end-of-life standing throughout 12M+ bundle variations on npm, PyPI, Maven, NuGet, and each different main registry.
Add an SBOM or run the CLI to search out each EOL dependency in your stack, together with the transitive ones your scanners cannot flag.
Get Your Free EOL Threat Report
What This Seems to be Like in Apply
Two current vital vulnerabilities within the Spring ecosystem make this concrete.
CVE-2026-22732 — Spring Safety (Vital, March 2026, CVSS 9.1)
This vulnerability causes security response headers, together with Cache-Management, X-Body-Choices, Strict-Transport-Safety, and Content material-Safety-Coverage, to be silently dropped in sure servlet utility configurations. The official affected vary covers Spring Safety 5.7.x by way of 7.0.x.
Spring Safety 6.2.x is just not listed. It reached EOL in December 2025. Spring Boot 3.2 ships with Spring Safety 6.2. Any group working Boot 3.2, one minor model behind the listed vary, receives no scanner sign.
HeroDevs has confirmed Spring Safety 6.2.x is affected and has backported a repair for NES clients. The upstream CVE report doesn’t mirror this.
How Usually Does This Occur?
The Spring examples above aren’t outliers. They mirror a sample HeroDevs encounters constantly throughout its By no means-Ending-Help follow.
When a brand new CVE is disclosed on a supported bundle, HeroDevs finds it must patch an EOL model the official CVE report doesn’t record as affected roughly 80% of the time. The blast radius of any given vulnerability is systematically wider than what the report reveals.
Put plainly: for 4 out of each 5 CVEs disclosed on a supported model, there’s a cheap likelihood that an EOL model you’re working can be affected, and no scanner on the planet will inform you that.
Downside Two: The Business Is Counting the Unsuitable EOL Software program
The CVE investigation hole above applies to EOL software program that the group really is aware of is EOL. That seems to be a really small fraction of the actual downside.
Probably the most extensively cited supply of EOL information is endoflife.date, which tracks roughly 350 actively maintained initiatives; main frameworks and runtimes the place maintainers have explicitly printed end-of-life dates.
Throughout these 350 initiatives, roughly 7,000 particular bundle variations are recognized as EOL. That’s the universe most scanners and security groups are working from.
Right here is the precise scale of the issue.
In Sonatype’s 2026 State of the Software program Provide Chain report, produced in partnership with HeroDevs, the information tells a distinct story. Analyzing lifecycle standing throughout 12 million bundle variations spanning npm, PyPI, Maven, NuGet, RubyGems, Go, Packagist, and crates.io, HeroDevs discovered that 5.4 million of these variations are end-of-life.
Nonetheless, the business’s most full public supply (endoflife.date) solely accounts for ~7,000 of them.
The breakdown by ecosystem is placing. Roughly 25% of npm bundle variations are EOL. NuGet sits at round 18%, Cargo at 13%, PyPI at 11%, and Maven Central at 10%. These are variations actively showing in enterprise SBOMs right now, with no CVE investigation protection and no repair path.
The Sonatype report discovered that 5–15% of elements in enterprise dependency graphs are EOL, indicating EOL publicity even when groups consider they’re solely utilizing supported top-level libraries. Transitive dependencies, the packages your packages rely upon, carry nearly all of this hidden publicity.
Most organizations are profoundly underreporting their EOL publicity, and it isn’t their fault. Their tooling was by no means constructed to detect abandonment at scale.
HeroDevs has confirmed greater than 81,000 EOL bundle variations with identified CVEs and no out there repair path, which means these are CVEs that had been actively investigated and confirmed.
On condition that roughly 80% of CVEs on supported variations additionally have an effect on EOL variations that had been by no means formally investigated, the true quantity is probably going far bigger. HeroDevs estimates the precise determine could also be nearer to >400,000 throughout all registries.
Why This Is Getting Worse
This dynamic is just not new. What’s new is the speed at which it’s compounding.
The OSS ecosystem is scaling quicker than the security infrastructure constructed to observe it. npm alone recorded over 838,000 releases related to vital CVSS 9.0+ scores in 2025. PyPI obtain quantity grew over 50% 12 months over 12 months.
Each new bundle model that enters a registry is a future EOL model, and the EOL inhabitants grows repeatedly, whereas the investigative capability to cowl it doesn’t.
The extra vital forcing perform, nevertheless, could also be AI.
In April 2026, Anthropic introduced Mission Glasswing alongside Claude Mythos Preview, documenting its potential to establish and exploit zero-day vulnerabilities throughout all main working methods and browsers — together with vulnerabilities undetected for many years.
The initiative is explicitly defensive, directed towards discovering and fixing vital vulnerabilities earlier than attackers can exploit them.
For software program with energetic assist, that is genuinely excellent news. Vulnerabilities discovered at AI scale could be routed to engineers who can handle them.
For EOL software program, the calculus is completely different. An AI that finds vulnerabilities throughout the complete codebase panorama will floor findings in variations no maintainer is watching. These findings won’t be formally investigated towards the EOL-affected ranges.
They won’t set off scanner alerts for EOL customers. No upstream patch will ever handle them. The identical functionality that accelerates protection for supported software program widens the publicity hole for every part already left behind.
The early indicators of this shift are already seen. The complete affect hasn’t arrived but.
How A lot of Your Stack is Already EOL?
You do not know. Your scanner would not know. Your CVE feed would not know.
Sonatype’s information says 5–15% of elements in a typical enterprise stack are EOL. For npm alone, it is 25% of all bundle variations. Spring Boot 3.2 shipped Spring Safety 6.2, EOL since December, no scanner alert.
What’s your quantity?
The HeroDevs EOL Dataset tells you in below 5 minutes. Add an SBOM or run the CLI. We test it towards 12M+ bundle variations throughout npm, PyPI, Maven, NuGet, and each different main registry, together with the transitive dependencies your scanner skipped. You get a report itemizing each EOL bundle in your stack. No gross sales name. No bank card.
As AI-assisted vulnerability analysis scales, the variety of undisclosed vulnerabilities in uninvestigated EOL packages will solely develop.
[Run My Free EOL Scan →]
Sponsored and written by HeroDevs.
