CVE-Flut: Warum Open-Source-Maintainer überrannt werden

Open-Source-Maintainer patchen in ihrer Freizeit. KI-Scanner finden Schwachstellen rund um die Uhr. Und dazwischen: ein System, das nie für dieses Volumen gebaut wurde.

Die Zahlen hinter der Flut

CVE steht für Common Vulnerabilities and Exposures – ein standardisiertes Verzeichnis öffentlich bekannter Sicherheitslücken in Software. Jede gemeldete Schwachstelle bekommt eine eindeutige Kennung (z.B. CVE-2024-3094), über die sich Hersteller, Scanner und Datenbanken weltweit koordinieren. Wenn hier von CVE-Flut die Rede ist, geht es um die explodierende Anzahl dieser Meldungen.

CVE-Meldungen steigen seit Jahren. 2024 lag der Anstieg bei 32 Prozent gegenüber dem Vorjahr. In den ersten neun Monaten 2025 wurden bereits über 35.000 CVEs veröffentlicht – Prognose für das Gesamtjahr: zwischen 45.000 und 50.000 neue Schwachstellen. Linux allein hat als CVE Numbering Authority das System mit einem enormen Volumen an Meldungen belastet.

Das National Vulnerability Database (NVD) kommt nicht hinterher. Nur 28 Prozent der 2025 gemeldeten CVEs wurden vollständig analysiert, ein Rückgang von 46 Prozent im Vorjahr. Über 54.000 CVEs aus 2024 und 2025 warten noch auf ihre Einordnung. NIST selbst nennt die Arbeit “sehr arbeitsintensiv” und “nicht skalierbar auf die Menge an CVEs, die wir erhalten”.

Gleichzeitig steigt die Geschwindigkeit, mit der Schwachstellen ausgenutzt werden: 32 Prozent der 2025 aktiv exploiteten Lücken wurden innerhalb von 24 Stunden nach Veröffentlichung angegriffen – oder sogar davor. 2024 lag dieser Wert noch bei 23 Prozent.

Wer das auffangen soll: Freiwillige

60 Prozent der Open-Source-Maintainer arbeiten unbezahlt. Dieselben 60 Prozent haben bereits gekündigt oder darüber nachgedacht. 44 Prozent nennen Burnout als Hauptgrund. Die Zahlen stammen nicht aus Randprojekten – sie betreffen die Infrastruktur, auf der Millionen von Anwendungen laufen.

300 Millionen Unternehmen nutzen Open Source. 4.200 zahlen dafür. Das ist eine Freeloading-Rate von 99,999 Prozent. Nur 14 Prozent der Unternehmensinvestitionen in Open Source fließen direkt an Maintainer – der Rest geht in Consulting und Support-Dienstleistungen.

Die Konsequenzen sind bereits sichtbar – und sie treffen nicht irgendwelche Nischenprojekte.

Kubernetes Ingress NGINX: Eine der meistgenutzten Komponenten stirbt

Am 11. November 2025 verkündeten Kubernetes SIG Network und das Security Response Committee das Retirement von Ingress NGINX. Nicht wegen technischer Überlegenheit einer Alternative. Wegen Maintainer-Burnout.

Ingress NGINX steuert den eingehenden HTTP-Traffic für Kubernetes-Cluster. Über 40 Prozent aller Kubernetes-Administratoren nutzen die Komponente. Jahrelang wurde sie von ein bis zwei Personen gepflegt – in ihrer Freizeit, nach der Arbeit, an Wochenenden. Als die Komplexität wuchs (Security-Patches, NGINX-Updates, Multi-Version-Support), konnte diese Besetzung nicht mehr mithalten.

Im März 2025 wurde dann CVE-2025-1974 bekannt, getauft „IngressNightmare”: Eine kritische Schwachstelle, die unauthentifizierte Remote Code Execution ermöglichte und potenziell ganze Cluster-Übernahmen erlaubte. Was einst als Stärke galt – die Flexibilität, beliebige NGINX-Konfigurationen per Annotations zu setzen – erwies sich als Sicherheitsrisiko, das mit der vorhandenen Maintainer-Kapazität nicht mehr beherrschbar war.

Ab März 2026 gibt es keine Releases, keine Bugfixes, keine Security-Patches mehr. Die offizielle Empfehlung: sofortige Migration auf die Gateway API oder einen anderen aktiv gepflegten Ingress Controller.

External Secrets Operator: Vier Maintainer ausgebrannt

Am 13. August 2025 verkündete das Team des External Secrets Operator (ESO) den Freeze aller Releases. ESO verwaltet API-Keys, Passwörter und Tokens für Kubernetes-Deployments weltweit – kritische Infrastruktur für Enterprise-Systeme.

