Entdeckung und Ausnutzung von Schwachstellen in kritischer, realer Software mit Claude

In den vergangenen Monaten haben wir ein unveröffentlichtes, internes Forschungsmodell verwendet, um kritische Schwachstellen zu finden in einigen der weltweit am weitesten verbreiteten Softwareprodukte, wie etwa Browsern und Betriebssystemen. In diesem Beitrag teilen wir Einzelheiten zu fünf Angriffsketten mit, die zu Remote Code Execution und anderen kritischen Auswirkungen mit kaum bis keiner Nutzerinteraktion führten. Diese Angriffsketten demonstrieren die Fähigkeit des Modells, ausgeklügelte, mehrstufige Exploits sowohl in Open-Source- als auch in proprietärer Software zu erstellen. Schwachstellen in diesen Produkten könnten Milliarden von Nutzern betreffen. Sie gehören auch zu den sicherheitskritischsten Softwareprodukten der Welt, was sie zu einem Gradmesser für die Prüfung der Schwachstellenforschung und Cyber-Fähigkeiten von Modellen macht.

Wir haben jede Schwachstelle dem betroffenen Anbieter im Rahmen unserer koordinierten Schwachstellenoffenlegung gemeldet, die Entwicklern 90 Tage Zeit zum Patchen gibt und weitere 45 Tage, bevor wir Details über das hinaus erörtern, was bereits in einer öffentlichen Empfehlung enthalten ist.

1. Remote Code Execution mit einem Klick in Chrome

Nach anfänglichem Prompting schrieb Claude eine vollständige Exploit-Kette, die es einem Angreifer ermöglichte, beliebigen Code als Nutzer außerhalb der Sandbox des Browsers auszuführen. Unser Proof of Concept startet die Taschenrechner-App aus einem Chrome-Browser mit Standardkonfiguration auf macOS innerhalb von Sekunden nach dem Laden der Seite, ohne jegliche weitere Nutzerinteraktion:

• Claude entdeckte eine Schwachstelle in Chromes JavaScript-Engine, V8, die es einer bösartigen Webseite ermöglichte, den Heap-Speicher von V8 zu beschädigen.
• Claude entdeckte eine zweite Schwachstelle, um aus der Memory-Region-Sandbox von V8 auszubrechen und ASLR zu überwinden. Dieser Schritt lokalisierte Chromes Code im Speicher und nutzte eine Return-Oriented-Programming-Kette (ROP), um die volle Kontrolle über den Renderer-Prozess zu übernehmen.
• Der kompromittierte Renderer war durch Chromes Prozess-Sandbox eingeschränkt. Claude entdeckte daraufhin eine Race Condition in CacheStorage. Der kompromittierte Renderer nutzte die Race Condition, um Speicher außerhalb der Sandbox zu lesen und das Speicherlayout des privilegierten Browser-Prozesses zu ermitteln.
• Schließlich entdeckte Claude einen Use-After-Free in FedCM, Chromes föderierter Anmeldefunktion, der es dem Exploit ermöglichte, beliebigen Code außerhalb der Sandbox auszuführen.

Wir haben unsere Ergebnisse an Google gemeldet: 62 CVEs wurden zugewiesen und standen bis Chrome 156 als Patches bereit, wobei alle als kritisch oder hoch eingestuft wurden. Darunter befinden sich 13 Sandbox-Escapes und 21 Schwachstellen, die zur Kompromittierung des Renderers hätten verwendet werden können.

2. Eine Exploit-Kette mit einem Klick in Safari

Nach anfänglichem Prompting schrieb Claude eine Exploit-Kette, die es dem JavaScript jeder Website ermöglichte, die Same-Origin-Policy (SOP) vollständig zu umgehen. Der Exploit konnte auf den Safari-Verlauf, Cookies und andere sensible Daten eines Nutzers zugreifen und authentifizierte HTTP-Anfragen an andere Domänen senden und die Antworten lesen. Ist der Nutzer beispielsweise in sein E-Mail-Konto eingeloggt, kann der Angreifer nun seine E-Mails lesen; ist er in sein Bankkonto eingeloggt, kann der Angreifer Kontostände einsehen oder Überweisungen versuchen.

