Eine funktionierende Exploit-Kette gegen einen Browser oder einen Kernel zu bauen, dauert normalerweise Monate. Daran arbeiten wenige Spezialteams, die genau dieses Ziel kennen. Der Bericht beschreibt einen anderen Fall. Ein internes, nicht veröffentlichtes KI-Modell hat in wenigen Monaten fünf komplette Angriffsketten gegen Chrome, Safari, Android, Windows und den Linux-Kernel gebaut – jeweils bis zum lauffähigen Exploit. Die betroffene Software läuft auf Milliarden Geräten.
Neu ist nicht, dass ein Modell eine verdächtige Codezeile markiert. Neu ist, dass es mehrere Schwachstellen zu einer Kette verbindet, die tatsächlich Rechte übernimmt: nachvollziehbar, reproduzierbar, mit einem Proof of Concept, den jeder starten kann. Damit verschiebt sich etwas in der Cyber-Sicherheit. Im Folgenden geht es darum, was gefunden wurde, wie die Ketten funktionieren und was daraus für Verteidiger folgt.
Sicherheit ist selten eine einzelne Mauer. Eher ist sie eine Abfolge von Türen. Ein Browser hat eine Tür im Skriptmotor, eine zwischen Skriptmotor und Prozess, eine zwischen Prozess und Betriebssystem. Für die Verteidigung reicht es, wenn eine Tür hält. Für den Angriff muss jede aufgehen. Wer eine Exploit-Kette liest, liest deshalb keine einzelne Schwachstelle, sondern eine Einbruchsserie.
Fünf Angriffsketten und ein gemeinsames Muster
Das Team beschreibt fünf Ketten. Ihre Wirkung reicht von „der Taschenrechner startet“ bis „der Server gibt einem fremden Paketsender Root-Rechte“. Alle fünf wurden nach dem Prinzip der koordinierten Offenlegung gemeldet: 90 Tage zum Patchen, weitere 45 Tage, bevor Details über die öffentlichen Sicherheitshinweise hinaus veröffentlicht werden. Die Frist ist kein Formalismus. Sie trennt verantwortungsvolle Meldung von einem offenen Fenster für Angreifer.
Die Ziele sind bewusst gewählt. Chrome, Safari, Android, Windows und der Linux-Kernel gehören zu den am häufigsten angegriffenen und am gründlichsten geprüften Programmen. Wenn ein Modell ausgerechnet hier findet, was jahrelange manuelle Prüfung übersehen hat, sagt das weniger über die Produkte aus als über die Methode. Der Bericht zeigt damit auch, wie sich Sicherheitslücken in Chrome und Safari finden lassen, ohne dass ein Mensch jede Zeile liest. Die Lücken belegen den Fund. Die Methode erklärt, warum er möglich war.
Chrome: vier Lücken, ein Klick, Code außerhalb der Sandbox
Die erste Kette beginnt mit einem präparierten Seitenaufruf. Sie endet damit, dass der Taschenrechner des Systems startet – aus einem unveränderten Chrome unter macOS, wenige Sekunden nach dem Laden der Seite, ohne weitere Interaktion. Dazwischen liegen vier Türen, die nacheinander aufgehen mussten. Zuerst eine Speicherkorruption im JavaScript-Motor V8. Sie versetzt eine bösartige Seite überhaupt erst in die Lage, den Heap zu manipulieren.
Dann eine zweite Lücke, um aus dem Speicherbereich der V8-Sandbox auszubrechen und die Adressrandomisierung ASLR zu überwinden. Das Modell setzte dafür eine Return-Oriented-Programming-Kette ein, also eine Abfolge bereits vorhandener Codefragmente im Speicher, und übernahm so die Kontrolle über den Renderer-Prozess. An dieser Stelle greift normalerweise die dritte Tür: die Prozess-Sandbox von Chrome. Sie soll verhindern, dass ein kompromittierter Renderer an sensible Daten gelangt.
Das Modell fand eine Race Condition in CacheStorage. Über sie konnte der kompromittierte Renderer Speicher außerhalb der Sandbox lesen und das Speicherlayout des privilegierten Browser-Prozesses lernen. Die vierte Tür war eine Use-after-Free-Lücke in FedCM, Chromes Funktion für föderierte Anmeldungen. Damit lief der Code außerhalb der Sandbox. Google hat die Meldung bestätigt. Bis Chrome 156 wurden 62 CVEs vergeben und gepatcht, alle als kritisch oder hoch eingestuft, darunter 13 Sandbox-Ausbrüche und 21 Lücken, die den Renderer kompromittieren konnten.
Safari: der Angriff, der ohne fremden Code auskommt
Die zweite Kette wirkt technisch unspektakulärer und ist die interessantere. Eine beliebige Webseite kann nach dem Ausnutzen der Kette die Same-Origin-Policy vollständig umgehen. Diese Regel verhindert, dass eine Seite die Daten einer anderen liest. Konkret: Ist jemand im Mailkonto angemeldet, liest die Angreiferseite die Mails. Ist jemand bei seiner Bank eingeloggt, sieht sie Kontostände. Authentifizierte Anfragen an andere Domains samt Antwort sind ebenfalls möglich.
Der Weg dorthin führt über eine Use-after-Free-Lücke in JavaScriptCore. Sie beschreibt über bestimmte TypedArray-Operationen veraltete Zeiger und überschreibt so die Metadaten der Arrays. WebKit versucht, genau das mit der Gigacage zu verhindern, indem es die Daten dieser Arrays in einen eigenen Speicherbereich verbannt. Das Modell fand Variablen in diesem Bereich, die als Index in andere Bereiche dienten – und damit einen Lese- und Schreibzugriff außerhalb der Gigacage. Der Rest der Kette löst zwei weitere Türen: die IPC-Schnittstelle der WebContent-Sandbox, über die sich Verlauf, Cookies und Sitzungsdatenbanken auslesen ließen, und am Ende eine Variable im Speicher, die die Same-Origin-Policy abschaltet.
Die Kette ist ein reiner Datenangriff. Sie braucht zu keinem Zeitpunkt eigenen Code im Prozess. Der volle Lese- und Schreibzugriff auf den Speicher des Browser-Prozesses genügt, um eine Sicherheitsmarke, eine Objektgröße und eine URL zu ändern. Mehrere Bausteine sind einzeln betrachtet keine Schwachstellen, sondern gewolltes Verhalten. Erst in Kombination werden sie gefährlich. Apple hat die Meldung am selben Tag bestätigt und zügig einen Fix bereitgestellt.
Android, Windows und Linux: wenn das System selbst die Tür offen lässt
Beim Android-Beispiel wird es physischer. Das Team beschreibt einen Weg, aus einem gestohlenen Pixel 9 Fotos und persönliche Daten zu ziehen, ohne den Sperrbildschirm zu überwinden – genau das, was bei einem Diebstahl geschützt sein soll. Die Vorgehensweise kombinierte Quellcodeanalyse der offenen Android-Teile, Reverse Engineering und Deobfuskation der Google-Play-Dienste sowie Praxistests auf echter Hardware. Drei Lücken wurden daraus zu einer Kette verbunden.
Jede der drei betrifft eine andere Schutzschicht. Ein gesperrtes Telefon soll keine Daten über USB übertragen. Ein USB-Host mit einer bestimmten Einstellung kam trotzdem durch. Das Übertragungsprotokoll lehnt Befehle nicht autorisierter Gegenstellen ab. Ein Weg am Autorisierungsschritt vorbei startete die Kopplung dennoch. Diese Kopplung ist durch eine Schlüsselvereinbarung mit sechsstelliger Nutzerbestätigung geschützt. Eine Lücke ließ die Prüfung ausfallen, als hätte jemand auf „Zulassen“ getippt. Ein abschließender Rückfallmechanismus, der rohe Bytes über USB schickte, war von der Prüfung auf Dateiinhalte nicht erfasst. Google hat das Problem behoben.
Auf Windows lag die Schwierigkeit nicht im Exploit, sondern im Finden. Das Modell arbeitete sich über Binäranalyse durch die ausführbare Datei, rekonstruierte die relevanten Funktionen in einem kommentierten C-Programm, verglich dessen Verhalten mit dem Original und suchte dann im nachgebauten Code nach Schwachstellen. Gefunden wurde ein Auslesefehler außerhalb der Puffergrenzen in der QUIC-Implementierung des Windows-Kernels, erreichbar über HTTP/3 aus dem Netz. Wenige Pakete an einen lauschenden Server genügen, um ihn abstürzen zu lassen. Wiederholt man das, fällt der Dienst dauerhaft aus. Das Team schätzt, dass mehrere Millionen solcher Server im Internet erreichbar sind. Microsoft hat die Lücke als CVE-2026-33096 behoben.
Der Linux-Fund ist der schwerwiegendste: ein Zero-Click-Remote-Code-Execution-Exploit, der ohne Zugangsdaten und ohne Interaktion auskommt. Über einen Multipath-TCP-Listener im Kernel ließ sich eine Race Condition ausnutzen, die zu einer Use-after-Free-Lücke führt. Zuerst wird KASLR über einen gezielten Überlesevorgang ausgehebelt. Der Kernel nutzt dabei eine vom Angreifer kontrollierte Längenangabe und schickt zusätzliche Bytes zurück. Enthält die Antwort einen Kernelzeiger, ist das Speicherlayout bekannt. Dann wird der Kontrollfluss gekapert, ein Puffer überlaufen und ein Callback-Zeiger auf eine bereits im Kernelspeicher abgelegte Nutzlast gesetzt. In der Praxis dauerte es 48 Minuten bis zum geleakten Zeiger und weitere fünf bis zum Shell-Befehl als Root. Eine verlorene Race lässt nur die Aushandlung scheitern; das System stürzt nicht ab. Ein Angreifer kann es beliebig oft wiederholen. Die Lücke CVE-2026-98432 ist gepatcht und in alle gepflegten Kernel-Zweige zurückportiert.
Warum viele Scanner mehr finden als ein perfekter Scanner
Aus dem Vorgehen lassen sich zwei Lehren ziehen, die über den konkreten Anlass hinausgehen. Die erste betrifft Rechenzeit: Skalierung während der Laufzeit erhöht die Trefferzahl erheblich. Das Team baute eine Plattform, die sehr viele Scan-Agenten parallel laufen lässt. Jeder Agent wird danach bewertet, wie viele zusätzliche Funde er beisteuert. Die Abdeckung wird dynamisch nachgeführt, bis der gesamte Codebestand bearbeitet ist. Die Strategien reichen von reiner Abdeckung über zielgerichtete Fragen bis zu Bedrohungsmodellen, also der Frage, ob eine Anwendung etwas tut, das ihr dokumentiertes Bedrohungsmodell verletzt.
Die zweite Lehre ist weniger offensichtlich: Vielfalt schlägt Perfektion. Ein einzelner, noch so guter Scanner findet, was er finden kann, und übersieht systematisch den Rest. Viele unterschiedlich gebaute Scanner mit unterschiedlichen Fragestellungen finden mehr, gerade weil sie unterschiedlich blind sind. Die Schwachstellenforschung mit Claude folgte dabei keinem einzelnen Trick, sondern diesem Muster: Jeder bestätigte Fund läuft zusätzlich durch eine automatisierte Variantenanalyse und eine standardisierte Prüf- und Bewertungsstrecke. So lassen sich neue Scanner experimentell einsetzen, ohne die Qualität zu senken.
Für den laufenden Betrieb ergibt sich daraus eine unbequeme Konsequenz: Den bestehenden Rückstand abzuarbeiten löst nur die Hälfte des Problems. Die andere Hälfte ist, die Rate zu senken, mit der neue Lücken überhaupt in den Code gelangen. Wer seinen Code erst bei der Release-Prüfung scannt, arbeitet an der falschen Stelle. Das Team empfiehlt deshalb Scans zum Zeitpunkt des Pull Requests und hat die Sicherheitshinweise als Plugin direkt in den Entwicklungsprozess gelegt.
Was das für Verteidiger bedeutet
Die Botschaft ist unbequem und nüchtern: Frontier-Modelle sind inzwischen in der Lage, mehrere Schwachstellen zu einer funktionierenden Kette zu verbinden – und das Ergebnis als lauffähigen Exploit zu beweisen, den jeder ausführen kann. Diese Fähigkeit war bisher der Engpass weniger Spezialteams mit tiefem Wissen über genau diese Ziele. Fällt dieser Engpass, verschiebt sich das Gleichgewicht zwischen Angriff und Verteidigung, und zwar schneller, als die üblichen Patch-Zyklen es vorsehen.
Die naheliegende, aber falsche Reaktion wäre Resignation. Wer die Fähigkeiten selbst einsetzt, um den eigenen Code zu prüfen, gewinnt Zeit. In der Software-Sicherheit zählt vor allem Zeit. Das Team hinter dem Bericht hat dafür ein erweitertes Programm aufgelegt, das qualifizierten Sicherheitsfachleuten Zugang zu den leistungsfähigsten Modellen gibt. Der Rat an Verteidiger bleibt derselbe wie vor allen Modellen: den eigenen Code scannen, bevor es jemand anderes tut.
Eine Exploit-Kette ist keine magische Waffe. Sie ist eine Serie von Nachlässigkeiten, die einzeln harmlos wirken und zusammen ein Gebäude öffnen. KI-gestützte Schwachstellenanalyse macht solche Serien sichtbar – schneller, breiter und systematischer, als ein einzelnes Team es könnte. Deshalb gehört sie auf die Seite der Verteidigung, bevor sie auf der anderen auftaucht.
Quelle: anthropic.com