Vier Maintainer waren ausgebrannt. Übrig blieb ein einziger aktiver Contributor: Gergely Brautigam. Als er in den Urlaub ging, wurden null Pull Requests gemergt bei über 20 offenen Issues. Sein Kommentar: “People don’t always respect our time, our effort, our anything. People feel entitled – but that’s not how this works.”

Keine neuen Features, keine Patches, keine Container-Images, kein Support über Slack oder GitHub – bis mindestens fünf aktive Maintainer gefunden werden.

Wenn KI das Problem verschärft statt es zu lösen: Der Fall curl

curl ist eines der meistgenutzten Open-Source-Projekte der Welt. Die Bibliothek libcurl steckt in praktisch jedem Gerät mit Internetverbindung – Smartphones, Router, IoT-Devices, Server. Wenn es ein Projekt gibt, das als Goldstandard für Open-Source-Pflege gilt, dann dieses. Daniel Stenberg, der Maintainer, betreibt es seit über 25 Jahren.

Genau dieses Projekt wurde zum Paradebeispiel dafür, wie KI die Situation verschlimmern kann.

Der AI-Slop-Tsunami

Seit 2024 meldeten zunehmend Personen über die Bug-Bounty-Plattform HackerOne vermeintliche Sicherheitslücken in curl – generiert mit KI-Tools wie ChatGPT, Bard oder anderen LLMs. Die Reports klangen technisch, waren lang, detailliert und selbstbewusst formuliert. Und sie waren falsch.

Ein konkretes Beispiel: Ein Report enthielt eine angebliche GDB-Debug-Session mit Speicherregister-Dumps, die auf eine spezifische Funktion verwies. Die Funktion existierte im curl-Repository nicht. Ein anderer Report lieferte einen Code-Snippet von curl_easy_setopt, der nicht der tatsächlichen Signatur entsprach und nicht einmal kompiliert hätte, dazu ein Changelog, das nicht der Realität entsprach. Klassische Halluzination – aber verpackt in das Format eines seriösen Security-Reports.

Die Modelle identifizierten dabei routinemäßig Standard-Verhalten von C-Funktionen wie strcpy oder sprintf als angebliche Remote-Code-Execution-Schwachstellen – ohne reproduzierbaren Angriffsvektor, ohne Memory-Payload, ohne Proof-of-Concept.

Die Eskalation in Zahlen

Anfang 2025 war noch etwa jeder sechste Security-Report echt. Ende 2025 lag die Quote bei einem von 20 bis 30. Das Volumen der Einreichungen stieg auf das Achtfache des Normalwerts. Rund 20 Prozent aller Submissions waren reiner AI-Slop. In sechs Jahren Monitoring hat keine einzige rein KI-generierte Einreichung eine echte Schwachstelle gefunden.

Der Zeitaufwand zum Sichten jedes einzelnen Reports, nur um ihn als ungültig einzustufen, entsprach laut Stenberg einem DDoS-Angriff auf das Projekt. Jeder falsche Report kostet eine erfahrene Person 30 bis 60 Minuten Analysezeit – Zeit, die für echte Security-Arbeit fehlt.

Das Ende des Bug-Bounty-Programms

Stenberg zog die Konsequenzen. Zunächst führte er im Mai 2025 eine Sofort-Ban-Policy ein für AI-generierte Einreichungen. Als das nicht reichte, folgte die Ankündigung: Ab dem 1. Februar 2026 akzeptiert curl keine HackerOne-Reports mehr. Keine Bounties, kein Geld. Alle Security-Reports laufen jetzt über GitHubs Private Vulnerability Reporting – ohne monetäre Anreize.

In der gesamten Laufzeit des Bug-Bounty-Programms wurden 87 echte Schwachstellen bestätigt und über 100.000 US-Dollar an Researcher ausgezahlt. Ein Programm, das über Jahre echten Wert lieferte, wurde durch AI-Slop zerstört.

Stenbergs Fazit: “Ich werde jeden bannen und öffentlich bloßstellen, der unsere Zeit mit diesem Müll verschwendet.”

Die Ironie: KI findet auch echte Bugs

Das Bittere an der Geschichte: KI-gestützte Analyse findet in den richtigen Händen tatsächlich echte Schwachstellen. Fortgeschrittene AI-Analyzer haben tiefe Bugs in curl und anderen kritischen Projekten aufgedeckt, die kein bisheriges Tool gefunden hatte. Eine Analyse fand 50 echte Bugs in curl mithilfe von KI-Tools. Das Problem ist nicht die Technologie selbst – es sind die Anreize. Wer mit minimalem Aufwand einen KI-generierten Report einreicht und auf eine Bounty-Auszahlung hofft, betreibt kein Security Research. Er betreibt Spam.