Um dies zu erreichen, überwand Claude mehrere in Safari eingebaute Schutzebenen:

• Claude entdeckte eine Use-After-Free-Schwachstelle (UAF) in JavaScriptCore, Safaris in C++ geschriebener JavaScript-Engine. Bestimmte TypedArray-Operationen schrieben über veraltete Zeiger auf freigegebenen Speicher und überschrieben TypedArray-Metadaten.
• WebKits Gigacage mildert diese Art von Angriff ab, indem TypedArray-Daten in einem separaten Speicherbereich isoliert werden. Claude entdeckte, dass bestimmte Variablen in diesem Bereich verwendet wurden, um in andere Bereiche zu indizieren, was ihm ein Arbitrary-Read/Write-Primitive außerhalb des Gigacage verschaffte.
• Das JavaScript aller Websites läuft in der WebContent-Sandbox, die Bugs wie den UAF davon abhält, sensible Browserdaten auf der Festplatte zu erreichen. Claude entdeckte eine Schwachstelle im IPC-Mechanismus der Sandbox, die es dem Exploit ermöglichte, Safaris gespeicherten Verlauf, Cookies und Sitzungsdatenbanken von der Festplatte zu lesen.
• Schließlich nutzte Claude den UAF, um eine Variable im Speicher zu überschreiben und die SOP zu deaktivieren, sodass die Seite des Angreifers Daten von jedem beliebigen Origin lesen konnte.

Die Kette ist interessant, weil sie ein rein datenbasierter Angriff ist, der sich nie auf beliebige Codeausführung verlässt. Stattdessen nutzt sie vollen Lese-/Schreibzugriff auf den Speicher des Browser-Prozesses, um ein Sicherheitsflag, eine Objektgröße und eine URL zu verändern. Mehrere der Schwächen sind für sich genommen keine Schwachstellen, sondern beabsichtigte Verhaltensweisen, die erst in Kombination ausnutzbar werden.

Apple bestätigte unseren Bericht am selben Tag, an dem wir ihn eingereicht haben, und implementierte umgehend eine Korrektur. Diese Korrektur steht den Nutzern zur Verfügung.

3. Umgehung des Android-Sperrbildschirms

Nach anfänglichem Prompting schrieb Claude einen Exploit, der es einem Angreifer ermöglichte, Fotos und andere persönliche Informationen von einem gestohlenen Android-Telefon zu extrahieren, ohne es zu entsperren. Die Arbeit kombinierte drei Methoden: Quellcodeanalyse der Open-Source-Teile von Android, Reverse Engineering und Deobfuskierung der Google Play services-Binärdateien sowie Live-Tests auf einem physischen Google Pixel 9. Dabei wurde eine Vielzahl von Schwachstellen sowohl in den Open-Source- als auch in den proprietären Komponenten aufgedeckt. Claude verknüpfte dann drei davon zum finalen Exploit.

Android hat mehrere Schutzebenen gegen diesen Angriff. Claude fand einen Weg, jede einzelne zu umgehen:

• Ein gesperrtes Android-Telefon ist so konzipiert, dass es keine Daten über USB überträgt. Claude fand heraus, dass ein USB-Host mit einer bestimmten Einstellung dies umging.
• Das Geräte-zu-Gerät-Übertragungsprotokoll lehnt Datenbefehle von nicht autorisierten Teilnehmern ab. Claude fand einen Weg, die Autorisierungsprüfung zu überspringen und den Kopplungsprozess zu starten.
• Die Kopplung ist durch eine authentifizierte Schlüsselvereinbarung geschützt, bei der der Benutzer einen sechsstelligen Code verifizieren muss. Claude fand eine Schwachstelle, die diese Verifizierung übersprang und sich so verhielt, als hätte der Benutzer „Zulassen“ angetippt.
• USB-Übertragungen sollen eigentlich keine Dateiinhalte tragen, was durch eine fest einprogrammierte Prüfung durchgesetzt wird. Claude fand einen Fallback-Mechanismus, der rohe Bytes über USB sendete und nicht von dieser Prüfung abgedeckt war. Der Exploit forderte über ihn Dateiinhalte an.

Dieses Problem wurde von Google behoben.

4. Remote-Denial-of-Service unter Windows

