Die 500 Zero-Days von Claude Opus 4.6: Was drei Patches zeigen

Am 5. Februar 2026 veröffentlichte das Frontier Red Team von Anthropic Forschungsergebnisse, denen zufolge Claude Opus 4.6, das am selben Tag erschien, mehr als 500 Schwachstellen mit hohem Schweregrad in Open-Source-Software gefunden und validiert hatte – ohne aufgabenspezifische Tools, maßgeschneidertes Scaffolding oder spezialisiertes Prompting. Drei Funde werden ausführlich beschrieben: eine fehlende Stack-Bounds-Prüfung in Ghostscript, eine ungeprüfte Reihe von strcat-Aufrufen in OpenSC und ein Pufferüberlauf im GIF-Encoder CGIF, der davon abhängt, wie sich die LZW-Kompression verhält, wenn ihr Wörterbuch voll ist. Anthropic zufolge sind alle drei inzwischen von ihren Maintainern gepatcht, und laut Anthropics Darstellung wurden die Fehler gefunden, validiert und gemeldet. Viele der Projekte werden von kleinen Teams oder Freiwilligen ohne eigenes Sicherheitspersonal betreut, heißt es in dem Beitrag, sodass die Melde- und Patch-Last bei ihnen lag. Der eigene Eintrag des Archivs zu dem Fund, mit der Schweregradstufe „Info“ und ohne verzeichneten tatsächlichen Schaden, steht im Orca AI Incident Archive neben den anderen Richtlinien- und Offenlegungsunterlagen vom Februar 2026.

Was Anthropic tatsächlich veröffentlicht hat

Der Beitrag trägt den Titel „Evaluating and mitigating the growing risk of LLM-discovered 0-days“ und wird dem Frontier Red Team zugeschrieben: Nicholas Carlini, Keane Lucas und Evyatar Ben Asher als gleichberechtigte Mitwirkende, zusammen mit Newton Cheng, Hasnain Lakhani, David Forsythe und Kyla Guru. Die Seite trägt ein Veröffentlichungsdatum vom 5. Februar 2026 sowie einen Bearbeitungshinweis vom 6. Februar 2026, der festhält, dass die Autorenliste aktualisiert wurde. Das Archiv verweist für den Beitrag auf red.anthropic.com, das inzwischen auf anthropic.com/research/zero-days weiterleitet.

Die Methode ist wichtiger als die Schlagzeilen-Zahl. Anthropic sagt, es habe das Modell in eine virtuelle Maschine gesetzt, mit Zugriff auf die neuesten Versionen von Open-Source-Projekten, und ihm Standardwerkzeuge sowie die Tools gegeben, die ein menschlicher Sicherheitsforscher nutzen würde – Debugger und Fuzzer –, aber keine Anleitung zu deren Verwendung und, mit den Worten des Beitrags, „kein maßgeschneidertes Harness, das ihm Spezialwissen darüber vermittelt hätte, wie man Schwachstellen besser findet“. Getestet wurde das Verhalten des Modells out of the box.

Das Team engte die Suche auf Speicherkorruptionsfehler ein, mit der Begründung, dass ein Absturz leichter zu bestätigen sei als ein Logikfehler. Anthropic stellt ausdrücklich klar, dass dies ein Filter und keine Garantie ist: „Nicht alle Eingaben, die ein Programm zum Absturz bringen, sind Schwachstellen mit hohem Schweregrad.“ Also gingen die Abstürze zurück an das Modell, um sie zu kritisieren, zu deduplizieren und neu zu priorisieren, und dann an Menschen. „Für unsere erste Runde von Befunden validierten unsere eigenen Sicherheitsforscher jede Schwachstelle und schrieben Patches von Hand. Als die Zahl der Befunde wuchs, holten wir externe (menschliche) Sicherheitsforscher hinzu, um bei der Validierung und der Patch-Entwicklung zu helfen.“ Die Patch-Automatisierung, so heißt es in dem Beitrag, befand sich noch im Aufbau.

Drei Bugs und die Patches, die darauf folgten

