37.966 KI-Funde, 217 Fixes? Wo die Reparatur hängt und wo sie mithält

Darum geht es

Es gibt kaum noch eine Meldung über KI-Sicherheitsforschung ohne beeindruckende Fundzahlen. Spannender ist, was danach passiert. Eine gefundene Lücke schützt niemanden, solange sie nicht geprüft, verstanden und repariert ist. In der ersten Novemberhälfte 2026 sind dazu mehrere Datenpunkte erschienen, die auf den ersten Blick nicht zusammenpassen. Das Sicherheitsunternehmen VulnCheck rechnet vor, dass Anthropics Programm Project Glasswing fast 38.000 Funde, aber nur 217 Fixes vorweisen kann. In derselben Woche meldet der Linux-Kernel für einen Teilbereich eine Trendwende, und Apache flickt eine kritische Lücke in 16 Tagen.

Unsere These: Der Engpass ist nicht das Finden, sondern das Sichten (Fachleute sagen Triage) und das Reparieren. Wer geprüfte Patches mitliefert oder selbst mit KI repariert, hält Schritt. Wer große Mengen Rohmeldungen an knapp besetzte Projekte schickt, lässt den Berg wachsen. Außerdem zählt jeder etwas anderes als „behoben“.

217 oder 629: Zwei Zahlen aus demselben Haus

Glasswing ist im April 2026 gestartet. Anthropic stellt dafür sein Modell Claude Mythos Preview Partnern und Open-Source-Projekten zur Verfügung. Die Firma veröffentlicht zwei Datenquellen. Das Ledger ist eine öffentliche Liste, in der jeder Fund zunächst nur als kryptografischer Fingerabdruck (Hash) steht. Projekt, Fehlerart und Kennnummern werden erst sichtbar, wenn die Schonfrist für die Offenlegung abgelaufen ist. Das Dashboard zeigt dagegen Gesamtzahlen.

„Upstream gepatcht“ heißt laut Dashboard: Das Projekt hat einen Fix veröffentlicht. Ob Nutzer ihn eingespielt haben, ist damit nicht gesagt. Laut einer Auswertung von cellcog.ai stehen die 217 „fixed“-Einträge alle unter den nur 235 Funden, deren Details schon enthüllt sind. Die meisten der 629 Patches tauchen im Ledger also schlicht noch nicht auf.

Das verändert die Lesart deutlich. VulnCheck betont, dass das Ledger zwischen September und November nur 15 neue Fixes zeigt. Im Dashboard stieg die Zahl im ähnlichen Zeitraum von 421 (Anfang September, von VulnCheck selbst zitiert) über 516 (2. Oktober) auf 629. Unsere Rechnung: Von allen Kandidaten sind damit 1,7 Prozent gepatcht, von den tatsächlich gemeldeten Funden 12,4 Prozent. Das ist mehr als „unter 0,5 Prozent“, aber immer noch wenig.

Eine Ungereimtheit erklärt Anthropic nicht: Am 2. Oktober meldete das Dashboard 6.157 gemeldete Funde, davon 4.824 direkt verschickte. Einen Monat später sind es nur noch 5.087 bzw. 3.225. Eine Zahl, die eigentlich nur wachsen kann, ist um gut 1.000 gesunken. Naheliegend ist, dass Duplikate nachträglich herausgerechnet wurden. Anthropic hat eingeräumt, dass viele Meldungen Duplikate eigener Funde waren. Belegt ist dieser Zusammenhang aber nicht.

Was VulnCheck misst und was nicht

Patrick Garrity von VulnCheck verfolgt Glasswing seit April und hat am 9. November sein Siebenmonats-Audit veröffentlicht. Seine wichtigsten Punkte:

