Anthropic berichtet von fünf mit Claude entdeckten Exploit-Ketten und kritischen Schwachstellen

Fünf Untersuchungen, kein unabhängiges Audit

Anthropic hat einen Bericht über den Einsatz eines internen, noch nicht veröffentlichten Forschungsmodells bei der Suche nach Schwachstellen in weit verbreiteter Software veröffentlicht. Das Unternehmen beschreibt fünf Exploit-Ketten: eine in Chrome, eine in Safari, eine Umgehung der Android-Sperre, eine aus der Ferne auslösbare Dienstverweigerung unter Windows und die Ausführung von Befehlen aus der Ferne unter Linux. Das sind Aussagen von Anthropic über die eigene Arbeit, keine Ergebnisse, die durch die verfügbaren Unterlagen unabhängig bestätigt wurden.

Der Bericht enthält technische Einzelheiten und besagt, dass die Schwachstellen den jeweiligen Anbietern gemeldet wurden. Anthropic zufolge wurden die beschriebenen Fehler behoben. Wie viele Details öffentlich vorliegen, unterscheidet sich jedoch von Fall zu Fall; die Veröffentlichung belegt nicht, dass Dritte jede Exploit-Kette nachgestellt haben. Außerdem war das verwendete Modell intern und nicht öffentlich verfügbar. Die Ergebnisse zeigen daher nicht, dass beliebige Nutzer dieselben Fähigkeiten mit einem öffentlich zugänglichen Modell erzielen können.

Wichtig ist die Unterscheidung zwischen dem Finden eines Fehlers, dem Erstellen eines Proof of Concept und dem Nachweis einer Auswirkung unter einer bestimmten Konfiguration. Der Bericht nennt Beispiele für alle drei Schritte. Anthropics Darstellung ist aber keine externe Bewertung der Erfolgsquote, des erforderlichen Aufwands oder der Übertragbarkeit auf andere Produkte. Sie reicht auch nicht aus, um dem Modell allein die gesamte Analyse, Auswahl und Überprüfung zuzuschreiben, die zu einer Sicherheitsuntersuchung gehören.

Chrome und Safari: Exploit-Ketten aus mehreren Fehlern

Für Chrome beschreibt Anthropic eine Kette, die mit einem Speicherfehler in V8, der JavaScript-Engine, begann. Dem Bericht zufolge wurden weitere Schwachstellen genutzt, um Speichergrenzen und die Isolation des Browsers zu überwinden und schließlich Code außerhalb der Sandbox auszuführen. In der von Anthropic genannten Demonstration öffnete sich auf einem Mac mit Chrome-Standardeinstellungen die Rechner-App. Dieses Beispiel veranschaulicht die behauptete Auswirkung unter einer bestimmten Konfiguration; es belegt nicht, dass alle Installationen oder Versionen verwundbar waren.

Laut Veröffentlichung vergab Google 62 CVE-Kennungen für die Funde; bis zum Stand des Berichts seien sie in Chrome 156 behoben gewesen. Anthropic bezeichnet die Schwachstellen als kritisch oder hoch eingestuft. Das Unternehmen zählt darunter 13 Sandbox-Ausbrüche und 21 Fehler, die eine Kompromittierung des Renderer-Prozesses ermöglicht haben könnten. Diese Zahlen beziehen sich auf Anthropics Angaben. Sie sind nicht als 62 voneinander unabhängige, vollständige Exploit-Ketten zu verstehen.

Für Safari beschreibt der Bericht einen anderen Angriff: Ziel war es, die Same-Origin-Policy zu umgehen, die normalerweise verhindert, dass eine Website Daten anderer Websites ausliest. Anthropic schildert eine Kombination aus einem Use-after-free in JavaScriptCore, Lese- und Schreibzugriff außerhalb eines geschützten Speicherbereichs und einer Schwachstelle im IPC-Mechanismus der Sandbox. Die Kette soll den Zugriff auf lokale Browserdaten ermöglicht und eine Sicherheitsvariable verändert haben, um die Same-Origin-Policy auszuschalten. Laut Unternehmen war dafür keine beliebige Codeausführung nötig; der Angriff kombinierte Speicherzugriff mit Änderungen am Systemzustand.

