Ein unveröffentlichtes Forschungsmodell von Anthropic hat Schwachstellen in Chrome, Safari, Android, Windows und Linux gefunden und daraus fünf funktionierende Exploit-Ketten gebaut. Die Versuche fanden im Labor statt. Reale Angriffe wurden nicht beobachtet, und die betroffenen Hersteller erhielten die Meldungen vor der Veröffentlichung. Nach Angaben von Anthropic sind sämtliche verwendeten Schwachstellen inzwischen behoben.
Die praktisch wichtigste Einschränkung lautet deshalb: Es gibt funktionierende Proofs of Concept, aber keinen Beleg für aktive Ausnutzung. Aus den veröffentlichten Angaben geht auch nicht hervor, dass der Exploitcode frei verfügbar ist. Für Betreiber entscheidet derzeit vor allem der Patchstand – und bei Windows, Linux und Android zusätzlich die konkrete Konfiguration oder der physische Zugriff auf das Gerät.
Bemerkenswert ist weniger eine einzelne Schwachstelle als die Kombination mehrerer Fehler. Anthropic zufolge benötigte das Modell nach der anfänglichen Aufgabenstellung nur wenig menschliche Hilfe. Wie viel davon tatsächlich autonom geschah, lässt sich jedoch nicht unabhängig prüfen: Das Unternehmen nennt weder das Modell noch die menschlichen Eingriffe in den einzelnen Arbeitsschritten.
Fünf Plattformen, aber fünf sehr unterschiedliche Risiken
Die Chrome-Kette hatte die niedrigste Hürde für einen entfernten Angriff. Eine präparierte Webseite konnte auf einem regulären Mac mit Chrome Code außerhalb der Browser-Sandbox ausführen. In der Demonstration öffnete sich wenige Sekunden nach dem Laden der Seite die Taschenrechner-App, ohne einen weiteren Klick. Die Kette wurde mit Chrome 156 vom 20. Oktober 2026 geschlossen.
Die vier Schritte der Chrome-Exploit-Kette
Die Grafik zeigt, wie vier getrennte Schwachstellen von einer Speicherbeschädigung in V8 bis zur Codeausführung außerhalb der Chrome-Sandbox verkettet wurden.
Bei Safari führte die Kette nicht zur Ausführung nativen Codes. Stattdessen manipulierte sie den Browser so, dass die Same-Origin-Policy ausgeschaltet wurde. Eine bösartige Webseite konnte dadurch Daten anderer Webseiten lesen, auf denen der Nutzer angemeldet war, und authentifizierte Anfragen auslösen. Apple behob die zentrale Use-after-free-Schwachstelle mit iOS und iPadOS 26.5.2 vom 29. Juni 2026.
Der Android-Angriff setzte dagegen physischen Zugriff und eine USB-Verbindung voraus. Das Szenario war ein gesperrtes, gestohlenes Telefon, von dem Fotos und andere Daten kopiert werden. Anthropic zufolge hat Google den Fehler behoben; ein öffentlich nachvollziehbarer Sicherheitseintrag wurde dafür jedoch nicht gefunden.
Unter Windows genügte eine kleine Zahl präparierter Netzwerkpakete, um einen Server zum Absturz zu bringen. Wiederholte Pakete konnten ihn außer Betrieb halten. Voraussetzung war, dass der Server HTTP/3-Anfragen beantwortete. Die als CVE-2026-33096 geführte Schwachstelle hat einen CVSS-Wert von 7,5 und wurde im April 2026 gepatcht. Sie erlaubt nach den vorliegenden Angaben weder Codeausführung noch Datendiebstahl.
Die Linux-Kette hatte die schwerwiegendste technische Folge: Befehle ließen sich ohne Anmeldung über das Netzwerk als Root ausführen. Dafür musste der Server allerdings einen Multipath-TCP-Listener betreiben. Die zugeordnete Schwachstelle CVE-2026-98432 ist mit 9,8 bewertet und wurde am 15. Oktober 2026 im Upstream-Kernel behoben.
Chrome fiel nicht durch einen Fehler, sondern durch vier
Die Chrome-Demonstration zeigt, warum das Verketten von Schwachstellen die entscheidende Fähigkeit ist. Zunächst beschädigte die Webseite Speicher in V8, der JavaScript-Engine des Browsers. Ein zweiter Fehler durchbrach die V8-Sandbox und verschaffte Kontrolle über den Renderer-Prozess.
Danach nutzte die Kette eine Race Condition in CacheStorage, um unzulässig Speicher zu lesen und die Anordnung des privilegierteren Browser-Prozesses zu ermitteln. Den letzten Schritt bildete ein Use-after-free-Fehler in FedCM, Chromes Komponente für föderierte Anmeldungen. Erst dieser vierte Baustein ermöglichte Codeausführung außerhalb der Browser-Sandbox.
Anthropic gibt an, Google insgesamt 62 als kritisch oder hoch eingestufte Chrome-Schwachstellen gemeldet zu haben, darunter 13 Sandbox-Ausbrüche. Sie seien mit CVEs versehen und spätestens in Chrome 156 behoben worden. Googles Versionshinweise nennen Xinyang Ge von Anthropic, unterstützt durch Claude, als Finder bestimmter Fehler. Die Herstellerangaben bestätigen damit einzelne Funde, nicht automatisch jede Zahl aus Anthropics Bericht.
Bei Windows und Linux bleibt die Zuordnung teilweise offen
Für die Windows-Lücke existiert eine unabhängige CVE-Spur, sie stimmt aber nicht vollständig mit Anthropics Beschreibung überein. Das Unternehmen spricht von einem Out-of-bounds-Read in der QUIC-Verarbeitung des Windows-Kernels. Der öffentliche Eintrag für CVE-2026-33096 nennt dagegen HTTP.sys, den integrierten Web-Request-Handler von Windows. Ein Finder ist dort nicht eingetragen.
Ende Oktober war die Schwachstelle von US-Behörden nicht als ausgenutzt markiert und stand nicht im CISA-Katalog der nachweislich angegriffenen Sicherheitslücken. Anthropics Urheberschaft und die genaue Verbindung zwischen beiden Komponenten beruhen daher auf der Darstellung des Unternehmens.
Eine ähnliche Unschärfe besteht bei Linux. Anthropic ordnet seine Multipath-TCP-Kette CVE-2026-98432 zu. Der öffentliche CVE-Eintrag beschreibt jedoch eine Use-after-free-Lücke in IPv4-TCP. Laut Anthropic benötigte das Proof of Concept 48 Minuten, um eine Kernel-Adresse zu ermitteln und KASLR zu umgehen, sowie weitere fünf Minuten bis zur Root-Shell. Fehlversuche ließen das System demnach nicht abstürzen und konnten wiederholt werden.
Die unmittelbare Aufgabe bleibt nüchtern: Patchstand und Exposition prüfen
Für Nutzer von Chrome bedeutet die Meldung vor allem, mindestens Chrome 156 einzusetzen und den tatsächlich laufenden Versionsstand zu kontrollieren. Auf betroffenen Apple-Mobilgeräten ist iOS beziehungsweise iPadOS 26.5.2 die relevante Untergrenze. Android-Geräte sollten auf dem aktuellen Sicherheitsstand des jeweiligen Herstellers sein; wegen des fehlenden öffentlichen Eintrags lässt sich dort keine belastbare Mindestversion nennen.
Windows-Betreiber sollten die April-Updates zu CVE-2026-33096 eingespielt haben und prüfen, welche Systeme HTTP/3-Anfragen aus dem Netz annehmen. Bei Linux reicht die CVE-Nummer allein für die Bestandsaufnahme nicht aus: Distributionen übernehmen Kernel-Fixes zu unterschiedlichen Zeitpunkten. Betreiber müssen deshalb die Hinweise ihrer Distribution heranziehen und insbesondere Systeme priorisieren, auf denen Multipath TCP tatsächlich als Netzwerkdienst erreichbar ist.
Der operative Unterschied zwischen den fünf Fällen ist groß. Die Chrome- und Safari-Ketten begannen mit einer Webseite. Android erforderte den Besitz des Geräts. Windows setzte HTTP/3 voraus, Linux einen vergleichsweise speziellen Multipath-TCP-Listener. Eine gemeinsame Warnstufe für alle Plattformen wäre deshalb irreführend.
KI verkürzt möglicherweise nicht das Patchen, sondern die Vorwarnzeit
Anthropic stellt die Arbeit als defensives Red Teaming dar und verweist auf koordinierte Offenlegung. Das Unternehmen hat zudem sein Cyber Verification Program erweitert, über das überprüfte Sicherheitsfachleute Zugang zu Claude Opus 5.5, Sonnet 5.5 und Mythos 5.1 erhalten sollen.
Die weitergehende Bedeutung liegt nicht darin, dass ungepatchte Systeme plötzlich automatisch kompromittiert wären. Die belastbare Aussage ist enger: Ein internes Modell konnte mehrere Fehler finden, technisch kombinieren und mit ausführbaren Proofs of Concept belegen. Sollte sich diese Fähigkeit außerhalb eines kontrollierten Labors reproduzieren lassen, wird die Zeit zwischen Schwachstellenfund und funktionierender Exploit-Kette kürzer.
Damit verschiebt sich der Engpass auf die Prozesse, die nach dem Fund beginnen: Meldungen prüfen, Fehler mehreren Komponenten zuordnen, Fixes entwickeln, Updates verteilen und ihren Einsatz im Bestand kontrollieren. Genau dort zeigen die abweichenden Beschreibungen bei Windows und Linux die operative Schwierigkeit. Ein KI-Modell kann eine Kette liefern; Hersteller und Betreiber müssen trotzdem klären, welche Komponente betroffen ist, welcher Patch tatsächlich schützt und welche Systeme die notwendige Angriffsvoraussetzung erfüllen.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