Die drei durchgerechneten Beispiele haben eine Gemeinsamkeit: Ein automatisiertes Tool war bereits gescheitert, und das Modell fand den Fehler, indem es über etwas anderes als Eingabemutation nachdachte.

• Ghostscript, der PostScript- und PDF-Interpreter. Fuzzing und anschließende manuelle Analyse brachten nichts zutage. Das Modell las dann die Git-Historie des Projekts, fand einen Commit, der im Beitrag als Hinzufügen von „Stack-Bounds-Checking für MM-Blend-Werte“ zu Type-1-Charstrings beschrieben wurde, schloss daraus, dass der Code vor diesem Commit anfällig gewesen war, und suchte nach anderen Aufrufstellen, die nicht dieselbe Behandlung erhalten hatten. Es fand eine in gdevpsfx.c – der Beitrag nennt Zeile 292 – und erstellte eine Datei, die das Programm zum Absturz bringt. Das Repository bestätigt dies: Commit 87486fb801 von Chris Liddell, datiert auf den 5. September 2025, trägt den Titel „Type 1 charstrings: add stack bounds checking for MM blend values“. Ein späterer Fix von Ken Sharp, Commit 4e392a82 datiert auf den 26. Januar 2026, fügt unmittelbar vor diesem Aufruf im Font-Konverter Bounds-Checks hinzu, eingereicht gegen Bug 709080, dessen Bericht den Titel „Ghostscript Incomplete fix for Type 1 MM blend stack bounds check“ trägt. Ein Commit vom 13. Februar 2026 erweiterte Bounds-Checks im selben Konverter. Keine der Commit-Nachrichten sagt, wer den Fehler gemeldet hat.

• OpenSC, ein Kommandozeilenwerkzeug für Smartcard-Daten. Hier suchte das Modell nach riskanten Funktionsaufrufen und fand aufeinanderfolgende strcat-Operationen, die in einen 4096-Byte-filename-Puffer schrieben, nach einer Größenberechnung, die die Länge einer Eingabezeichenkette abzog, dann aber weitere Zeichenketten anhängte, ohne erneut zu prüfen. Der Beitrag merkt an, dass vorhandene Fuzzer diesen Pfad wegen der beteiligten Vorbedingungen selten erreichten. OpenSCs Commit 33ab343a5c vom 19. Januar 2026 fügte eine Prüfung hinzu, dass die angehängte Zeichenkette genau 64 Byte lang ist, und Pull Request #3554, zusammengeführt am 25. Januar 2026, ersetzte die verbleibenden strcat-Aufrufe im gesamten Projekt durch strlcat; sein Autor nannte die Funktion einen „Magnet für sämtliche statischen Analysewerkzeuge und CVEs“.

• CGIF, ein GIF-Encoder. Die Bibliothek ging davon aus, dass komprimierte Daten immer kleiner als die unkomprimierte Eingabe sein würden, was fast immer zutrifft. Das Modell argumentierte, dass LZW ein Wörterbuch fester Größe aufbaut und dass, wenn das Wörterbuch voll ist, in den Stream eingefügte Clear-Codes die „komprimierte“ Ausgabe länger als die Eingabe machen können – sodass ein für N+2 Codes dimensionierter Puffer mehr als N+1 erhalten könnte. Der Beitrag sagt, dass selbst 100 Prozent Zeilen- und Zweigabdeckung dies möglicherweise nicht aufdecken, weil es eine bestimmte Abfolge von Operationen erfordert. CGIFs Pull Request #84, zusammengeführt am 19. Januar 2026 und am selben Tag als v0.5.1 veröffentlicht, behebt genau das: „Die Reset-Clear-Codes fehlten in der Berechnung für die Obergrenze der LZW-Datengröße.“

Diese Korrekturen wurden vor der Veröffentlichung der Untersuchung eingespielt – CGIF und OpenSC am 19. Januar 2026, OpenSC erneut am 25. Januar, Ghostscript am 26. Januar – und Anthropic erklärte in dem Beitrag, man habe „begonnen, sie zu melden, und sehe unsere ersten Patches einfließen“, bevor das Unternehmen an die Öffentlichkeit ging. Die Repositories dokumentieren die Codeänderungen; sie dokumentieren nicht, wer die Meldungen eingereicht hat, daher beruht der Zusammenhang zwischen den Erkenntnissen des Modells und diesen speziellen Commits auf Anthropics Darstellung und darauf, wie genau die beschriebenen Defekte mit den Diffs übereinstimmen.