Nach anfänglichem Prompting schrieb Claude einen Exploit, der es einem Angreifer ermöglicht hätte, jede Windows-Maschine, die auf HTTP/3-Anfragen antwortet, über die native Windows-Implementierung remote zum Absturz zu bringen. Die Schwierigkeit bestand in diesem Fall zunächst darin, die Schwachstelle überhaupt zu identifizieren. Nach dem anfänglichen Prompting meldeten wir diese Schwachstelle direkt an Microsoft, das die Schwachstelle behob und ihr zuordnete CVE-2026-33096.

Die von Claude identifizierte Schwachstelle war ein Out-of-bounds-Lesezugriff mit Speichersicherheitsproblem in der QUIC-Implementierung des Windows-Kernels. Ein Angreifer konnte den verwundbaren Codepfad remote über das Netzwerk erreichen und einige Datenpakete an einen lauschenden Server senden, um die Maschine abstürzen zu lassen und neu zu starten. Durch wiederholtes Senden dieser Anfragen ist es möglich, den Server kontinuierlich abstürzen zu lassen, was für alle Benutzer den Verlust des Zugriffs auf den Server zur Folge hat. Wir schätzen, dass es im Internet wahrscheinlich mehrere Millionen solcher lauschenden Server gibt.

Claude entdeckte diese Schwachstelle durch Binäranalyse. Wir gaben dem Modell eine Kopie der Windows-Executable und baten Claude, mit den vorhandenen Reverse-Engineering-Werkzeugen (wie Ghidra) herauszufinden, wie die Software funktioniert, ein vollständig kommentiertes C-Programm zu schreiben, das die relevanten Funktionen reproduziert, das Verhalten des reproduzierten Programms mit der Binärdatei zu vergleichen, um die Korrektheit sicherzustellen, und dann den Code auf Schwachstellen zu untersuchen. Als wir Claude baten, potenziell riskantere Probleme zu identifizieren, brachte es diese remote ausnutzbare Schwachstelle ans Licht.

5. Zero-Click-Remote-Code-Ausführung unter Linux

Während sich dieser Beitrag auf Produkte von Drittanbietern konzentriert, hat unsere Arbeit an Open Source weiter angehalten. Mit Claude entdeckten wir lokale Rechteausweitungen auf OpenBSD, FreeBSD und Linux; eine Reihe von Sandbox-Escapes in beliebter Sandbox-Infrastruktur; und zahlreiche Schwachstellen in wichtigen Webanwendungen. Wir haben auch remote auslösbare (Zero-Click-)Schwachstellen zur willkürlichen Codeausführung im Netzwerk-Stack des Linux-Kernels gefunden, die inzwischen upstream gepatcht und öffentlich offengelegt wurden. Ein solches Beispiel erläutern wir im Folgenden.

Nach anfänglichem Prompting schrieb Claude einen Exploit, der es einem remote Angreifer ermöglicht, Pakete an Linux-Server mit einem Multipath-TCP-Listener zu senden, um beliebige Befehle als root auszuführen, ohne jegliche Zugangsdaten oder Benutzerinteraktion. Die zugrunde liegende Schwachstelle ist ein durch eine Race Condition verursachter UAF-Bug im Kernel-Netzwerk-Stack. Die vollständige Ausnutzung hat zwei entscheidende Phasen:

• In der ersten Phase besiegt der Angreifer KASLR remote. Er nutzt die Race Condition aus, um den Kernel ein vom Angreifer kontrolliertes Längenfeld lesen zu lassen, zusätzliche Bytes zu kopieren und diese an den Angreifer zurückzusenden; solange ein solcher Überlesevorgang einen Kernel-Pointer in der Antwort enthält, erfährt der Angreifer das Kernel-Adressraum-Layout.
• In der zweiten Phase kapert der Angreifer den Kontrollfluss. Er nutzt denselben UAF-Bug aus, um einen Buffer zu überfluten und einen Callback-Pointer mit der Adresse einer Payload zu überschreiben, die der Angreifer bereits über eine gewöhnliche Protokollfunktion im Kernel-Speicher platziert hat. Wenn der Kernel den Callback aufruft, verkettet die Payload eine Reihe von Aufrufen vorhandener Kernel-Funktionen und endet damit, dass ein vom Angreifer gewählter Shell-Befehl als root ausgeführt wird.