• 442 CVEs (öffentliche Kennnummern für Sicherheitslücken) gehen auf Anthropic zurück. Das sind etwa 0,5 Prozent aller 93.450 CVEs dieses Jahres.
• Nur 2 davon stehen in VulnCheck KEV, der Liste nachweislich von Angreifern ausgenutzter Lücken.
• 1.654 Duplikate stehen 217 Fixes gegenüber, also rund 7,6-mal so viele.
• Die 94,2-Prozent-Trefferquote rechne Duplikate und zurückgezogene Funde (419) nicht ein.

„Ich weiß nicht, wie man diese Zahlen anders als vernichtend lesen kann.“

Die Kritik trifft, hat aber Schwächen. VulnCheck nennt die 629 aus dem Dashboard überhaupt nicht. In der eigenen Tabelle stehen 1.670 Duplikate, im Text 1.654. Die Statusliste des Ledgers geht mit 1.654 rechnerisch auf (4.866 + 1.654 + 419 + 217 + 193 = 7.349). Dazu kommt der Absender: VulnCheck verkauft Schwachstellen- und Exploit-Daten. Beide Glasswing-Analysen enden mit einem Aufruf, eine Produktdemo zu buchen. Darauf weist auch das chinesische Portal QbitAI hin. Falsch werden die Zahlen dadurch nicht. Die Botschaft „Rohfunde helfen wenig, priorisierte Daten schon“ ist aber zugleich VulnCheck's Geschäftsmodell. Eine Antwort von Anthropic hatte Infosecurity Magazine bis Redaktionsschluss nicht erhalten.

curl: kaum Fehlalarme, aber wenig Sicherheitsrelevanz

Oft zitiert wird curl, das Kommandozeilenwerkzeug für Datenübertragungen. Laut VulnCheck waren von 34 öffentlich bewerteten Anthropic-Meldungen 19 „keine Sicherheitslücke“ (55,9 %) und 6 Lücken niedriger Schwere. Daraus wurde vielerorts „56 Prozent Fehlalarme“. Das stimmt so nicht. Im curl-Verfahren bedeutet die Einstufung vuln:NONE „nur ein Bug“, also ein echter Fehler, der aber keine Sicherheitslücke ist.

Am 10. November schrieb Daniel Stenberg auf Mastodon: Von den 45 Funden seien 7 als LOW bestätigt, 37 seien „nur ein Bug“ und einer „komplett falsch“. Fehlalarme gab es also in gut 2 Prozent der Fälle. Das Problem ist ein anderes: Die KI kann schlecht unterscheiden, wo ein Bug endet und eine Lücke beginnt. Genau das schrieb Stenberg schon im Oktober. Seit dem Frühjahr seien die Schrott-Meldungen „praktisch verschwunden“, die neue Herausforderung heiße „hohe Menge, hohe Qualität“.

curl hat darauf mit dem Verfahren reagiert. Seit 26. Oktober werden Meldungen niedriger und mittlerer Schwere öffentlich auf GitHub besprochen, damit die Community mitprüfen kann. Und Anthropic fand im Oktober auch eine ernste Lücke: einen Use-after-free-Fehler in HTTP/2-Uploads, eingestuft als HIGH und in curl 8.23.0 behoben. Bei curl ist die Reparatur also nicht steckengeblieben. Stattdessen sichten Freiwillige sehr viele echte, aber wenig dringende Bugs.

Wo die Reparatur mithält: Kernel, Apache, Microsoft

Linux-Kernel. Im Mai nannte Linus Torvalds die Sicherheits-Mailingliste wegen der KI-Meldungen „fast völlig unbeherrschbar“. Der Kernel reagierte mit neuen Regeln: KI-Funde gehen in der Regel direkt und öffentlich an die zuständigen Maintainer, mit knapper Beschreibung und geprüftem Reproduzierer. Im Merge-Window für 7.4 wurden nach Torvalds' Worten zunehmend auch die Patches von KI vorgeschlagen, oft aber umgeschrieben. Am 8. November gab er mit 7.4-rc2 die Einschätzung von BPF-Maintainer Alexei Starovoitov weiter: Dort kämen die Fixes „jetzt schneller als die neuen Meldungen“. Torvalds schränkte ein, die meisten anderen Bereiche seien noch nicht so weit, und mahnte: „Haltet nicht den Atem an.“ Zahlen dazu gibt es nicht. Laut Xenospectrum verweist das zugehörige Merge-Protokoll zudem darauf, dass Fixes für sockmap, einen BPF-Teilbereich, noch ausstehen.

