Vier Fehler, eine Seite, ein paar Sekunden. Für solche Exploit-Ketten brauchte es früher ein Spezialistenteam, heute baut ein Modell eine. Der Browser, den Ihr Coding-Agent steuert, ist ihnen auf jeder Seite ausgesetzt, die er öffnet.

Am 27. Oktober veröffentlichte das Frontier Red Team von Anthropic einen Bericht über fünf Exploit-Ketten, die ein unveröffentlichtes internes Forschungsmodell „nach einem ersten Prompt“ gefunden und gebaut hat. Eine Exploit-Kette verknüpft mehrere Fehler so, dass jeder den Angriff an einer Abwehr vorbeibringt, die der vorige nicht überwinden konnte. Ziele waren Chrome, Safari, Android, Windows und Linux. Anthropic meldete alle fünf im Rahmen einer koordinierten Offenlegung an die Hersteller, und The Hacker News, das gestern über den Bericht schrieb, hält fest, dass keine davon in einem echten Angriff beobachtet wurde.

Anthropics Fazit passt in eine Zeile: „Frontier-Modelle sind in der Lage, mehrere Schwachstellen zu entdecken und zu einem funktionierenden Exploit zu kombinieren.“

Eine Seite, vier Fehler

Die Chrome-Kette verdient einen genauen Blick. Ihr Proof of Concept startete den Rechner aus einem Chrome in Standardkonfiguration auf macOS, „innerhalb von Sekunden nach dem Laden der Seite“. Der Rechner ist der klassische Beweis: Wenn ein Exploit eine App auf Ihrem Mac starten kann, kann er alles andere auch starten.

Es brauchte vier Fehler:

Ein Fehler in V8, der JavaScript-Engine von Chrome, ließ die Seite den Speicher der Engine beschädigen.
Ein zweiter V8-Fehler brach aus der eigenen Speicher-Sandbox von V8 aus und gab dem Angreifer die Kontrolle über den Renderer, den Prozess, der die Seite zeichnet.
Eine Race Condition in CacheStorage ließ diesen Renderer Speicher außerhalb seiner Sandbox lesen und den höher privilegierten Browserprozess kartieren.
Ein Use-after-free in FedCM, der föderierten Anmeldefunktion von Chrome, führte den Code des Angreifers ganz außerhalb der Sandbox aus.

Die Sandbox von Chrome geht davon aus, dass der Renderer irgendwann fällt, und hält den Schaden in ihm fest. Die Schritte drei und vier heben das auf. Anthropic gibt an, 62 Chrome-Fehler gemeldet zu haben, die CVEs erhielten und mit Chrome 156 behoben waren, alle als kritisch oder hoch eingestuft, darunter 13 Sandbox-Ausbrüche und 21 Fehler, die den Renderer kompromittieren.

Die Safari-Kette führt nie Code aus. Sie verschafft sich Lese- und Schreibzugriff auf den Speicher des Browsers und ändert einen einzigen Wert, um die Same-Origin-Policy abzuschalten, die Regel, die eine Website daran hindert, eine andere zu lesen. Ohne diese Regel konnte jede Seite Verlauf, Cookies und Sitzungsdaten von Safari lesen und angemeldete Anfragen an andere Websites schicken. Apple hat den Fehler in iOS und iPadOS 26.5.2 behoben.

Die Linux-Kette erreichte über das Netzwerk eine Root-Shell, ohne Login, auf jedem Rechner mit einem Multipath-TCP-Listener. Das Leaken einer Kernel-Adresse dauerte etwa 48 Minuten, die Shell fünf weitere. Der Fehler, CVE-2026-98432, wurde am 15. Oktober upstream behoben.

Die Chrome-Kette aus dem Bericht von Anthropic. Eine bösartige Seite beschädigt den Speicher von V8, ein zweiter V8-Fehler übernimmt den Renderer, eine Race Condition in CacheStorage verrät das Speicherlayout des Browserprozesses, und ein Use-after-free in FedCM führt Code außerhalb der Chrome-Sandbox aus. Der Proof of Concept öffnete auf einem unveränderten Mac Sekunden nach dem Laden der Seite den Rechner.

Ihr Agent öffnet mehr Seiten als Sie

Das sind Browserfehler, und ein Coding-Agent gehört inzwischen zu den fleißigsten Browsernutzern auf dem Rechner eines Entwicklers. Er liest Dokumentation, folgt einem Link aus einem Issue, öffnet die Homepage eines Pakets, prüft ein Suchergebnis, lädt die gerade gebaute App, um einen Screenshot zu machen. Browser-MCP-Server und Browser-Erweiterungen haben das zur Routine gemacht: Der Agent steuert ein echtes Chromium, oft dasselbe Chrome-Profil, in dem sich der Entwickler jeden Morgen anmeldet.

Die meisten dieser Seiten hat der Entwickler nie ausgesucht. Ein Link in einem GitHub-Issue, eine URL in einer README, das dritte Suchergebnis zu einer Fehlermeldung: Jede davon kann eine Kette wie die von Anthropic ausliefern, und bei der Chrome-Kette muss der Agent nichts anklicken. Das Laden der Seite führt alle vier Schritte aus.

