The EOL Blind Spot in Your CVE Feed: What SCA Tools Miss

The EOL Blind Spot in Your CVE Feed: What SCA Tools Miss

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 that are leaving their software stacks exposed to known vulnerabilities that scanners will never flag.

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.

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.

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.

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%
• 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.

HeroDevs has confirmed more than 81,000 EOL package versions with known CVEs and no available fix path. Given that roughly 80% of CVEs on supported versions also affect EOL versions that were never officially investigated, the true number is likely closer to >400,000 across all registries.

Why This Is Getting Worse

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.

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.

How to Address the EOL Blind Spot

You don't know how much of your stack is already EOL. 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.

Organizations need to implement a comprehensive EOL detection strategy that goes beyond what traditional SCA tools provide. This includes:

1. Mapping EOL status across all dependencies, including transitive dependencies that scanners often miss
2. Implementing a process to evaluate and prioritize EOL components based on their criticality to your business
3. Developing a plan to replace or mitigate EOL components, especially those handling sensitive data or critical functions
4. Regularly updating your EOL knowledge base as new versions are released and others reach end-of-life

The HeroDevs EOL Dataset provides one approach to this challenge, checking software stacks against 12M+ package versions across npm, PyPI, Maven, NuGet, and every other major registry, including transitive dependencies your scanner skipped.

As AI-assisted vulnerability research scales, the number of undisclosed vulnerabilities in uninvestigated EOL packages will only grow. Organizations that proactively identify and address their EOL exposure now will be better positioned to manage the expanding security landscape of tomorrow.

This article highlights a critical vulnerability in how organizations manage their software supply chain security. By understanding and addressing the EOL blind spot, security teams can reduce their exposure to known vulnerabilities that traditional tools fail to detect.