81,000 Open Source Package Versions Have Known CVEs and No Patch. Here's Why That Number Is Probably Much Higher.

There is a number in the 2026 State of the Software Supply Chain Report that deserves more attention than it has received: 81,000.

That's the number of open source package versions with known CVEs that are both end-of-life and unpatchable. No fix is coming. The maintainer is gone, the project is abandoned, the release line is closed. The vulnerability exists, it's been disclosed, and there is no upstream path forward.

HeroDevs contributed this estimate to the SSCR, and we believe the actual number is closer to 400,000 when you account for the full scope of open source registries and the significant portion of EOL vulnerabilities that are never formally disclosed at all.

Here's what that number means, why it's likely an undercount, and what security teams should actually do with this information.

‍

What Does "Unpatchable EOL Vulnerability" Actually Mean?

An unpatchable EOL vulnerability is a disclosed security flaw in a software package that will never receive a remediation patch from upstream — because the project maintaining that package is no longer active.

This is distinct from vulnerabilities that are slow to be patched, vulnerabilities under embargo, or vulnerabilities where teams haven't applied existing fixes. Those are consumption and process problems. An unpatchable EOL vulnerability is a structural problem: the normal mechanism for resolving it no longer exists.

When a vulnerability is disclosed in an actively maintained package, the process is predictable. The maintainer acknowledges it, a fix is developed, the fix is released, and organizations apply it. That process may be fast or slow depending on the severity and the team, but the path forward exists.

When a vulnerability is disclosed in an EOL package, that path doesn't exist. The package can't be patched. The advisory may note the EOL status. The fix may exist in a newer, incompatible major version. But for organizations running the EOL version — and millions of enterprise applications are — the standard remediation workflow produces a ticket that can never be closed.

‍

Why 81,000 Is Probably a Floor

The 81,000 figure represents package versions in the registries HeroDevs and Sonatype analyzed where both conditions are true: the package is EOL, and at least one CVE exists for that version. It's a meaningful number. It's also an undercount for several reasons.

Advisory coverage degrades for EOL packages. When a package reaches end of life, the security community gradually stops looking at it as closely. CVE assignments slow down. Advisories are less likely to be filed. Researchers focus on actively maintained codebases where their findings can actually produce fixes. This means that for many EOL packages, the absence of a filed CVE isn't evidence of safety — it's evidence of reduced scrutiny. Vulnerabilities may exist that simply haven't been found or reported because nobody is actively looking.

The 400,000 estimate accounts for full registry coverage. The 81,000 figure focused on specific ecosystems with reliable EOL signal. When HeroDevs estimates the full scope across all major and minor registries — including ecosystems where EOL data is less standardized — the number grows substantially. Open source exists across hundreds of package ecosystems, and the EOL tracking infrastructure for most of them is immature compared to npm or Maven Central.

EOL without a formal declaration is common. Many projects don't formally announce end of life. Maintainers move on. Repositories go quiet. Release cadences stop. But because there's no official declaration, no EOL date is recorded, no advisory is issued, and no scanner flags the package as end-of-life. Organizations running these packages often have no visibility into their unsupported status until something breaks or a researcher happens to notice.

‍

What Happens to Vulnerability Management When Patches Don't Exist

Most vulnerability management programs are built on an assumption that rarely gets examined: the assumption that patches exist or will exist for the vulnerabilities being tracked.

The workflow that most security teams run looks something like this: scanners identify vulnerabilities, findings are triaged by severity, tickets are opened, and engineering teams apply patches during their next sprint or scheduled maintenance window. The program is measured by mean time to remediation, number of open critical CVEs, and compliance with patching SLAs.

This workflow works reasonably well for the consumption layer of vulnerability risk — where vulnerabilities exist in actively maintained software that produces patches on some cadence. It breaks down completely for the ecosystem layer, where no patches are coming.

When a scanner flags an EOL component with a known CVE, there are only a few possible outcomes:

Option 1: Migrate away from the EOL component. This is always the right long-term answer. It's also often not immediately feasible. Major framework migrations are complex, resource-intensive, and slow. A team managing 40 other priorities can't always drop everything to rewrite a working application on a new framework because one of its dependencies went EOL.

Option 2: Accept the risk and document it. Some organizations formally accept the risk of running EOL software, document the exposure, and build compensating controls around it. This is a defensible posture in some circumstances, but it requires accurate visibility into what EOL exposure you're accepting — and it doesn't satisfy compliance requirements in regulated industries.

Option 3: Apply a backported security patch. Commercial extended support providers like HeroDevs backport security fixes to EOL release lines, providing patches for vulnerabilities that upstream maintainers are no longer addressing. This doesn't eliminate the EOL debt, but it eliminates the specific CVE exposure while migrations are planned and executed.