Der Fall zeigt, weshalb ein einzelner Fehler das Gesamtrisiko nicht immer erklärt. Einige der beschriebenen Bedingungen waren dem Bericht zufolge vorgesehenes Verhalten, wurden aber in Kombination mit anderen Schwachstellen ausnutzbar. Anthropic gibt an, Apple habe den Bericht am selben Tag bestätigt und eine Korrektur bereitgestellt. Eine externe Bewertung, mit der sich die Zahl möglicherweise betroffener Nutzer oder das tatsächliche Ausmaß einer Ausnutzung bestimmen ließe, enthält die Veröffentlichung nicht.

Android, Windows und Linux: drei Ziele, drei Arten von Auswirkungen

Für Android beschreibt Anthropic eine Umgehung der Sperre, mit der sich angeblich Fotos und andere persönliche Informationen von einem gesperrten Pixel 9 auslesen ließen. Die Untersuchung kombinierte die Analyse von Open-Source-Komponenten, Reverse Engineering von Google-Play-Diensten und Tests auf einem physischen Gerät. Die beschriebene Kette umging mehrere Schutzmaßnahmen: USB-Übertragung, Kopplungsautorisierung, die Überprüfung eines Codes und eine Kontrolle für Dateiübertragungen. Laut Veröffentlichung hat Google das Problem behoben. Der vorliegende Berichtsauszug enthält keine vollständige Liste betroffener Versionen oder Geräte.

Unter Windows wurde eine speicherbedingte, außerhalb der Grenzen liegende Leseoperation in der QUIC-Implementierung des Kernels gefunden. Anthropic zufolge hätte ein Angreifer aus der Ferne einige Pakete an einen Server senden können, der HTTP/3-Anfragen entgegennimmt, und dadurch einen Absturz mit anschließendem Neustart auslösen können. Das Unternehmen gibt an, Microsoft habe den Fehler behoben und ihm die Kennung CVE-2026-33096 zugewiesen. Die beschriebene Untersuchung basierte auf der Analyse einer ausführbaren Datei und Reverse-Engineering-Werkzeugen. Als Auswirkung wird eine Dienstverweigerung genannt, nicht die Übernahme des Systems aus der Ferne.

Für Linux berichtet Anthropic von einem Use-after-free infolge einer Race Condition im Netzwerk-Stack des Kernels auf Systemen mit einem MPTCP-Listener. Die behauptete Exploit-Kette bestand aus zwei Schritten: Zunächst wurde eine Kernel-Adresse offengelegt, danach der Kontrollfluss verändert, um einen Befehl mit Administratorrechten auszuführen. Anthropic zufolge erhielt die Schwachstelle die Kennung CVE-2026-98432, wurde im Projekt behoben und in die gepflegten stabilen Kernel-Zweige zurückportiert. Das Unternehmen schätzt, dass sein Proof of Concept etwa 48 Minuten benötigte, um eine Kernel-Adresse offenzulegen, und weitere fünf Minuten bis zur Befehlsausführung. Diese Zeitangaben beschreiben die konkrete Demonstration und sind keine allgemeine Leistungsgarantie.

Die drei Beispiele sind nicht gleichzusetzen: Der Windows-Fall betrifft eine Unterbrechung des Dienstes aus der Ferne; die Beispiele für Chrome und Linux beschreiben unter den genannten Bedingungen die Ausführung von Code oder Befehlen. Bei Android geht es um den Zugriff auf Daten, ohne das Gerät zu entsperren. Für die Risikobewertung zählen Produkt, Version, Konfiguration und installierte Korrekturen – nicht allein die Schweregrad-Einstufung.

Die Methode: viele Scanner und anschließende Überprüfung

