GPT-5.6 Sol half, drei Chrome Bugs in sechs Tagen zu finden, Google zahlte 250.000 Dollar
Der Bug-Chain wurde mit rund 40.000 Dollar an API-Kosten fuer GPT-5.6 Sol aufgedeckt. Google zahlte dafuer eine Bug-Bounty von 250.000 Dollar.
Eine eigens präparierte Webseite, geöffnet in Chrome Beta unter Windows, öffnet den Taschenrechner. Das ist die Demonstration, die XBOW der vollständigen Exploit-Kette beigefügt hat, die es am 13. Oktober veröffentlicht hat: drei Schwachstellen, von dieser Seite bis zur Codeausführung außerhalb der Sandbox von Chrome. Google zahlte dafür 250.000 US-Dollar, was XBOW als "die erste Prämie unter den neuen Regeln für 2026" bezeichnet.
Die Kosten sind die Zahl, die man wiederholen wird. XBOWs Forschungsbericht sagt, das Team habe OpenAIs GPT-5.6 Sol über Codex laufen lassen, und dass "die Rekonstruktion der Nutzung aus den archivierten Codex-Protokollen die sechstägige Kampagne auf rund 40.000 US-Dollar an API-Kosten beziffert" (XBOW). Die Ankündigung schreibt "OpenAIs GPT-5.6 Sol und dessen Vorgängern" über das gesamte Projekt hinweg einen Anteil zu. Die Schätzung des Berichts für dieselbe Aufgabe vor der Zeit der LLMs: "ein Team von vier Personen über rund 6 bis 9 Monate."
XBOW sagt, "alle drei Schwachstellen in unserer Kette seien behoben". Seine Pressemitteilung beziffert die Betroffenheit auf "schätzungsweise eine Milliarde Menschen, die weltweit Chrome unter Windows nutzen", und erklärt, "die Schwachstellen wurden niemals gegen Chrome-Nutzer eingesetzt".
Das Sandbox-Design von Chrome behandelt Code in einem sandboxisierten Prozess als möglicherweise feindlich, daher läuft Webinhalt innerhalb einer Sandbox, und V8 legt zusätzlich eine eigene Sandbox um seinen Heap. Eine vollständige Kette muss jede dieser Wände durchbrechen. Brendan Dolan-Gavitts Bericht listet die drei Etappen auf:
GBHackers' Zusammenfassung listet die Behebungen so auf, wie XBOW sie beschreibt: keine Wiederverwendung veränderlicher HeapNumbers, die Ausgabepuffer von WebP innerhalb der Bitmap-Grenzen halten und die Crashpad-Wiederversuche auf die Länge der ursprünglichen Anfrage begrenzen. Der Bericht verweist auf die Chromium-Issues 547819997, 548509153 und 545820931. XBOWs Pressemitteilung nennt CVE-2026-85045 für die WebP-Schwachstelle und CVE-2026-78952 für die Crashpad-Schwachstelle. Für die V8-Schwachstelle gibt es keine CVE, und keine der drei Veröffentlichungen von XBOW nennt die Chrome-Versionen, die die Behebungen enthalten.
Drei Etappen, drei Wände: V8s Käfig, die Renderer-Sandbox und dann der Crash-Handler außerhalb beider.
Nach XBOWs Darstellung "durchsuchten die Agents Chromes Quellcode, testeten Ideen, bauten Proof-of-Concepts und verfassten die frühesten Entwürfe des Exploits." Die Menschen "legten die Strategie fest, wählten, wo gesucht werden sollte", prüften dann "die Arbeit der Agents und lenkten die Agents um". Der Blog nennt vier Forscher: Brendan Dolan-Gavitt, Andres Luksenberg, Baul Lee und Willem Pinckaers.
Das Setup ist der Teil, der sich lohnt zu übernehmen. Das Team hat nicht einen Agenten von vorne bis hinten nach einem Exploit gefragt. Es führte parallele Kampagnen mit engeren Zielen durch: breite Schwachstellensuche, V8-Memory-Corruption, ein V8-Sandbox-Escape, ein Renderer-Sandbox-Escape und die Integration (Bericht). Jede Etappe hatte eine saubere Schnittstelle und eine Ausweichroute.
Die Ausweichrouten wurden genutzt. Die erste Version der Kette verwendete eine Gin-Schwachstelle für ihren V8-Sandbox-Escape, und diese Schwachstelle war mit einem bereits existierenden Bericht identisch, Issue 542670566. Das Team tauschte sie nach "ein paar sehr stressigen Stunden" gegen den WebP-Escape aus. Eine frühere Kette war bereits gestorben, als ihre letzte Etappe auf eine Schwachstelle traf, die Google Monate zuvor intern selbst gefunden hatte.
Dolan-Gavitt zieht zwei Lehren daraus. "Diese Art von Invariantenverletzungen könnte der Bereich sein, in dem LLMs glänzen", schreibt er, und "man wird mehr Erfolg haben, wenn man seinen Agents hochwertige Beispiele zum Nachahmen gibt." Er schreibt auch: "wir haben durchaus eine Menge unserer eigenen menschlichen Expertise und unseres Urteilsvermögens angewandt." Deshalb würde ich die 40.000 US-Dollar nicht als den Preis lesen, den dieselbe Kette für jeden anderen kosten würde.
Fünf enge Kampagnen laufen parallel, mit Menschen, die Ziele auswählen und die Etappen zusammenführen.
Sechs Tage und rund 40.000 US-Dollar an API-Kosten, gegenüber XBOWs eigener Schätzung von 6 bis 9 Monaten für ein Vier-Personen-Team. Zur Einordnung: CyberInsider weist darauf hin, dass der Exploit-Broker Crowdfense für Desktop-Chrome-Zero-Day-Ketten mit bis zu 1,5 Millionen US-Dollar wirbt. Diese Zahl ist ein beworbenes Maximum; es gibt keinen Bericht darüber, dass hier jemand so viel gezahlt hätte.
Die Ankündigung, die XBOWs CEO Oege de Moor verfasst hat, wagt eine Vorhersage: "wir glauben, dass innerhalb eines Jahres jede der drei Schwachstellen von Agents gefunden werden könnte, die eigenständig arbeiten." Das kommt von einem Unternehmen, das offensive KI-Sicherheit verkauft, also sollte man es entsprechend einordnen.
Es ist nicht die einzige Meldung in dieser Woche. Am 14. Oktober erschien curl 8.23.0 mit Behebungen für 24 CVEs, und AISLE sagt, seine KI-gestützte Prüfung habe 18 davon gefunden (mein früherer Beitrag schlüsselt die Hinweise der Advisory auf). Meine Lesart: Die Lücke zwischen dem Existieren einer Schwachstelle und dem Finden durch jemanden schrumpft, und damit auch der Preis des Findens. Dein Patch-Fenster schrumpft mit.
Starte den Browser neu. Chrome lädt Updates im Hintergrund herunter, und Googles Hilfeseite sagt: "das Update wird beim nächsten Neustart von Chrome angewendet." XBOWs Rat: "wenn die Update-Schaltfläche erscheint, starte jedes Mal neu."
In einer Electron-App geben die Prozess-Dokumente beide Versionen preis:
// In der Konsole deines Electron-Main-Prozesses. log ( ' Chromium ', process. versions. chrome ); console. log ( ' Electron ', process. versions. electron ); Um täglich Pull Requests für diese Pakete zu bekommen, unterstützt Dependabot eine Allow-Liste:
#.github/dependabot.yml version: 2 updates: - package-ecosystem: " npm" directory: " /" schedule: interval: " daily" allow: - dependency-name: " electron" - dependency-name: " playwright" - dependency-name: " puppeteer" allow funktioniert als Whitelist: Dieser Eintrag prüft nur diese drei Pakete, und alle anderen npm-Abhängigkeiten in / erhalten keine Update-PRs mehr davon. Verwende es unverändert nur in einem Repository ohne anderen npm-Eintrag für dieses Verzeichnis. Wenn du bereits einen hast, füge dort kein allow hinzu; stelle stattdessen sein Intervall auf "daily".
Richte die Agents zuerst auf deinen eigenen Code. XBOWs Schlussrat: "nimm an, dass deine Anwendungen ausnutzbar sind, und teste deine eigene Software, bevor es jemand anderes tut." Wenn sechs Tage und rund 40.000 US-Dollar an API-Kosten, dazu ein Expertenteam, bis zu Chrome reichen, sind die Parser und Datei-Handler deines Dienstes eine kleinere Aufgabe.
Menschen haben jede Etappe gesteuert, und die sechs Tage bauten auf früherer Forschung und gescheiterten Einreichungen auf, wie GBHackers anmerkt. Die 40.000 US-Dollar sind XBOWs eigene Rekonstruktion aus seinen Codex-Protokollen; niemand hat sie geprüft. Die Milliarden-Zahl ist XBOWs Schätzung der Betroffenheit: Menschen, die Chrome unter Windows nutzen. Die Demonstration lief auf signiertem Chrome Beta. Keine der drei Veröffentlichungen von XBOW zitiert Google; CyberInsider berichtet, dass Google die Zahlung laut seinem öffentlichen Issue-Verlauf am 31. August genehmigt hat. Ich habe nichts davon selbst nachgestellt.
Wenn ein kleines Team mit Agents das in einer Woche bei einem Browser hinbekommt, was wäre das Erste in deinem eigenen Stack, auf das du sie ansetzen würdest? Schreib es in die Kommentare.
Eine Behebung erreicht deine Nutzer erst, wenn deine eigene Pipeline sie ausliefert. Wenn du einen Browser in eine Electron-App oder einen Headless-Chrome-Dienst einbindest, liegt der Patch-Rhythmus bei dir. Ship It behandelt die Strecke zwischen localhost und Produktion für kleine Teams: Hosting, Deploys, CI/CD, Zahlungen, Auth und Monitoring.
Ich baue außerdem Hermes IDE, eine kostenlose, quelloffen verfügbare App, die Codex, Claude Code und andere CLI-Agents nebeneinander ausführt, jedes in seinem eigenen Terminal und Worktree, auf macOS, Windows und Linux (GitHub).
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
A crafted web page, opened in Chrome Beta on Windows, pops up Calculator. That is the demo XBOW attached to the full exploit chain it published on October 13: three bugs, from that page to code execution outside Chrome's sandbox. Google paid $250,000 for it, which XBOW calls "the first under its 2026 new rules".
The cost is the number people will repeat. XBOW's research write-up says the team ran OpenAI's GPT-5.6 Sol through Codex, and that "reconstructing usage from the archived Codex logs puts the six-day campaign at roughly $40,000 in API charges" ( XBOW ). The announcement credits "OpenAI's GPT-5.6 Sol and its predecessors" across the wider project. The write-up's estimate for the same job before LLMs: "a team of four around 6-9 months."
XBOW says "All three bugs in our chain are fixed". Its news release puts the exposure at "an estimated one billion people running Chrome on Windows globally", and says "the vulnerabilities were never used against Chrome users".
Chrome's sandbox design treats code in a sandboxed process as possibly hostile, so web content runs inside a sandbox, and V8 adds its own sandbox around its heap. A full chain has to get through every wall. Brendan Dolan-Gavitt's write-up lists the three stages:
GBHackers' summary lists the fixes as XBOW describes them: stop reusing mutable HeapNumbers, keep WebP output buffers inside bitmap bounds, and cap Crashpad retries at the original request length. The write-up cites Chromium issues 547819997, 548509153 and 545820931. XBOW's news release lists CVE-2026-85045 for the WebP bug and CVE-2026-78952 for the Crashpad bug. It gives no CVE for the V8 bug, and none of XBOW's three posts names the Chrome versions that carry the fixes.
Three stages, three walls: V8's cage, the renderer sandbox, then the crash handler outside both.
In XBOW's account, the agents "searched Chrome's source code, tested ideas, built proofs of concept, and wrote the earliest drafts of the exploit." The people "set the strategy, chose where to look," then "checked the agents' work, and redirected the agents." The blog names four researchers: Brendan Dolan-Gavitt, Andres Luksenberg, Baul Lee and Willem Pinckaers.
The setup is the part worth copying. The team did not ask one agent for an exploit end to end. It ran parallel campaigns with narrower goals: broad vulnerability search, V8 memory corruption, a V8 sandbox escape, a renderer sandbox escape, and integration ( write-up ). Each stage had a clean interface and a backup route.
The backup routes got used. The first version of the chain used a Gin bug for its V8 sandbox escape, and that bug duplicated an existing report, issue 542670566. The team swapped in the WebP escape after "a very stressful few hours." An earlier chain had already died when its final stage collided with a bug Google had found internally months before.
Dolan-Gavitt draws two lessons. "These kind of invariant violations may be where LLMs shine," he writes, and "you will have more success if you give your agents high-quality examples to follow." He also writes, "we did apply a fair bit of our own human expertise and judgment." So I wouldn't read the $40,000 as what the same chain would cost anyone else.
Five narrow campaigns run in parallel, with people choosing targets and joining the stages.
Six days and about $40,000 in API charges, set against XBOW's own estimate of 6–9 months for a team of four. For scale, CyberInsider notes that the exploit broker Crowdfense advertises up to $1.5 million for desktop Chrome zero-day chains. That figure is an advertised ceiling; nobody is reported to have paid it here.
The announcement, which XBOW's CEO Oege de Moor wrote, makes a prediction: "we believe that within a year, each of the three bugs could be found by agents working on their own." That comes from a company that sells AI offensive security, so weigh it that way.
It is not the only one this week. On October 14, curl 8.23.0 shipped fixes for 24 CVEs, and AISLE says its AI-driven audit found 18 of them ( my earlier post breaks down the advisory credits). My reading: the gap between a bug existing and someone finding it is shrinking, and so is the price of finding it. Your patch window shrinks with it.
Relaunch the browser. Chrome downloads updates in the background, and Google's help page says "the update applies the next time you restart Chrome." XBOW's advice: "when the Update button appears, restart it every time."
In an Electron app, the process docs expose both versions:
// In your Electron main process console. log ( ' Chromium ', process. versions. chrome ); console. log ( ' Electron ', process. versions. electron ); Enter fullscreen mode Exit fullscreen mode To get pull requests for those packages every day, Dependabot supports an allow list:
#.github/dependabot.yml version: 2 updates: - package-ecosystem: " npm" directory: " /" schedule: interval: " daily" allow: - dependency-name: " electron" - dependency-name: " playwright" - dependency-name: " puppeteer" Enter fullscreen mode Exit fullscreen mode allow works as a whitelist: this entry checks only those three packages, and every other npm dependency in / stops getting update PRs from it. Use it as-is only in a repo with no other npm entry for that directory. If you already have one, don't add allow to it; set its interval to "daily" instead.
Point agents at your own code first. XBOW's closing advice: "assume your applications are exploitable and test your own software before someone else does." If six days and about $40,000 in API charges, plus an expert team, can reach Chrome, your service's parsers and file handlers are a smaller job.
People steered every stage, and the six days sat on top of earlier research and failed submissions, as GBHackers points out. The $40,000 is XBOW's own reconstruction from its Codex logs; nobody has audited it. The billion-person figure is XBOW's exposure estimate: people running Chrome on Windows. The demo ran on signed Chrome Beta. None of XBOW's three posts quotes Google; CyberInsider reports that Google approved the payment on August 31, according to its public issue record. I haven't run any of this myself.
If a small team with agents can do this to a browser in a week, what's the first thing in your own stack you'd point them at? Tell me in the comments.
A fix only reaches your users when your own pipeline ships it. If you bundle a browser in an Electron app or a headless-Chrome service, the patch cadence is yours. Ship It covers the stretch between localhost and production for a small team: hosting, deploys, CI/CD, payments, auth and monitoring.
I also build Hermes IDE, a free, source-available app that runs Codex, Claude Code and other CLI agents side by side, each in its own terminal and worktree, on macOS, Windows and Linux ( GitHub ).