Die Ursache ist laut HeroDevs ein Skalierungsproblem. Dem Sonatype-Bericht „2026 State of the Software Supply Chain" zufolge hat sich die globale Zahl der CVEs in nur fünf Jahren verdoppelt, während die Zahl der nicht bewerteten CVEs um das 37-Fache stieg. Maintainer seien bereits mit der Untersuchung und Behebung der aktiv unterstützten Versionen überlastet; die Kapazität, ältere Release-Linien abzudecken, existiere schlicht nicht. Sonatype benennt „aus Advisories ausgelassene EOL-Versionen" ausdrücklich als Treiber für falsche Sicherheit und führt darauf einen Teil der 167.286 falsch-negativen Befunde — ausnutzbarer Komponenten, die allein 2025 völlig unmarkiert blieben — zurück.
Wie konkret das wird, zeigt HeroDevs an CVE-2026-22732 in Spring Security (kritisch, März 2026, CVSS 9.1). Durch die Lücke werden in bestimmten Servlet-Konfigurationen Sicherheits-Header wie Cache-Control, X-Frame-Options, Strict-Transport-Security und Content-Security-Policy stillschweigend verworfen. Der offizielle Versionsbereich umfasst Spring Security 5.7.x bis 7.0.x. Version 6.2.x ist nicht aufgeführt — sie erreichte im Dezember 2025 ihr EOL. Da Spring Boot 3.2 mit Spring Security 6.2 ausgeliefert wird, erhält jede Organisation, die Boot 3.2 betreibt, kein Scanner-Signal. HeroDevs hat die Betroffenheit von 6.2.x bestätigt und für NES-Kunden einen Fix zurückportiert; im offiziellen CVE-Eintrag findet sich das nicht.
Nach Angaben von HeroDevs ist das kein Einzelfall: Wird eine neue CVE für ein unterstütztes Paket bekannt, muss das Unternehmen in rund 80 Prozent der Fälle auch eine EOL-Version patchen, die im offiziellen Eintrag nicht als betroffen geführt wird. Der tatsächliche Wirkungsradius einer Schwachstelle sei also systematisch größer als dokumentiert.
Hinzu kommt ein Erfassungsproblem. Die meistzitierte EOL-Quelle endoflife.date verfolgt rund 350 aktiv gepflegte Projekte mit etwa 7.000 als EOL markierten Paketversionen. Der gemeinsam mit HeroDevs erstellte Sonatype-Bericht analysierte hingegen den Lifecycle-Status von 12 Millionen Paketversionen über npm, PyPI, Maven, NuGet, RubyGems, Go, Packagist und crates.io — und identifizierte 5,4 Millionen davon als EOL. Aufgeschlüsselt nach Ökosystemen sind demnach etwa 25 Prozent der npm-Versionen EOL, bei NuGet rund 18 Prozent, bei Cargo 13, bei PyPI 11 und bei Maven Central 10 Prozent.
Laut Bericht sind 5 bis 15 Prozent der Komponenten in den Abhängigkeitsgraphen von Unternehmen EOL, wobei der Großteil dieser verdeckten Last in transitiven Abhängigkeiten steckt. HeroDevs hat über 81.000 EOL-Paketversionen mit bekannten CVEs und ohne Fix-Pfad bestätigt; angesichts der 80-Prozent-Quote schätzt das Unternehmen die reale Zahl auf über 400.000.
Als zusätzlichen Treiber nennt HeroDevs künstliche Intelligenz. Anthropic kündigte im April 2026 das Projekt Glasswing zusammen mit Claude Mythos Preview an und dokumentierte die Fähigkeit, Zero-Day-Schwachstellen über alle gängigen Betriebssysteme und Browser hinweg aufzuspüren und auszunutzen — auch solche, die jahrzehntelang unentdeckt blieben. Die Initiative ist ausdrücklich defensiv ausgerichtet. Für unterstützte Software lassen sich solche Funde an Entwickler weiterreichen; bei EOL-Software jedoch tauchen Befunde in Versionen auf, die kein Maintainer mehr beobachtet, die nicht offiziell geprüft werden und für die nie ein Patch erscheint.