Anthropic führt einen Teil der Ergebnisse auf eine Plattform zurück, die zahlreiche Analyseagenten parallel ausführt. Das Unternehmen erklärt, es messe den zusätzlichen Beitrag jedes Scanners und verfolge die Codeabdeckung. Zu den beschriebenen Strategien gehören die Suche nach Schwachstellen in einzelnen Funktionen, zielorientierte Prüfungen – etwa danach, ob Kundendaten offengelegt werden könnten – und die Frage, ob eine Anwendung ihr dokumentiertes Bedrohungsmodell verletzt.

Der Bericht erwähnt außerdem eine automatisierte Variantenanalyse: Nach der Bestätigung eines Fundes wird nach ähnlichen Fällen gesucht. Anthropic zufolge durchlaufen die Ergebnisse einen standardisierten Prozess zur Überprüfung und Risikoeinstufung. Das ist relevant, denn eine Hypothese über einen Fehler belegt noch nicht, dass er reproduzierbar oder ausnutzbar ist. Die Veröffentlichung legt jedoch weder alle Kriterien für die Aufnahme eines Fundes im Detail offen noch nennt sie die Zahl falsch positiver Ergebnisse oder einen kontrollierten Vergleich mit menschlichen Teams und anderen Werkzeugen.

Als Empfehlung für Entwickler schlägt Anthropic vor, Sicherheitsanalysen in die Prüfung von Codeänderungen zu integrieren und zugleich bereits bekannte Schwachstellen zu beheben. Dahinter steht ein präventiver Ansatz: Werden neue Änderungen geprüft, können Fehler möglicherweise erkannt werden, bevor sie in die Codebasis gelangen. Eine Empfehlung oder automatisierte Analyse garantiert jedoch weder, dass alle Fehler gefunden werden, noch dass die resultierende Software frei von Schwachstellen ist. Die Wirksamkeit hängt vom Umfang der Prüfung, dem verfügbaren Kontext, der menschlichen Überprüfung und der Reaktion des Teams ab.

Die Veröffentlichung hebt außerdem die Skalierung des Rechenaufwands während der Tests und die Vielfalt der Scanner hervor. Nach Angaben des Unternehmens erhöhten diese methodischen und technischen Entscheidungen in seinem Verfahren die Zahl der gefundenen Schwachstellen. Daraus folgt nicht, dass mehr Rechenressourcen immer bessere Ergebnisse liefern oder ein Modell ohne Überprüfung korrekte Funde erzeugt. Die Betonung der Verifikation macht deutlich, dass Erkennung und Bestätigung zwei unterschiedliche Schritte sind.

Was der Bericht für Verteidiger bedeutet – und was er nicht belegt

Für Sicherheitsteams ist das wichtigste Ergebnis, dass ein Modell laut Anthropic mehrere Fehler in komplexen Produkten verknüpfen und Proofs of Concept mit unterschiedlichen Auswirkungen erstellen konnte. Automatisierte Forschung könnte die Möglichkeit erweitern, Code zu prüfen und Varianten schneller zu analysieren. Dieselben Fähigkeiten können jedoch auch offensiv genutzt werden. Die Funde unterstreichen deshalb die Bedeutung von Patch-Management, begrenzter Angriffsfläche und autorisierten Sicherheitstests.

Anthropic vertritt die Auffassung, dass Fähigkeiten, die bisher vor allem spezialisierten Teams vorbehalten waren, nun mit geringem menschlichem Eingriff durch Modelle verfügbar werden könnten. Das ist eine Interpretation des Unternehmens auf Grundlage seiner Experimente. Der Bericht enthält keinen unabhängigen Vergleich, der beziffert, wie viel menschliche Arbeit nötig war oder wie viel schneller der Prozess im Vergleich zu üblichen Methoden ablief. Ebenso lässt sich daraus nicht ableiten, dass unerfahrene Angreifer die fünf Ketten ohne Weiteres nachstellen können.

Bei dem beschriebenen Modell handelt es sich laut Dokument um ein internes, noch nicht veröffentlichtes Forschungssystem. Die Ergebnisse lassen sich daher nicht automatisch auf öffentliche Claude-Versionen übertragen; sie belegen auch nicht, dass eine zugängliche Benutzeroberfläche dasselbe Verhalten ermöglicht. Verfügbarkeit von Werkzeugen, Rechenzeit, Ausgangsinformationen, Sicherheitsbeschränkungen und menschliche Aufsicht können das Ergebnis erheblich beeinflussen.