Eine erleichternde Eigenschaft dieser Race Condition ist, dass eine verlorene Race nur den Handshake scheitern lässt, ohne das ganze System abstürzen zu lassen, sodass ein entschlossener Angreifer unbegrenzt wiederholen kann, bis er Erfolg hat. In unserem Proof of Concept dauert es 48 Minuten, um einen Kernel-Pointer zu leaken, und weitere fünf Minuten, um bis zur Ausführung des Shell-Befehls zu gelangen. Diese Schwachstelle (CVE-2026-98432) wurde upstream gepatcht und auf alle gepflegten stabilen Kernel-Zweige zurückportiert.

Was wir gelernt haben

Während unseres gesamten Prozesses der Nutzung von Claude für diese Sicherheitsarbeit identifizierten wir eine Reihe von Erkenntnissen, die unseren Ansatz prägten. Wir denken, dass zwei davon besonders wichtig sind.

Scaling des Rechenbudgets zur Testzeit und Scanner-Diversität erhöhen erheblich, wie viele Schwachstellen man findet. Wir bauten eine Plattform, die große Zahlen von Scanning-Agents parallel ausführt, jeden Scanner danach misst, wie viele zusätzliche Schwachstellen er zur Mischung beiträgt, und die Abdeckung dynamisch verfolgt, damit die Scanner die gesamte Codebasis bearbeiten.

Die Strategien reichen von reiner Abdeckung (gibt es eine Schwachstelle in dieser Funktion?) über zielbasierte Ansätze (legt diese Anwendung etwas offen, das Kundendaten gefährden könnte?) bis zu bedrohungsmodellbasierten Ansätzen (umgeht etwas in dieser Anwendung ihr dokumentiertes Bedrohungsmodell?). Wir haben Claude außerdem genutzt, um automatisierte Variantenanalyse für jeden bestätigten Fund durchzuführen. Alle Erkenntnisse durchlaufen eine standardisierte Pipeline zur Verifizierung und Risikobewertung, sodass wir frei mit neuen Scannern experimentieren können, ohne die Qualitätsanforderungen zu senken.

Die Beseitigung des bestehenden Rückstaus löst nur die halbe Aufgabe; die andere Hälfte besteht darin, die Rate zu senken, mit der neue Schwachstellen in die Codebasis gelangen. Dafür empfehlen wir das Scannen zum Zeitpunkt von Pull Requests. Wir haben Sicherheitsleitlinien direkt durch ein Claude-Code-Plugin in unseren Entwicklungsprozess integriert, das wir öffentlich veröffentlicht haben.

Was das für Verteidiger bedeutet

Grenzmodelle haben die Fähigkeit, mehrere Schwachstellen zu entdecken und zu einem funktionierenden Exploit zu kombinieren. Diese Fähigkeiten waren historisch das Domäne weniger spezialisierter Teams mit Expertise zu diesen Zielen. Jetzt ist es etwas, das Modelle mit geringer menschlicher Beteiligung tun können und dann durch die Erstellung eines funktionierenden Exploits belegen, den jeder ausführen und überprüfen kann.

Die Ausstattung von Verteidigern mit leistungsfähigen Modellen ist entscheidend, um ihnen einen Vorsprung bei der Patchung von Systemen vor den Angreifern zu verschaffen. Kürzlich haben wir eine erweiterte Version unseres Cyber Verification Programveröffentlicht, das qualifizierten Sicherheitsexperten fortgeschrittene Cyber-Fähigkeiten und reduzierte blockierende Klassifikatoren zur Verfügung stellt. Es umfasst den Zugang zu unseren leistungsfähigsten Modellen, darunter Claude Opus 5.5, Claude Sonnet 5.5, Claude Mythos 5.1 und weitere neue Modelle in Zukunft. Unser Rat an Verteidiger bleibt derselbe: Das Scannen des eigenen Codes ist wichtiger denn je.

Autoren & Danksagungen

Mitwirkende

Nicholas Carlini, David Dworken, Xinyang Ge, Ben Morris, Milad Nasr, Chris Rohlf, Luna Tong