The researcher who said the OpenSC bug was not real

Public scrutiny of the individual findings did not start and end with Anthropic. On 14 February 2026 K. Reid Wightman, an industrial security researcher posting as @reverseics on infosec.exchange, published a review of the OpenSC example arguing the bug could not be triggered: the input string was already checked to be 64 bytes at line 5138, he wrote, which capped the buffer at 4095 bytes including the terminator. "I spent about an hour looking at the code to debunk their finding," he wrote.

He edited the same post on 17 February 2026 to withdraw the challenge. "Looks like the version of code I was looking at, already had a fix for anthropic-discovered bug(s)," the edit reads, before conceding the arithmetic: "but yes without the strlen() check on 'fp' the overflow could actually be triggered. The humble pie has been eaten." The check he had relied on was the one added to OpenSC on 19 January 2026 — before Anthropic published, and before most readers would have gone looking. The archive does not flag the record as disputed, and here the challenge was retracted by the person who raised it.

OpenSC's own maintainers answered the same question in their tracker. In discussion #3575, opened on 17 February 2026 by a user asking whether Anthropic's claims were legitimate, OpenSC maintainer frankmorgner replied the same day: "We received two bug reports from anthropic, which were both verified by humans." He said the fixes were in pull request #3554 and would be in the next release, and that commit 33ab343 was "a change that was introduced after anthropic reported the problem."

Die Governance-Hälfte: Prüfungen, Blockierung und 90 Tage

Was dies zu einem Grundsatzdokument statt zu einer reinen Forschungsnotiz macht, ist die zweite Hälfte des Beitrags. Neben der Modellveröffentlichung gibt Anthropic an, cyberspezifische Sonden eingeführt zu haben, die Aktivierungen im Modell messen, während es eine Antwort generiert, und dass es seine Durchsetzungs-Workflows aktualisiert hat, um sondenbasierte Erkennung zu verwenden. Es geht über die Erkennung hinaus: „Wir können Echtzeit-Interventionen einleiten, einschließlich der Blockierung von Datenverkehr, den wir als bösartig erkennen.“ Anthropic räumt die Kosten ein – „Dies wird für legitime Forschung und einige defensive Arbeiten Reibung erzeugen“ – und sagt, es wolle mit der Sicherheitsforschungsgemeinschaft daran arbeiten. Weder Erkennungsrate noch Fehlerrate noch Einspruchsverfahren werden veröffentlicht.

Der Beitrag argumentiert außerdem, dass der Offenlegungskalender selbst inzwischen ein Problem darstellt. „Branchenübliche 90-Tage-Fristen könnten der Geschwindigkeit und Menge der von LLMs entdeckten Fehler nicht standhalten“, heißt es, und es wird gewarnt, dass Modelle „bald die Geschwindigkeit und den Umfang selbst erfahrener menschlicher Forscher übertreffen könnten“. Das ist ein Anbieter, der argumentiert, dass die Norm, an der er gemessen wird, ersetzt werden muss, und es ist der Teil der Aufzeichnung mit der größten Reichweite.

Was hat sich danach geändert?

Am 20. Februar 2026 öffnete Anthropic Claude Code Security als begrenzte Forschungsvorschau für Enterprise- und Team-Kunden, mit kostenlosem beschleunigtem Zugang für Open-Source-Maintainer — die Funktion wurde fünfzehn Tage nach der Forschungsphase zum Produkt gemacht. VentureBeat berichtete über den Start und erklärte, man habe Anthropic nach der Falsch-Positiv-Rate vor und nach der Selbstverifizierung gefragt, nach der Anzahl der offengelegten Schwachstellen mit bereits übernommenen Patches gegenüber solchen, die sich noch in der Triage befanden, sowie nach den Schutzvorkehrungen, die Angreifer-Nutzung von Verteidiger-Nutzung unterscheiden; es berichtete, dass der leitende Forscher des Projekts nicht verfügbar war und dass das Unternehmen es ablehnte, konkrete Mechanismen zur Angreifererkennung zu teilen.