Besondere Vorsicht ist beim Vergleich dieser Veröffentlichung mit anderen Sicherheitsvorfällen geboten. Anthropics Bericht über Schwachstellen in Produkten Dritter bestätigt nicht, dass ein externes Unternehmen in die internen Systeme von Anthropic eingedrungen ist, und liefert keine Daten zu einem vermeintlichen Angriff von Cathedral. Das sind unterschiedliche Sachverhalte. Auf Grundlage der hier verfügbaren Informationen gibt es keine ausreichende Basis für Aussagen darüber, wer auf welche Systeme zugegriffen, wie lange der Zugriff gedauert oder welche Daten dabei erlangt haben soll.

Für Organisationen, die Software betreiben, lautet die praktische Schlussfolgerung nicht, darauf zu vertrauen, dass ein Modell alle Fehler findet. Sinnvoll sind ein aktuelles Anlagenverzeichnis, die Installation von Updates, die Prüfung exponierter Komponenten und die Validierung von Funden in einer autorisierten Umgebung. Automatisierte Werkzeuge können die Arbeit unterstützen; Zugriffskontrollen, menschliche Prüfung und koordinierte Offenlegungsverfahren bleiben jedoch nötig. Der Bericht enthält konkrete Beispiele für Risiken und gemeldete Korrekturen, ist aber weder eine Sicherheitsgarantie noch ein universeller Nachweis von Fähigkeiten.

Welchen praktischen Wert die Funde haben

Die technischen Details sind nützlich, weil sie unterschiedliche Auswirkungen voneinander abgrenzen und zeigen, wie mehrere Fehler einander verstärken können. Bei einer defensiven Prüfung kann eine Exploit-Kette wichtiger sein als ein isolierter Fehler, wenn sie beispielsweise eine Speicherschwachstelle mit einem Weg über eine Sicherheitsgrenze verbindet. Die Priorisierung sollte sich dennoch an der tatsächlichen Exposition, den eingesetzten Versionen, verfügbaren Patches und möglichen Gegenmaßnahmen orientieren – nicht allein an einer eindrucksvollen Demonstration.

Teams können die veröffentlichten Funde nutzen, um Bestände und Updates der betroffenen Produkte zu prüfen, ohne eine Kette gegen fremde Systeme nachzustellen. Wer eine Schwachstelle untersucht, sollte dies in kontrollierten Laboren, mit Genehmigung und dafür vorbereiteten Versionen tun. Sicherheits-Proofs of Concept können unerwünschte Folgen haben, wenn sie in Produktionsumgebungen oder gegen Infrastruktur Dritter ausgeführt werden.

Die Empfehlung, Prüfungen in den Entwicklungsprozess einzubinden, macht mehrschichtige Schutzmaßnahmen ebenfalls nicht überflüssig. Automatisierte Prüfungen können bekannte Muster erkennen oder verdächtigen Code markieren; menschliche Analyse liefert Kontext und bewertet das Risiko. Keiner der beiden Ansätze garantiert für sich allein eine vollständige Abdeckung. Der Nutzen entsteht durch das Zusammenspiel von Erkennung, Validierung, Behebung und Nachverfolgung.

Zusammengefasst enthält der Bericht detaillierte Angaben dazu, was Anthropic nach eigener Darstellung in einer internen Untersuchung erreicht hat und welche Schritte zur Offenlegung und Behebung das Unternehmen den Anbietern zuschreibt. Das ist ein relevanter Hinweis auf die Entwicklung modellgestützter Sicherheitsforschung. Die Aussagekraft bleibt jedoch begrenzt: Es handelt sich um Ergebnisse eines Unternehmens, für konkrete Systeme und mit einem nicht veröffentlichten Modell; in den verfügbaren Quellen ist keine unabhängige Reproduktion dokumentiert.

Weiter entdecken

Korrekturen und Transparenz

Wenn du falsche oder veraltete Angaben findest, sende uns die Seite und die zu prüfende Quelle.