Warum das alle betrifft

Wenn ein Maintainer seine Zeit mit der Analyse falscher Reports verbringt statt mit echten Patches, werden echte Schwachstellen langsamer geschlossen. Wenn ein Maintainer ausbrennt und ein Projekt aufgibt, bleiben bekannte Lücken offen. Die Downstream-Effekte treffen jedes Unternehmen, das diese Dependencies nutzt – und das sind, bei Projekten wie curl, praktisch alle.

Die Kombination aus steigender CVE-Flut, KI-generiertem Rauschen und sinkender Maintainer-Kapazität erzeugt eine gefährliche Dynamik: Mehr Schwachstellen werden gefunden, weniger werden gepatcht, und die Zeit zwischen Exploit und Fix wird länger.

Was Unternehmen jetzt tun können

Maintainer direkt finanzieren

Nicht über Umwege. Direkt. Tidelift bietet ein Subskriptionsmodell (100-150 Euro pro Entwickler jährlich), das Einnahmen an Maintainer weiterleitet, basierend auf tatsächlicher Nutzung. Der Sovereign Tech Fund der Bundesregierung hat sein Budget von 3,5 Millionen Euro (2022) auf 17 Millionen Euro (2025) gesteigert. Alpha-Omega, ein Projekt der Linux Foundation, hat 2025 5,8 Millionen Dollar an 14 Projekte vergeben. Die Open Source Endowment, eine neue Initiative von Thomas Dohmke (ex-GitHub-CEO), Mitchell Hashimoto (HashiCorp) und anderen, hat bereits über 750.000 Dollar an Zusagen gesammelt.

Das sind gute Ansätze. Aber bei 300 Millionen Unternehmen, die profitieren, und 4.200, die zahlen, reicht das bei weitem nicht.

Eigene Security-Verantwortung übernehmen

Wer kritische Open-Source-Dependencies nutzt, sollte nicht darauf warten, dass der Maintainer patcht. Optionen:

• Security-Personal auf Upstream-Projekte allokieren: Entwickler, die bezahlt daran arbeiten, Schwachstellen in den Projekten zu fixen, von denen das eigene Business abhängt.
• Eigene Forks für kritische Dependencies: Wenn ein Projekt keine Patches mehr liefert, braucht es einen internen Fork mit eigenem Maintenance-Team.
• SBOMs ernst nehmen: Software Bill of Materials erstellen und pflegen, um zu wissen, welche Dependencies in der eigenen Software stecken – bevor die nächste CVE kommt.

KI-Reports filtern, nicht ignorieren

Die Antwort auf AI-Slop ist nicht, alle automatisierten Reports zu blockieren. Es ist, die guten von den schlechten zu trennen. Unternehmen können interne Triage-Prozesse aufbauen, die KI-gestützte Findings vorfiltern, bevor sie an Upstream-Maintainer weitergeleitet werden. Das spart dem Maintainer Zeit und erhöht die Qualität der Reports, die ankommen.

Das strukturelle Problem

Die Open-Source-Infrastruktur des Internets wurde von Freiwilligen gebaut. Die Wirtschaft hat darauf eine Billionen-Dollar-Industrie errichtet, ohne die Fundamente zu pflegen. KI beschleunigt jetzt beides – das Finden von Schwachstellen und das Erzeugen von Rauschen. Die Maintainer stehen dazwischen, mit denselben 24 Stunden am Tag wie vorher.

Der Fall curl zeigt das Dilemma in Reinform: Ein Projekt, das über Jahrzehnte vorbildlich gepflegt wurde, mit einem Maintainer, der alles richtig macht – und trotzdem überrollt wird von einem System, das seine Anreize falsch setzt.

Die Lösung liegt nicht in besseren KI-Modellen. Sie liegt in besserer Infrastruktur-Finanzierung, intelligenteren Triage-Systemen und der Erkenntnis, dass “kostenlos” immer jemand bezahlt. Bisher sind das die Maintainer. Das ist nicht nachhaltig.

Quellen

• Ingress NGINX Retirement: What You Need to Know – Kubernetes Blog
• Ingress NGINX Deprecation: EOL by March 2026 – chkk.io
• Users scramble as critical open source project left to die – The Register
• External Secrets Operator is paused. What’s next? – Infisical
• How Maintainer Burnout Is Causing a Kubernetes Security Disaster – The New Stack
• Burnout on Kubernetes secrets puts OSS support in spotlight – The Stack
• Open Source Maintainer Crisis: 60% Unpaid, Burnout Hits 44% – ByteIota
• Daniel Stenberg on AI-generated curl bug reports – daniel.haxx.se
• Burnout Prevention – External Secrets Operator Docs