Written by means of Isaac Wuest, Fundamental Product Supervisor at HeroDevs.
When safety groups take into consideration end-of-life (EOL) open supply tool, the dialog in most cases begins and results in the similar position: not more patches.
That is true, however it is just part the tale, and arguably the fewer unhealthy part. There are two compounding issues maximum groups are blind to.
Downside One: The CVE Ecosystem Does not Examine What It Does not Beef up
When a vulnerability is found out in an open supply venture, maintainers decide 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 outdoor it, you get no alert. Now not since you’re secure, however as a result of nobody checked.
EOL variations fall outdoor that vary nearly by means of default. The reason being simple: it is a scale downside. In simply 5 years, the worldwide CVE rely doubled whilst the choice of unscored CVEs higher 37x, in line with Sonatype’s 2026 State of the Tool Provide Chain record.
Maintainers are already crushed investigating and patching the variations they actively make stronger, and as each CVE quantity and the full choice of bundle releases keep growing, the investigative bandwidth required to hide older free up traces merely does not exist.
Maintainers will have to be sensible about how a ways again in their very own free up historical past they are able to fairly move.
Sonatype’s analysis explicitly named “EOL variations not noted from advisories” as a motive force of false safety self assurance, contributing to the 167,286 false negatives, exploitable elements that went solely unflagged, they known in 2025 by myself.
HeroDevs’ EOL DS tracks end-of-life standing throughout 12M+ bundle variations on npm, PyPI, Maven, NuGet, and each and every different main registry.
Add an SBOM or run the CLI to seek out each and every EOL dependency to your stack, together with the transitive ones your scanners cannot flag.
Get Your Loose EOL Chance File
What This Seems to be Like in Observe
Two fresh essential vulnerabilities within the Spring ecosystem make this concrete.
CVE-2026-22732 — Spring Safety (Vital, March 2026, CVSS 9.1)
This vulnerability reasons safety reaction headers, together with Cache-Keep an eye on, X-Body-Choices, Strict-Delivery-Safety, and Content material-Safety-Coverage, to be silently dropped in positive servlet utility 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 operating 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 shoppers. The upstream CVE file does now not mirror this.
How Incessantly Does This Occur?
The Spring examples above don’t seem to be outliers. They mirror a development HeroDevs encounters constantly throughout its By no means-Finishing-Beef up apply.
When a brand new CVE is disclosed on a supported bundle, HeroDevs reveals 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 presentations.
Put it appears that evidently: for 4 out of each and every 5 CVEs disclosed on a supported model, there’s a affordable likelihood that an EOL model you might be operating may be affected, and no scanner on this planet will inform you that.
Downside Two: The Trade Is Counting the Unsuitable EOL Tool
The CVE investigation hole above applies to EOL tool that the group in truth is aware of is EOL. That seems to be an overly small fraction of the true downside.
Essentially the most broadly cited supply of EOL information is endoflife.date, which tracks more or less 350 actively maintained tasks; main frameworks and runtimes the place maintainers have explicitly printed end-of-life dates.
Throughout the ones 350 tasks, roughly 7,000 particular bundle variations are known as EOL. That’s the universe maximum scanners and safety groups are running from.
Here’s the real scale of the issue.
In Sonatype’s 2026 State of the Tool Provide Chain record, produced in partnership with HeroDevs, the information tells a special tale. Examining lifecycle standing throughout 12 million bundle 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 whole public supply (endoflife.date) handiest accounts for ~7,000 of them.
The breakdown by means of ecosystem is putting. Roughly 25% of npm bundle 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 endeavor SBOMs as of late, and not using a CVE investigation protection and no repair trail.
The Sonatype record discovered that 5–15% of elements in endeavor dependency graphs are EOL, indicating EOL publicity even if groups consider they’re handiest the usage of supported top-level libraries. Transitive dependencies, the programs your programs rely on, lift the vast majority of this hidden publicity.
Maximum organizations are profoundly underreporting their EOL publicity, and it isn’t their fault. Their tooling used to be by no means constructed to hit upon abandonment at scale.
HeroDevs has showed greater than 81,000 EOL bundle variations with recognized CVEs and no to be had repair trail, that means those are CVEs that had been actively investigated and showed.
For the reason that more or less 80% of CVEs on supported variations additionally have an effect on EOL variations that had been by no means formally investigated, the actual quantity is most probably a ways better. HeroDevs estimates the real 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 speed at which it’s compounding.
The OSS ecosystem is scaling quicker than the protection infrastructure constructed to watch it. npm by myself recorded over 838,000 releases related to essential CVSS 9.0+ ratings in 2025. PyPI obtain quantity grew over 50% 12 months over 12 months.
Each and every new bundle model that enters a registry is a long run EOL model, and the EOL inhabitants grows frequently, whilst the investigative capability to hide it does now not.
The extra important forcing serve as, alternatively, 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 main working techniques and browsers — together with vulnerabilities undetected for many years.
The initiative is explicitly defensive, directed towards discovering and solving essential vulnerabilities ahead of attackers can exploit them.
For tool with energetic make stronger, that is in actuality just right information. Vulnerabilities discovered at AI scale can also be routed to engineers who can deal with them.
For EOL tool, the calculus is other. An AI that reveals vulnerabilities throughout all the codebase panorama will floor findings in variations no maintainer is gazing. The ones findings might not be formally investigated towards the EOL-affected levels.
They’re going to 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 lot already left in the back of.
The early indicators of this shift are already visual. The overall affect hasn’t arrived but.
How A lot of Your Stack is Already EOL?
You do not know. Your scanner does not know. Your CVE feed does not know.
Sonatype’s information says 5–15% of elements in a normal endeavor stack are EOL. For npm by myself, it is 25% of all bundle variations. Spring Boot 3.2 shipped Spring Safety 6.2, EOL since December, no scanner alert.
What is your quantity?
The HeroDevs EOL Dataset tells you in below 5 mins. Add an SBOM or run the CLI. We test it towards 12M+ bundle variations throughout npm, PyPI, Maven, NuGet, and each and every different main registry, together with the transitive dependencies your scanner skipped. You get a record record each and every EOL bundle to your stack. No gross sales name. No bank card.
As AI-assisted vulnerability analysis scales, the choice of undisclosed vulnerabilities in uninvestigated EOL programs will handiest develop.
[Run My Free EOL Scan →]
Subsidized and written by means of HeroDevs.