What isn't a real option: leaving the ticket open and waiting for a patch that isn't coming. That's not vulnerability management — that's vulnerability accumulation.

‍

The Hidden Cost of EOL Debt in Your Dependency Graph

One of the most important findings from the SSCR's EOL analysis is that 5 to 15 percent of components in enterprise dependency graphs are EOL — even in organizations with relatively mature security programs. This percentage shows up consistently across ecosystems and persists over time.

The reason is structural. Most organizations manage their direct dependencies with reasonable discipline. They know what they've explicitly included in their projects. But transitive dependencies — the packages that your packages depend on — accumulate outside of active governance. A library you imported three years ago has its own dependencies, and some of those dependencies may have reached EOL without anyone in your organization noticing.

This is how EOL exposure hides. It's not that organizations are deliberately running abandoned software. It's that the dependency graph grows faster and in more directions than any team can actively track, and EOL status propagates through the graph in ways that surface vulnerability scanner results don't capture.

‍

What to Do About Unpatchable EOL Vulnerabilities

The practical response to EOL vulnerability exposure starts with visibility. You can't manage what you can't see, and most organizations don't have a clear, current picture of their EOL footprint — especially in the transitive dependency graph.

Get an accurate EOL inventory. This means going beyond your top-level dependencies to your full transitive graph, across all applications in your portfolio. Point-in-time audits aren't sufficient because EOL events happen continuously — new packages reach EOL on a rolling basis, and your graph changes with every build.

Separate EOL risk from patchable risk in your tracking. Treating unpatchable EOL vulnerabilities the same as vulnerabilities with available fixes distorts your remediation metrics and creates false urgency in some areas while real structural risk goes unaddressed in others. EOL vulnerabilities need a different workflow because they have a different resolution path.

Build migration plans with realistic timelines. For every EOL component in your dependency graph, there should be a documented plan for what happens next — whether that's migration to a supported version, replacement with an alternative, or a formal acceptance with compensating controls. Roadmaps that live only in someone's head don't produce action.

Use commercial extended support as a bridge, not a destination. NES and similar backport services exist to buy organizations time — not to eliminate the need for migration. They provide security coverage for the period between "we know this is EOL" and "we've completed the migration," which in complex enterprise environments can be a period of months or years.

‍

Check Your EOL Exposure

HeroDevs' EOL Detection Suite gives your team continuous, portfolio-wide visibility into end-of-life dependencies — including your full transitive graph, not just top-level packages. When a package reaches EOL or a new CVE drops against an unsupported version, you know immediately rather than finding out during an audit.

For EOL components where migration isn't immediately on the table, Never-Ending Support provides security patches and CVE remediation that keeps your exposure under control while your team works through the migration backlog on a realistic schedule.

Find out how much of your graph is EOL: eoldataset.com

‍

Frequently Asked Questions

What is an unpatchable EOL vulnerability? An unpatchable EOL vulnerability is a disclosed security flaw in a software package that will never receive an upstream fix because the project is no longer actively maintained. Unlike vulnerabilities in supported software — where a patch will eventually be released — EOL vulnerabilities have no upstream remediation path. Organizations running the affected version must migrate, replace the dependency, or use commercial extended support to receive backported patches.

Why does HeroDevs estimate 400,000 unpatchable CVEs when the SSCR cites 81,000? The 81,000 figure cited in the 2026 SSCR represents a conservative count from specific ecosystems with reliable EOL signal. HeroDevs estimates the actual figure across all registries is closer to 400,000 when accounting for: registries with immature EOL tracking infrastructure, packages with undisclosed vulnerabilities due to reduced scrutiny of EOL codebases, and projects that have effectively reached end of life without a formal declaration.

How do I find EOL vulnerabilities in my application's dependency graph? Finding EOL vulnerabilities requires looking beyond your direct dependencies to your full transitive dependency graph. HeroDevs' EOL Detection Suite provides continuous monitoring of EOL status across your entire portfolio. Traditional SCA scanners often miss EOL exposure because they're optimized for finding CVEs in active software rather than detecting end-of-life status in unsupported packages.

What's the difference between an EOL vulnerability and a regular unpatched vulnerability? A regular unpatched vulnerability has a fix available that an organization hasn't applied yet — a consumption and workflow problem. An EOL vulnerability has no upstream fix available and never will — a structural problem that requires migration, replacement, or commercial backport support. These require different workflows, different metrics, and different remediation approaches.

Can I get patches for EOL open source software? Yes. Commercial extended support providers like HeroDevs backport security patches to EOL release lines, providing fixes for vulnerabilities that upstream maintainers no longer address. This is a bridge solution — it provides security coverage while migrations are planned — not a permanent replacement for modernizing to supported software.

‍