Auf einem Laptop endet diese Kette im Benutzerkonto des Entwicklers auf dem Mac. Dasselbe Konto enthält ~/.ssh, ~/.aws/credentials, die gh-Anmeldung, die API-Schlüssel des Agenten selbst und jedes ausgecheckte Repository. Tauschen Sie den Rechner gegen ein Skript, und es kopiert all das. Bei der Safari-Kette ist der Inhalt des Browsers selbst die Beute: die Cookies und Sitzungen jeder Website, bei der der Entwickler angemeldet ist, für eine einzige Seite erreichbar.

Dieselbe Seite in Bromure Agentic Coding

Bromure Agentic Coding betreibt Claude Code, Codex, Grok, Kimi und omp in Ubuntu-VMs auf Ihrem Mac. Jede Maschine bekommt außerdem einen eigenen Browser: ein vollständiges Chromium, das sich als Bereich neben dem Chat öffnet und das Sie und der Agent gemeinsam nutzen. Der Agent steuert es über einen eingebauten MCP-Server browser mit 23 Werkzeugen zum Navigieren, Klicken, Lesen des DOM, für Screenshots und zum Lesen von Konsole und Netzwerkprotokoll. Sie müssen nichts konfigurieren.

Der Browser hat eine VM für sich

Dieses Chromium läuft nicht auf Ihrem Mac und auch nicht in der VM des Agenten. Es läuft in einer separaten Sidecar-VM. Die VM des Agenten und die Browser-VM teilen sich ein privates Netzwerk, damit der Browser den Entwicklungsserver laden kann, den der Agent gestartet hat, und mehr teilen sie nicht. Eine Datei, die der Agent schreibt, liegt nicht auf der Festplatte des Browsers. Sogar localhost zeigt im Browser auf die eigene VM des Browsers.

Lassen Sie Anthropics Chrome-Kette gegen diesen Browser laufen. Die Schritte eins bis vier funktionieren wie vorgesehen: Der Renderer fällt, die Sandbox fällt, und der Code des Angreifers läuft als der Browser. Dieser Code steckt nun in einer VM, die ein Chromium enthält und sonst nichts. Es gibt kein ~/.ssh zum Kopieren und kein ~/.aws zum Lesen. Das Repository, die Konfiguration des Agenten und seine Tokens liegen alle in einer anderen VM, und Ihr Mac liegt hinter einer Hypervisor-Grenze. Auch die Browserwerkzeuge des Agenten teilen sich keinen Prozess mit Chromium: Sie erreichen es über einen kleinen Shim, der per vsock mit dem Host spricht. Im Handbuch heißt es: „Eine feindliche Seite kann niemals die Dateien des Agenten oder Ihren Mac berühren.“

Der Browser vergisst

Standardmäßig ist der Browser ein Wegwerfbrowser. Seine Festplatte ist ein Copy-on-Write-Klon eines gemeinsamen Images, der gelöscht wird, wenn der Browser abgebaut wird. Ein ausgeblendeter Browser wird nach etwa zehn Sekunden pausiert und nach fünf Minuten abgebaut, und der nächste startet von einem sauberen Image. Eine Nutzlast, die in der Browser-VM landet, verschwindet mit der VM.

Das gilt auch für die Art von Kette wie bei Safari, die Cookies und Sitzungen liest, statt Code auszuführen. Ein Wegwerfbrowser hat keine Sitzungen von gestern. Er enthält, wobei sich der Agent während dieser Aufgabe angemeldet hat, und nichts aus Ihrem alltäglichen Surfen, denn Ihr Alltagsbrowser ist ein anderes Programm auf einem anderen Rechner.

Braucht ein Projekt eine dauerhafte Anmeldung, behält Stay signed in to websites in den Browser-Einstellungen der Maschine ein Profil auf einer verschlüsselten Festplatte, nur für diese Maschine. Schalten Sie es für die Staging-Site ein, gegen die der Agent testet, und lassen Sie es auf jeder Maschine aus, die auf nicht vertrauenswürdigen Code angesetzt ist.

Dieselbe Kette auf einem Laptop und auf einer Bromure-Maschine. Auf dem Laptop steuert der Agent einen Browser, der als Sie auf dem Mac läuft, sodass Code, der aus der Chrome-Sandbox ausbricht, Ihre Schlüssel, Tokens und Repositorys lesen kann. In Bromure läuft der Browser des Agenten in einer eigenen Wegwerf-Sidecar-VM; ein Ausbruch landet in einer VM, die nur Chromium enthält, getrennt von der VM des Agenten und vom Mac, und die VM wird weggeworfen.

Die VM des Agenten enthält nur Platzhalter

Angenommen, ein Angreifer kommt weiter und erreicht die VM des Agenten auf anderem Weg, etwa über ein bösartiges Paket, das der Agent installiert, weil er den Anweisungen der Seite folgt. Die Schlüssel dort sind Platzhalter. Das GitHub-Token in der Konfiguration von gh und in ~/.git-credentials ist eine Fälschung, die der Proxy auf Ihrem Mac erst auf dem Weg zu github.com gegen das echte austauscht. Ein Platzhalter, der an einen anderen Host geht, wird blockiert, bevor er den Mac verlässt, und die VM pausiert mit einer Warnung, die das Zugangsdatum und sein Ziel nennt.

