Der blinde Fleck im CVE-Feed: Warum EOL-Software an Schwachstellen-Scannern vorbeirutscht

Zusammenfassung

End-of-Life-Software (EOL) gilt vielen Sicherheitsteams vor allem als Problem fehlender Patches. Ein Beitrag von HeroDevs argumentiert, dass dies nur die halbe und die weniger gefährliche Hälfte des Problems sei. Wird in einem Open-Source-Projekt eine Schwachstelle entdeckt, legen die Maintainer einen betroffenen Versionsbereich fest und melden eine CVE. Jeder Schwachstellen-Scanner, jedes SBOM-Werkzeug und jeder CVE-Feed stützt sich auf genau diesen Bereich. Liegt die eingesetzte Version außerhalb, gibt es keine Warnung — nicht, weil sie sicher wäre, sondern weil niemand sie geprüft hat. EOL-Versionen fallen nahezu zwangsläufig aus diesem Bereich heraus, weil die Maintainer mit der Untersuchung der aktiv unterstützten Versionen bereits ausgelastet sind. Laut Sonatypes State-of-the-Software-Supply-Chain-Report 2026 hat sich die globale Zahl der CVEs binnen fünf Jahren verdoppelt, während die Zahl der nicht bewerteten CVEs um das 37-Fache stieg. Der Report benennt ausgelassene EOL-Versionen in Sicherheitshinweisen ausdrücklich als Ursache trügerischer Sicherheit — und führt sie auf 167.286 falsch-negative, ausnutzbare Komponenten zurück, die 2025 unentdeckt blieben.

HeroDevs verweist auf zwei aktuelle kritische Schwachstellen im Spring-Ökosystem, um das Problem greifbar zu machen. CVE-2026-22732 betrifft Spring Security, gilt als kritisch (CVSS 9.1) und wurde im März 2026 bekannt. 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 offiziell betroffene Bereich umfasst Spring Security 5.7.x bis 7.0.x.

Spring Security 6.2.x ist dort nicht aufgeführt — diese Version erreichte im Dezember 2025 ihr End-of-Life. Da Spring Boot 3.2 mit Spring Security 6.2 ausgeliefert wird, erhält jede Organisation, die Boot 3.2 einsetzt, keinerlei Scanner-Signal. HeroDevs hat nach eigenen Angaben bestätigt, dass 6.2.x betroffen ist, und für Kunden seines Never-Ending-Support einen Fix zurückportiert; der offizielle CVE-Eintrag spiegelt das nicht wider.

Nach Erfahrung von HeroDevs ist das kein Einzelfall: Wird eine neue CVE für ein unterstütztes Paket veröffentlicht, muss das Unternehmen in rund 80 Prozent der Fälle auch eine EOL-Version patchen, die der offizielle Eintrag nicht als betroffen führt. Der tatsächliche Wirkungsbereich einer Schwachstelle ist demnach systematisch größer als dokumentiert.

Dieser Untersuchungslücke liegt zudem ein noch größeres Problem zugrunde: die Frage, welche Software überhaupt als EOL bekannt ist. Die meistzitierte Quelle, endoflife.date, erfasst rund 350 aktiv gepflegte Projekte mit etwa 7.000 als EOL markierten Versionen. Auf dieser Basis arbeiten die meisten Scanner und Sicherheitsteams.

Die Analyse von HeroDevs für den Sonatype-Report zeichnet ein anderes Bild: Von 12 Millionen untersuchten Paketversionen über npm, PyPI, Maven, NuGet, RubyGems, Go, Packagist und crates.io sind 5,4 Millionen End-of-Life. Nach Ökosystemen aufgeschlüsselt sind etwa 25 Prozent der npm-Versionen betroffen, bei NuGet rund 18 Prozent, bei Cargo 13, bei PyPI 11 und bei Maven Central 10 Prozent.

Laut Report sind 5 bis 15 Prozent der Komponenten in den Abhängigkeitsgraphen von Unternehmen EOL — wobei der Großteil dieser verdeckten Exposition auf transitive Abhängigkeiten entfällt, also auf die Pakete, von denen die eigenen Pakete abhängen. HeroDevs hat über 81.000 EOL-Paketversionen mit bekannten CVEs und ohne verfügbaren Fix bestätigt; angesichts der 80-Prozent-Quote schätzt das Unternehmen die wahre Zahl auf über 400.000.

Als zusätzlichen Treiber nennt HeroDevs den Faktor KI. Anthropic kündigte im April 2026 mit Project Glasswing und der Claude Mythos Preview eine Fähigkeit an, Zero-Day-Schwachstellen über alle großen Betriebssysteme und Browser hinweg aufzuspüren und auszunutzen — darunter teils jahrzehntelang unentdeckte Lücken. Die Initiative ist ausdrücklich defensiv ausgerichtet. Für unterstützte Software lassen sich solche Funde an Entwickler weiterreichen; bei EOL-Software dagegen werden die Befunde nicht offiziell gegen die betroffenen Versionsbereiche geprüft, lösen keine Scanner-Warnung aus und erhalten nie einen Patch.

Der blinde Fleck im CVE-Feed: Warum EOL-Software an Schwachstellen-Scannern vorbeirutscht

Ähnliche Artikel

Neueste Artikel