EOL Open Source Risks: CVE Feed Gaps Exposed

HeroDevs released a new analysis showing that end‑of‑life (EOL) open‑source components create systematic blind spots in CVE feeds and the Software Composition Analysis (SCA) tools that rely on them. The research examined more than 30 popular libraries that have reached official EOL status, such as Log4j 1.x, Spring Framework 5.0.x, and the Python 2 interpreter, and found that known critical flaws such as CVE‑2020‑9488 (Log4j 1.x), CVE‑2021‑44228 (Log4j 2.x), and CVE‑2022‑22965 (Spring4Shell) were either omitted or down‑graded because the National Vulnerability Database (NVD) marks EOL versions as “won’t fix”.

SCA platforms such as Snyk, Sonatype Nexus Lifecycle, and Mend (formerly WhiteSource) typically filter vulnerability results to only those versions that are still officially supported. When a library’s version range is flagged as EOL, the scanner’s “supported” flag is set to false, and the associated CVEs are hidden from the default dashboard. This design choice, intended to reduce noise, inadvertently strips out high‑severity entries that remain exploitable in legacy codebases. For example, Snyk’s vulnerability database shows CVE‑2022‑22965 only for Spring 5.2.x before 5.2.19, while the older 5.0.x branch, which is EOL, is absent from the feed despite containing the same deserialization flaw.

The consequence is a false sense of security: organizations that trust CVE‑driven SCA reports may believe their open‑source risk is minimal, while vulnerable EOL code still runs in production environments. In a test environment, the HeroDevs team demonstrated a remote code execution (RCE) payload successfully exploiting CVE‑2020‑9488 on a Log4j 1.2.17 instance that was never flagged by either the NVD entry or the scanner’s default policy. The study also found that only 12 % of surveyed enterprise teams manually audit EOL components, leaving the majority exposed to known‑but‑untracked threats.

To close the gap, security teams should supplement feeds with EOL‑aware vulnerability databases—such as Sonatype’s Component Lifecycle data or Mend’s EOL Insight—and configure SCA tools to include “unsupported” versions in policy checks. Generating a comprehensive Software Bill of Materials (SBOM) that explicitly tags EOL libraries, and scheduling periodic manual reviews of those components, are practical steps that can catch hidden CVEs. HeroDevs is offering a free e‑book titled “EOL Blind Spots: Untangling CVE Feed Gaps” that details remediation playbooks, configuration snippets for Snyk and Nexus Lifecycle, and a template SBOM; download it at hackmyip.com/hero-devs-report.