Jeden Pull Request scannen, auf Ihrem Mac

Anthropic sagt Verteidigern, dass „das Scannen des eigenen Codes wichtiger ist denn je“. Der Bericht fügt hinzu, dass der Scan zum Zeitpunkt des Pull Requests gehört, weil das Abarbeiten des Rückstands „nur die Hälfte des Problems löst“, solange neuer Code hinzukommt.

Bromure Agentic Coding hat das eingebaut. Eine Code-Review-Automation überwacht ein GitHub-Repository mit einem Agenten auf einer Ihrer Maschinen und legt, was sie findet, als Findings ab, über alle Scans hinweg dedupliziert. Eine Überwachung kann drei Arten von Scan ausführen:

Jeden neuen Pull Request, wobei geprüft wird, was der Pull Request ändert.
Jeden neuen Commit auf dem überwachten Branch.
Ein geplantes Review, wöchentlich, der neuen Commits seit dem letzten oder des gesamten Repositorys. Die vollständige Baseline arbeitet sich Verzeichnis für Verzeichnis nach Risiko vor, beginnend mit Request-Handlern, Authentifizierung und Eingabe-Parsing.

Jeder der fünf Agenten kann ihn ausführen. Jedes Review ist an den Commit gebunden, den es abgedeckt hat, und der Agent schließt den Lauf mit findings_done und einer Zusammenfassung ab. Der Scan läuft auf Ihrem Mac, mit den Zugangsdaten der Maschine, in ihrer VM. GitHub wird alle drei Minuten vom Mac aus mit dem Token der Maschine abgefragt, und dieses Token gelangt nie in die VM. Es gibt keine Webhooks und keine offenen Ports.

Ein Pull-Request-Scanner liest nicht vertrauenswürdigen Text, den jemand geschrieben hat, der den Pull Request eröffnet hat, und ein unbeaufsichtigter Reviewer läuft mit übersprungenen Freigabeabfragen. Bromure schickt Titel, Beschreibung, Autor und Kommentare jedes Pull Requests durch eine verpflichtende Prüfung auf Prompt Injection, bevor der Agent sie sieht. Ist das PromptGuard-Modell nicht installiert, werden ereignisgesteuerte Läufe blockiert, statt durchgewinkt zu werden. Das Review selbst läuft in einer VM voller Platzhalter. Stellen Sie die GitHub-Schreibrichtlinie der Maschine in Guardrails auf Read-only, und der Reviewer kann alles lesen, was sein Token erlaubt, während jeder Push und jeder REST-Schreibzugriff auf dem Mac abgelehnt wird. Findings gehen an Bromure, nicht an das Repository.

Der Browser ist eine eigene VM

Das Chromium des Agenten läuft in einer Sidecar-VM. Ein Sandbox-Ausbruch landet neben Chromium, weit weg von Code, Schlüsseln und Ihrem Mac.

Standardmäßig zum Wegwerfen

Die Festplatte des Browsers ist ein Klon, der beim Abbau gelöscht wird. Nutzlasten und Cookies überdauern die Aufgabe nicht.

Dahinter nur Platzhalter

Die VM des Agenten enthält gefälschte Tokens. Die echten bleiben auf dem Mac und werden nur für den Host eingesetzt, zu dem sie gehören.

Reviews bei jedem PR

Code-Review-Automationen scannen jeden Pull Request und Commit, prüfen den PR-Text auf Injection und können schreibgeschützt laufen.

Patchen, scannen und dem Browser einen eigenen Rechner geben

Jeder Fehler im Bericht ist behoben, und der erste Schritt ist der übliche: Aktualisieren Sie Chrome auf Version 156 oder neuer, aktualisieren Sie Apple-Geräte, und patchen Sie Kernel, auf denen Multipath-TCP-Listener laufen. Anthropic hat recht, dass Verteidiger dieselben Modelle brauchen, die Angreifer bald haben werden, zuerst auf den eigenen Code gerichtet.

Der weitergehende Punkt des Berichts betrifft die nächste Runde von Fehlern. Wenn Modelle eine Handvoll Schwachstellen so schnell in eine funktionierende Kette verwandeln können, werden einige dieser Ketten aktiv sein, bevor der Patch erscheint. Ein Coding-Agent, der den ganzen Tag surft, wird irgendwann eine solche Seite laden. In Bromure Agentic Coding lädt diese Seite in einer VM, die dafür gebaut ist, verloren zu gehen, und Ihr Code, Ihre Schlüssel und Ihr Mac sind woanders.

Wie der Bromure-Browser außerhalb von Agentic Coding mit Browser-Zero-Days umgeht, lesen Sie in Warum Browser-Zero-Days nicht verschwinden. Über eine bösartige Anweisung, die einen Agenten über eine heruntergeladene Datei erreichte, lesen Sie Der Download gab die Befehle.