The EOL Blind Spot in Your CVE Feed: What SCA Tools Don’t Check.

Written by Isaac Wuest, Principal Product Manager at HeroDevs.

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.

That’s true, but it’s only half the story, and arguably the less dangerous half. There are two compounding problems most teams are unaware of.

Problem One: The CVE Ecosystem Doesn’t Investigate What It Doesn’t Support

When a vulnerability is discovered in an open source project, maintainers determine which versions are affected and file a CVE with a defined affected range. Every vulnerability scanner, SBOM tool, and CVE feed in the industry consumes that range.

If your version falls outside it, you get no alert. Not because you’re safe, but because no one checked.

EOL versions fall outside that range almost by default. The reason is straightforward: it’s a scale problem. In just five years, the global CVE count doubled while the number of unscored CVEs increased 37x, according to Sonatype’s 2026 State of the Software Supply Chain report.

Maintainers are already overwhelmed investigating and patching the versions they actively support, and as both CVE volume and the total number of package releases continue to grow, the investigative bandwidth required to cover older release lines simply doesn’t exist.

Maintainers must be realistic about how far back in their own release history they can reasonably go.

Sonatype’s research explicitly named “EOL versions omitted from advisories” as a driver of false security confidence, contributing to the 167,286 false negatives, exploitable components that went entirely unflagged, they identified in 2025 alone.

What This Looks Like in Practice

Two recent critical vulnerabilities in the Spring ecosystem make this concrete.

CVE-2026-22732 — Spring Security (Critical, March 2026, CVSS 9.1)

This vulnerability 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 is not listed. It reached EOL in December 2025. Spring Boot 3.2 ships with Spring Security 6.2. Any organization running Boot 3.2, one minor version behind the listed range, receives no scanner signal.

HeroDevs has confirmed Spring Security 6.2.x is affected and has backported a fix for NES customers. The upstream CVE record does not reflect this.

How Often Does This Happen?

The Spring examples above are not outliers. They reflect a pattern HeroDevs encounters consistently across its Never-Ending-Support practice.

When a new CVE is disclosed on a supported package, HeroDevs finds it needs to patch an EOL version the official CVE record does not list as affected approximately 80% of the time. The blast radius of any given vulnerability is systematically wider than what the record shows.

Put plainly: for four out of every five CVEs disclosed on a supported version, there is a reasonable probability that an EOL version you are running is also affected,  and no scanner in the world will tell you that.

Problem Two: The Industry Is Counting the Wrong EOL Software

The CVE investigation gap above applies to EOL software that the community actually knows is EOL. That turns out to be a very small fraction of the real problem.

The most widely cited 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 identified as EOL. That is the universe most scanners and security teams are working from.

Here is the actual scale of the problem.

In Sonatype’s 2026 State of the Software Supply Chain report, produced in partnership with HeroDevs, the data tells a different story. 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.

However, the industry’s most complete public source (endoflife.date) only accounts for ~7,000 of them.

The breakdown by ecosystem is striking. Approximately 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 appearing in enterprise SBOMs today, with no CVE investigation coverage and no fix path.

The Sonatype report found that 5–15% of components in enterprise dependency graphs are EOL, indicating EOL exposure even when teams believe they are only using supported top-level libraries. Transitive dependencies, the packages your packages depend on, carry the majority of this hidden exposure.

Most organizations are profoundly underreporting their EOL exposure, and it is not their fault. Their tooling was never built to detect abandonment at 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 confirmed.

Given that roughly 80% of CVEs on supported versions also affect EOL versions that were never officially investigated, the true number is likely far larger. HeroDevs estimates the actual figure may be closer to >400,000 across all registries.

Why This Is Getting Worse

This dynamic is not new. What is new is the rate at which it is compounding.

The OSS ecosystem is scaling faster than the security infrastructure built to monitor it. npm alone recorded over 838,000 releases associated with critical CVSS 9.0+ scores in 2025. PyPI download volume grew over 50% year over year.

Every new package version that enters a registry is a future EOL version, and the EOL population grows continuously, while the investigative capacity to cover it does not.

The more significant forcing function, however, may be AI.

In April 2026, Anthropic announced Project Glasswing alongside Claude Mythos Preview, documenting its ability to identify and exploit zero-day vulnerabilities across all major operating systems and browsers — including vulnerabilities undetected for decades.

The initiative is explicitly defensive, directed toward finding and fixing critical vulnerabilities before attackers can exploit them.

For software with active support, this is genuinely good news. Vulnerabilities found at AI scale can be routed to engineers who can address them.

For EOL software, the calculus is different. An AI that finds vulnerabilities across the entire codebase landscape will surface findings in versions no maintainer is watching. Those findings will not be officially investigated against the EOL-affected ranges.

They will not trigger scanner alerts for EOL users. No upstream patch will ever address them. The same capability that accelerates defense for supported software widens the exposure gap for everything already left behind.

The early signals of this shift are already visible. The full impact hasn’t arrived yet.

What To Do

Start with visibility. HeroDevs offers a free EOL scan. 

Upload dependency files or use the CLI to identify EOL exposure across your stack in minutes, covering both announced and abandoned packages across all major registries.

Don’t treat scanner silence as safety. A clean scan against an EOL package means the package wasn’t checked, not that it isn’t vulnerable.

The Spring CVEs above are current proof — in both cases, EOL users were exposed without warning until HeroDevs investigated and reported.

EOL dates are not finish lines. They are the moment risk silently transfers from maintainer to operator. As AI-assisted vulnerability research scales, the number of undisclosed vulnerabilities in uninvestigated EOL packages will only grow.

Get started today with HeroDev’s free EOL scan.

Sponsored and written by HeroDevs.

Adblock test (Why?)