Written through Isaac Wuest, Main Product Supervisor at HeroDevs.
When safety groups take into accounts end-of-life (EOL) open supply tool, the dialog normally begins and results in the similar position: not more patches.
That is true, however it is only part the tale, and arguably the fewer unhealthy part. There are two compounding issues maximum groups are blind to.
Drawback One: The CVE Ecosystem Does not Examine What It Does not Give a boost to
When a vulnerability is came upon in an open supply challenge, maintainers resolve which variations are affected and record a CVE with an outlined affected vary. Each and every vulnerability scanner, SBOM software, and CVE feed within the business consumes that vary.
In case your model falls out of doors it, you get no alert. Now not since you’re protected, however as a result of nobody checked.
EOL variations fall out of doors that vary nearly through default. The reason being easy: it is a scale drawback. In simply 5 years, the worldwide CVE rely doubled whilst the choice of unscored CVEs larger 37x, in line with Sonatype’s 2026 State of the Tool Provide Chain document.
Maintainers are already beaten investigating and patching the variations they actively reinforce, and as each CVE quantity and the overall choice of package deal releases keep growing, the investigative bandwidth required to hide older unencumber strains merely does not exist.
Maintainers should be life like about how a long way again in their very own unencumber historical past they may be able to relatively cross.
Sonatype’s analysis explicitly named “EOL variations overlooked from advisories” as a motive force of false safety self belief, contributing to the 167,286 false negatives, exploitable elements that went completely unflagged, they recognized in 2025 on my own.
HeroDevs’ EOL DS tracks end-of-life standing throughout 12M+ package deal variations on npm, PyPI, Maven, NuGet, and each and every different primary registry.
Add an SBOM or run the CLI to search out each and every EOL dependency for your stack, together with the transitive ones your scanners can not flag.
Get Your Unfastened EOL Possibility Document
What This Appears to be like Like in Apply
Two contemporary crucial vulnerabilities within the Spring ecosystem make this concrete.
CVE-2026-22732 — Spring Safety (Important, March 2026, CVSS 9.1)
This vulnerability reasons safety reaction headers, together with Cache-Keep watch over, X-Body-Choices, Strict-Shipping-Safety, and Content material-Safety-Coverage, to be silently dropped in positive servlet software configurations. The reliable affected vary covers Spring Safety 5.7.x via 7.0.x.
Spring Safety 6.2.x isn’t indexed. 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 in the back of the indexed vary, receives no scanner sign.
HeroDevs has showed Spring Safety 6.2.x is affected and has backported a repair for NES consumers. The upstream CVE file does now not replicate this.
How Incessantly Does This Occur?
The Spring examples above don’t seem to be outliers. They replicate a trend HeroDevs encounters persistently throughout its By no means-Finishing-Give a boost to apply.
When a brand new CVE is disclosed on a supported package deal, HeroDevs unearths it must patch an EOL model the reliable CVE file does now not listing as affected roughly 80% of the time. The blast radius of any given vulnerability is systematically wider than what the file displays.
Put evidently: for 4 out of each and every 5 CVEs disclosed on a supported model, there’s a affordable chance that an EOL model you might be working could also be affected, and no scanner on the planet will let you know that.
Drawback Two: The Trade Is Counting the Incorrect EOL Tool
The CVE investigation hole above applies to EOL tool that the neighborhood in reality is aware of is EOL. That seems to be an excessively small fraction of the true drawback.
Probably the most broadly cited supply of EOL information is endoflife.date, which tracks kind of 350 actively maintained initiatives; primary frameworks and runtimes the place maintainers have explicitly revealed end-of-life dates.
Throughout the ones 350 initiatives, roughly 7,000 explicit package deal variations are recognized as EOL. That’s the universe maximum scanners and safety groups are operating from.
This is the true scale of the issue.
In Sonatype’s 2026 State of the Tool Provide Chain document, produced in partnership with HeroDevs, the information tells a unique tale. Examining lifecycle standing throughout 12 million package deal variations spanning npm, PyPI, Maven, NuGet, RubyGems, Cross, Packagist, and crates.io, HeroDevs discovered that 5.4 million of the ones variations are end-of-life.
Then again, the business’s maximum entire public supply (endoflife.date) handiest accounts for ~7,000 of them.
The breakdown through ecosystem is placing. Roughly 25% of npm package deal variations are EOL. NuGet sits at round 18%, Shipment at 13%, PyPI at 11%, and Maven Central at 10%. Those are variations actively showing in undertaking SBOMs these days, and not using a CVE investigation protection and no repair trail.
The Sonatype document discovered that 5–15% of elements in undertaking dependency graphs are EOL, indicating EOL publicity even if groups consider they’re handiest the use of supported top-level libraries. Transitive dependencies, the applications your applications rely on, raise nearly all of this hidden publicity.
Maximum organizations are profoundly underreporting their EOL publicity, and it’s not their fault. Their tooling was once by no means constructed to hit upon abandonment at scale.
HeroDevs has showed greater than 81,000 EOL package deal variations with identified CVEs and no to be had repair trail, which means those are CVEs that had been actively investigated and showed.
For the reason that kind of 80% of CVEs on supported variations additionally have an effect on EOL variations that had been by no means formally investigated, the real quantity is most probably a long way greater. HeroDevs estimates the true determine is also nearer to >400,000 throughout all registries.
Why This Is Getting Worse
This dynamic isn’t new. What’s new is the velocity at which it’s compounding.
The OSS ecosystem is scaling quicker than the protection infrastructure constructed to watch it. npm on my own recorded over 838,000 releases related to crucial CVSS 9.0+ ratings in 2025. PyPI obtain quantity grew over 50% yr over yr.
Each and every new package deal model that enters a registry is a long run EOL model, and the EOL inhabitants grows incessantly, whilst the investigative capability to hide it does now not.
The extra vital forcing serve as, then again, is also AI.
In April 2026, Anthropic introduced Mission Glasswing along Claude Mythos Preview, documenting its skill to spot and exploit zero-day vulnerabilities throughout all primary working methods and browsers — together with vulnerabilities undetected for many years.
The initiative is explicitly defensive, directed towards discovering and solving crucial vulnerabilities ahead of attackers can exploit them.
For tool with energetic reinforce, that is really excellent information. Vulnerabilities discovered at AI scale will also be routed to engineers who can deal with them.
For EOL tool, the calculus is other. An AI that unearths vulnerabilities throughout all of the codebase panorama will floor findings in variations no maintainer is observing. The ones findings may not be formally investigated towards the EOL-affected levels.
They’ll now not cause scanner indicators for EOL customers. No upstream patch will ever deal with them. The similar capacity that speeds up protection for supported tool widens the publicity hole for the whole thing already left in the back of.
The early alerts of this shift are already visual. The overall have an effect on hasn’t arrived but.
What To Do
Get started with visibility. HeroDevs provides a unfastened EOL scan.
Add dependency recordsdata or use the CLI to spot EOL publicity throughout your stack in mins, overlaying each introduced and deserted applications throughout all primary registries.
Do not deal with scanner silence as protection. A blank scan towards an EOL package deal method the package deal wasn’t checked, now not that it’s not prone.
The Spring CVEs above are present evidence — in each instances, EOL customers had been uncovered with out caution till HeroDevs investigated and reported.
EOL dates don’t seem to be end strains. They’re the instant chance silently transfers from maintainer to operator. As AI-assisted vulnerability analysis scales, the choice of undisclosed vulnerabilities in uninvestigated EOL applications will handiest develop.
Get began these days with HeroDev’s unfastened EOL scan.
Subsidized and written through HeroDevs.