Microsoft MDASH. Microsofts FORGE Lab hat Teile des Kernels mit seinem System MDASH durchsucht. Aus 26.502 Rohfunden wurden 59 öffentliche Meldungen. Jede davon kam mit Patch, wie es im Kernel erwartet wird: KI-Agenten schrieben den ersten Entwurf, Menschen prüften und überarbeiteten ihn. 38 Fixes sind im Hauptzweig, im Median 41 Tage nach dem ersten öffentlichen Patch, höchstens nach 108 Tagen. Der Preis dafür: mehr als vier Personenmonate für 59 Meldungen. Microsoft schreibt selbst, Finden und Beheben seien „drastisch aus dem Gleichgewicht“.

Apache. Anthropics OSS Scanner meldete am 26. Oktober eine kritische Lücke im HTTP/2-Modul des Apache-Webservers (CVE-2026-119618), über die Angreifer Code ausführen können. Am 11. November erschien der Fix in Version 2.4.71, nach 16 Tagen. Laut der Apache-Sicherheitsseite ist es die erste kritische Einstufung seit Oktober 2021. Bemerkenswert ist auch: Zwei Google-Forscher meldeten denselben Fehler am 3. November unabhängig davon. Ob Anthropic einen Patch mitgeliefert hat, steht nirgends. Der OSS Scanner legt laut Socket aber, „wenn vorhanden“, Patch-Vorschläge bei.

SoftBank: wenn der Berg im eigenen Haus liegt

Einen Sonderfall schildert SoftBank-Chef Junichi Miyakawa. Ein OpenAI-Modell fand im Juni 10.500 Lücken in rund 700 eigenen Systemen, alle wurden in etwa drei Monaten geschlossen. Danach fand GPT-6 Astra 35.000 weitere. Hier gehört der Code der Firma selbst, Finden und Patchen laufen weitgehend automatisch. Als Engpass nennt Miyakawa die menschliche Prüfung, ob vernetzte Systeme nach dem Patch noch zusammenarbeiten: „Ehrlich gesagt sind wir völlig erschöpft.“ Angaben zur Schwere der 35.000 Funde machte er nicht.

Unser Fazit

Unsere Einschätzung: Die Schlagzeile „37.966 Funde, 217 Fixes“ beschreibt vor allem eine Messlücke, nicht das ganze Bild. Je nach Zählweise liegt die Quote zwischen 0,6 und 12,4 Prozent. Die richtige Frage ist deshalb, wo die Reparatur hängt. Die Gegenbeispiele haben eines gemeinsam: Wer meldet, liefert geprüfte Arbeit mit, oder die Maintainer haben eigene Kapazität und klare Regeln. So ist es bei Microsofts Kernel-Patches, beim BPF-Team und beim schnellen Apache-Fix. Wo viele ungeprüfte Meldungen ankommen, wandert die Prüfarbeit zu den Projekten. Daran ändert auch nichts, dass die Maintainer diese Meldungen beim OSS Scanner selbst angefordert haben. Das Ergebnis sind curls 37 „Nur-Bugs“ und mehr als 1.600 Duplikate.

Offen bleibt einiges. Die BPF-Wende ist eine Einzelaussage ohne Daten. Anthropics sinkende Meldezahl ist unerklärt. Kein Patch-Zähler sagt etwas darüber, ob Fixes auf echten Rechnern ankommen. Und auch der lauteste Kritiker verdient mit seiner Kritik Geld. Für Nutzer ist die Lehre schlicht: Updates einspielen, denn genau dort entscheidet sich, ob ein KI-Fund am Ende etwas nützt.