Auch die Patches verschoben sich weiter, und nicht immer in eine Richtung. CGIFs Korrektur für die von Anthropic beschriebene Allokation wurde am 19. Januar 2026 in v0.5.1 ausgeliefert; am 21. Februar 2026 behob Pull Request #103 einen 32-Bit-Ganzzahlüberlauf, der durch dieselbe Allokationsberechnung eingeführt worden war, und wurde am nächsten Tag als v0.5.2 für GIFs mit der maximalen Größe von 65.535 × 65.535 Pixeln veröffentlicht. Wie sich zeigt, ist die Reparatur einer Grenzberechnung selbst eine kleine Quelle von Grenzfehlern.

Die Zahl richtig lesen

Anthropics eigener Satz lautet „mehr als 500 Schwachstellen mit hohem Schweregrad“. Axios, das als erstes vom Unternehmen gebrieft wurde, beschrieb sie am Tag der Veröffentlichung als „mehr als 500 zuvor unbekannte Zero-Day-Schwachstellen“, jede davon validiert von einem Mitglied von Anthropics Team oder einem externen Sicherheitsforscher. Beide Beschreibungen verweisen auf dieselbe Gruppe, aber nur eine ist die Formulierung des Anbieters, und keine wird von einer Liste, einer CVE-Zuordnung oder einer Verteilung der Schweregrade begleitet. Die Zahl stammt von Anthropic, die Schweregradbewertungen stammen von Anthropic, und die drei im Beitrag abgearbeiteten Projekte sind die einzigen, die die Öffentlichkeit überprüfen kann.

Die darauf folgende unabhängige Analyse nahm die Zahl überwiegend für bare Münze und stritt darüber, was sie bedeutet. Mitch Ashley von der Futurum Group schrieb am 24. Februar 2026, das Ergebnis „sei weniger wegen der Anzahl als vielmehr wegen dessen von Bedeutung, was die Methode offenlegt“, und die eigentliche Einschränkung liege weiter unten in der Kette: „Mehr Schwachstellen schneller aufzudecken verkleinert die Angriffsfläche nicht. Es schafft eine größere Warteschlange vor einem nachgelagerten Prozess, der das Volumen nicht bewältigen kann.“ Das ist eine Kritik an der Offenlegungs-Pipeline und nicht am Befund, und sie trifft denselben Punkt, den Anthropic im Zusammenhang mit 90-Tage-Zeitfenstern angesprochen hat.

Was sich aus der Akte nicht ergibt

Das Archiv bewertet diesen Eintrag mit Konfidenz A, Schweregrad info, ohne dokumentierten tatsächlichen Schaden und ohne Widerspruchsmarkierung. Diese Bewertung bezieht sich darauf, wie gut das Ereignis dokumentiert ist, nicht darauf, wie gut die zugrunde liegende Behauptung geprüft wurde, und dieser Unterschied sollte festgehalten werden. Niemand außerhalb von Anthropic hat die 500 verifiziert. Es wurde keine Falschpositivrate veröffentlicht. Die Patches für die drei genannten Projekte sind echt und datierbar, und sie sind die stärkste verfügbare Bestätigung – aber sie bestätigen drei Beispiele, nicht die Gesamtzahl.

Was bleibt, ist also eine gut dokumentierte Ankündigung mit einem überprüfbaren Kern und einem nicht überprüfbaren Rest: ein Anbieter, der eine Fähigkeit meldet, drei Upstream-Diffs, die seiner Beschreibung der Fehler entsprechen, und die erklärte Absicht, Missbrauch dieser Fähigkeit auf der Modellebene zu unterbinden. Das Archiv legt sie als Policy ab, was das richtige Regal ist. Die Behauptung über die Fähigkeit wird von demjenigen geklärt werden, der den vierten Patch veröffentlicht.