Pwn2Own zahlt 40.000 $ für Code, der außerhalb der Sandbox eines Coding-Agents läuft. Auf einem Laptop heißt außerhalb der Sandbox: Ihr Konto, Ihre Schlüssel und Ihre Repositories.

Am Dienstag, dem 6. Oktober, um 18 Uhr trat Ikotas Labs in Cork bei Pwn2Own Ireland 2026 mit OpenAI Codex als Ziel an. Der Ergebniseintrag der Zero Day Initiative ist eine Zeile lang: Ikotas „used a single argument injection bug to exploit OpenAI Codex. They win $40,000 and 4 more Master of Pwn points.“ BleepingComputer und Infosecurity Magazine berichteten am nächsten Morgen darüber, zwischen den 32 Zero-Days des ersten Tages.

ZDI veröffentlicht den Bug erst nach 90 Tagen, der Frist, die Pwn2Own den Herstellern für einen Fix gibt. Was der Exploit leisten musste, steht in den Wettbewerbsregeln.

Was ein Sieg bedeutet

Coding-Agents haben bei Pwn2Own eine eigene Kategorie. Die Regeln für Ireland 2026 nennen zwei Ziele, Anthropic Claude Code und OpenAI Codex, mit je 40.000 $, beide unter Windows 11. Die Bedingungen sind streng:

Sandbox- und Isolationsfunktionen sind in ihrer Standardkonfiguration aktiviert, und kein unsicherer Ausführungsmodus (etwa --dangerously-skip-permissions oder ein Äquivalent) ist aktiv.
Der Versuch „muss mit einer vom Teilnehmer kontrollierten Ressource interagieren (z. B. Webseite, Repository, Mediendatei)“, und der Angriff „muss ein gängiger Anwendungsfall eines Coding-Agents sein“.
Er muss beliebige Codeausführung jenseits der „vorgesehenen Sandbox- und Berechtigungsgrenzen“ des Agents erreichen oder sensible Informationen abrufen, die „aus der Sandbox der Anwendung normalerweise unzugänglich“ sind.

Die Regeln nennen drei Ausgangslagen. Der Agent läuft bereits in einem vertrauenswürdigen Ordner, und der Angriff findet innerhalb einer Sitzung statt. Oder der Agent wird im Repository des Teilnehmers gestartet, bevor jemand ihm vertraut hat. Oder eine Desktop-App öffnet das Projekt des Teilnehmers. Das sind die drei Dinge, die ein Entwickler den ganzen Tag tut: arbeiten, etwas Neues klonen, etwas Neues öffnen.

Die Regeln schließen außerdem eine Liste von Dingen aus, die nicht zählen: das Modell dazu überreden, in der Umgebung konfigurierte Zugangsdaten, unsichere Modi, MCP-Server von Drittanbietern. Das Preisgeld zahlt für genau eine Sache: das Brechen der eigenen Grenze des Agents.

Fünf Monate, zwei Wettbewerbe

Ireland ist der zweite Pwn2Own mit Coding-Agents auf der Liste. In Berlin im Mai nutzte Compass Security Codex am ersten Tag mit „a single CWE-150 bug“ aus, für 40.000 $. Doyensec nutzte es am selben Tag mit einem Bug aus, den der Hersteller schon kannte, und am dritten Tag gelang es Satoki Tsuji von Ikotas Labs erneut, über eine External-Control-Schwachstelle, mit Taschenrechnern, die auf dem Zielsystem aufgingen. Security Affairs fasste die drei Codex-Siege zusammen: „Each exploit used a different technique, meaning the attack surface is not a single narrow flaw but something broader.“

Claude Code musste in Berlin drei Exploits einstecken, von Viettel Cyber Security, Compass Security und Out of Bounds. Alle drei waren Kollisionen: Die Bugs funktionierten auf der Bühne, und Anthropic kannte sie bereits. Eine Kollision bringt weniger, weil die Forscher nicht die Ersten waren, aber der Exploit lief trotzdem gegen die Version, die der Wettbewerb installiert hatte.

Dann kam Ireland, fünf Monate später, und Codex fiel erneut durch einen einzigen Bug.

ZDI hat den Bug aus Ireland noch nicht beschrieben, aber Argument Injection ist bei Coding-Agents eine bekannte Klasse. Die Berechtigungsschicht eines Agents genehmigt einen Befehl anhand seines Namens: git, rg, find sind schreibgeschützt und laufen ohne Rückfrage. Der Angreifer liefert die Argumente, über einen Dateinamen, einen Branch-Namen oder einen Konfigurationswert im Repository, und das „schreibgeschützte“ Werkzeug erhält eine Option, die ein Programm ausführt. Gits --upload-pack, ripgreps --pre und finds -exec nehmen alle einen Befehl entgegen. Im Juli meldete Pillar Security, dass die Safe-Command-Liste von Codex git show allein anhand des Namens vertraute, obwohl der Aufruf, den es absetzte, nicht schreibgeschützt war.

Jeder dieser Exploits schlägt eine Prüfung, die im Agent selbst lebt, vom Hersteller des Agents geschrieben und mit dessen Updates ausgeliefert. Die Hersteller patchen jeden einzelnen, und der Wettbewerb findet den nächsten, denn eine Berechtigungsschicht, die Shell-Befehle parst, ist ein großes Ziel, und ein Preisgeld von 40.000 $ hält gute Teams bei der Suche.

Was der Ausbruch auf einem Laptop einbringt

Der Pwn2Own-Sponsor legt fest, welche „sensiblen Informationen“ der Exploit abrufen muss, und die Jury prüft das auf einem sauberen Testrechner. Auf dem Laptop eines Entwicklers muss niemand eine Flagge auswählen. Außerhalb der Sandbox des Agents liegt Ihr Benutzerkonto, und Ihr Konto enthält:

~/.ssh/id_ed25519 und jeden Host in known_hosts
~/.aws/credentials, ~/.config/gcloud, ~/.kube/config
ein gh-Token mit Push-Rechten und .env-Dateien in jedem Checkout
das OAuth-Token des Agents selbst und seinen Sitzungsverlauf
jedes andere Repository auf der Platte und die Browserprofile daneben

Der Wettbewerb schließt außerdem Wege aus, die echte Angreifer jeden Tag nutzen. Eine Prompt Injection, die den Agent zu einem Befehl überredet, zählt nicht. Ein Entwickler, der im --yolo-Modus arbeitet, um die Rückfragen loszuwerden, ebenso wenig. In freier Wildbahn enden all diese Wege am selben Ort wie ein Sandbox-Ausbruch: bei einem Prozess, der als Sie läuft.

Auf einem Laptop ist die Sandbox des Agents die einzige Linie. Ein Ausbruch wie bei Pwn2Own, eine Prompt Injection oder ein unsicherer Modus enden alle am selben Ort: bei einem Prozess mit dem Konto, den Schlüsseln und dem Netzwerk des Entwicklers.

Derselbe Ausbruch in einer Bromure-Maschine

In Bromure Agentic Coding laufen Codex und Claude Code in einer Linux-VM auf Ihrem Mac, eine VM pro Maschine. Die eigene Sandbox des Agents ist weiterhin da und erfüllt weiterhin ihre Aufgabe. Darunter liegt eine zweite Grenze, die weder der Hersteller des Agents geschrieben hat noch das Repository konfigurieren kann: Apples Virtualization.framework, mit dem Host auf der anderen Seite.

Spielen Sie den Exploit von Ikotas Labs in einer Maschine nach. Der Agent öffnet das Repository des Teilnehmers, das Argument erreicht einen Befehl, der es nicht hätte annehmen dürfen, und Code läuft außerhalb der Sandbox von Codex. Er läuft als Benutzer der VM. Von dort sucht er jeden Punkt der Laptop-Liste und findet jeweils die Version der VM.

Die Dateien sind die der Maschine

Die VM hat ihre eigene Systemplatte, einen Copy-on-Write-Klon eines signierten Ubuntu-Images, und ihr eigenes Home-Verzeichnis. Das Home Ihres Macs, Ihr Schlüsselbund, Ihre Browserprofile und Ihre anderen Projekte sind nicht darin. Die einzigen Mac-Ordner, die sie sieht, sind die, die Sie im Bereich Folders mit dieser Maschine geteilt haben, und eine Maschine für fremden Code braucht keinen: Klonen Sie das Repository ins Home der VM.

Die Schlüssel sind Platzhalter

Keine Datei, keine Umgebungsvariable und kein Prozess in der VM enthält einen echten API-Schlüssel, ein OAuth-Token, ein AWS-Secret oder einen privaten SSH-Schlüssel. Die VM hält Fälschungen in der richtigen Form, etwa ANTHROPIC_API_KEY=sk-ant-api03-brm-… oder ein ghp_-Token, das GitHub ablehnen würde. Der Proxy auf dem Mac setzt den echten Wert ein, nachdem eine Anfrage die VM verlassen hat, und nur für den Host, zu dem die Zugangsdaten gehören.

~/.ssh enthält keinen privaten Schlüssel zum Kopieren. SSH_AUTH_SOCK ist eine Brücke über vsock zu einem ssh-agent auf dem Mac, der auf Anfrage signiert und den Schlüssel nie herausgibt. Schalten Sie für einen Schlüssel Ask before use ein, und jede Signatur öffnet einen Dialog auf dem Mac.

Die Platzhalter funktionieren auch als Stolperdrähte. Wenn der Exploit seine Beute bündelt und nach Hause schickt, sieht der Proxy ein gefälschtes Token auf dem Weg zu einem Host, für den es nicht ausgestellt wurde. Er antwortet mit HTTP 451, leitet nichts weiter, pausiert die VM und öffnet auf dem Mac This environment may have been compromised, mit dem Token, dem Host, zu dem es gehört, und dem Host, an den es gesendet wurde.

Der Weg nach draußen führt über den Mac

Jede Verbindung, die die VM öffnet, passiert den virtuellen Switch und den Proxy auf dem Host, unabhängig von Port oder Protokoll. Der Bereich Guardrails der Maschine hat eine Egress-Firewall: Regeln nach Host, IP-Bereich, Protokoll und Port sowie eine Einstellung Unmatched traffic auf Allow oder Deny. Eine Maschine für Code von Fremden kann ihren Modellanbieter, ihre Paket-Registries und GitHub erlauben und den Rest verweigern. Der Ruf des Exploits nach Hause kommt dann nie zustande.

Die Security Timeline zeichnet die Urteile der Firewall auf, ob Sie Regeln gesetzt haben oder nicht. Sie ist immer aktiv, für jede Maschine, und eine Verbindung zu einem Host, den das Projekt nie gebraucht hat, erscheint dort neben der Sitzung, die sie aufgebaut hat.

Pushes und Schreibzugriffe warten auf einen Klick

Die schlimmste Beute auf der Laptop-Liste ist das gh-Token, denn Push-Rechte machen aus einer kompromittierten Maschine ein kompromittiertes Paket. Auf neuen Maschinen nutzt jeder geschützte Dienst Prompt before write. Ein git push über HTTPS ist ein Schreibzugriff, also hält der Proxy ihn an, und macOS zeigt Allow write on "github.com" from workspace "…"? mit der Operation, wie sie über die Leitung ging. Dieselbe Richtlinie gilt für Cloud-APIs, Kubernetes, Registries und Datenbanken. Der Dialog wird auf dem Mac aus dem gezeichnet, was der Proxy gelesen hat, sodass der Code in der VM ihn weder beantworten noch seinen Wortlaut ändern kann.

Der Trace bewahrt die Geschichte

Eine Argument Injection beginnt mit einem Tool-Aufruf, der nach Routine aussieht. Auf der Standard-Trace-Stufe, AI request details, speichert der Proxy jeden Austausch mit dem Modellanbieter verschlüsselt auf dem Mac, und der Trace Inspector zerlegt jeden in Tool-Aufrufe, Shell-Befehle und Dateilesungen. Wenn ZDI den Bug im Januar veröffentlicht, können Sie Ihre Traces nach dem Befehl und dem Argument durchsuchen, die ihn ausgelöst haben, und die Aufzeichnung, die Sie durchsuchen, wurde auf dem Mac geschrieben, außer Reichweite von allem, was in der VM lief.

Die Bereinigung betrifft eine Maschine

Hat der Exploit etwas ins Home-Verzeichnis geschrieben, setzt Rewind home… es auf den Checkpoint eines früheren Starts zurück. Eine Maschine, die der Kompromittierungsdetektor markiert hat, startet erst wieder, wenn Sie Wipe and Launch wählen, das Platte und Home neu aufbaut und Ihre Einstellungen sowie die echten Zugangsdaten auf dem Mac behält. Für Code, den Sie sich nur einmal ansehen wollen, startet bromure-cli vm run --rm eine Maschine, die beim Stoppen gelöscht wird, samt Platte.

Derselbe Ausbruch in einer Bromure-Maschine. Die Sandbox des Agents bricht weiterhin, aber der Code landet in einer VM mit eigenem Home, Platzhalter-Zugangsdaten und ohne private Schlüssel. Ihre Ausgänge, Schreibdialoge und ihr Trace liegen auf dem Mac.

Egal, welche Tür aufging

Die Pwn2Own-Regeln schließen Prompt Injection, unsichere Modi und gespeicherte Zugangsdaten aus, damit ein Sieg genau eines misst: die eigene Grenze des Agents. Für einen Wettbewerb ist das der richtige Test. Angreifer auf Ihrem Laptop nutzen alle drei ausgeschlossenen Wege.

Die VM-Grenze hängt nicht davon ab, wie der Code aus dem Agent herausgekommen ist. Ein Argument-Injection-Bug, ein vergiftetes README, das das Modell zu einem Befehl überredet, eine Testdatei, die ein Implantat herunterlädt, ein Entwickler, der um 2 Uhr nachts die Rückfragen abgeschaltet hat: Jeder Weg endet mit Code, der als Benutzer der VM läuft, vor denselben Platzhaltern, derselben Firewall und denselben Dialogen auf dem Mac. OpenAI wird den Fix für den Ireland-Bug nach eigenem Zeitplan ausliefern, und bis dahin läuft der Bug wie die anderen gegen die VM-Grenze.

Der Ausbruch landet in einer VM

Code, der aus der Sandbox des Agents entkommt, läuft als Benutzer der VM, mit dem Home dieser Maschine und den Ordnern, die Sie mit ihr geteilt haben. Das Home Ihres Macs, Ihr Schlüsselbund und Ihre anderen Projekte sind nicht darin.

Die Schlüssel sind Platzhalter

Echte API-Schlüssel, Git-Tokens und Cloud-Secrets bleiben verschlüsselt auf dem Mac, und SSH-Schlüssel signieren über eine Brücke. Ein Platzhalter außerhalb seines Bereichs bekommt eine 451 und pausiert die Maschine.

Pushes brauchen einen Klick auf dem Mac

Mit Prompt before write, dem Standard auf neuen Maschinen, wartet ein git push oder ein destruktiver Cloud-Aufruf auf einen macOS-Dialog, den die VM nicht beantworten kann.

Die Aufzeichnung bleibt auf dem Host

Egress-Firewall, Security Timeline und Trace laufen alle auf dem Mac. Wenn der Bug veröffentlicht wird, liegt der Verlauf jeder Sitzung zum Durchsuchen bereit.

Rechnen Sie mit dem nächsten

Pwn2Own findet im Frühjahr wieder statt, und Coding-Agents werden wieder auf der Liste stehen, denn ein Coding-Agent führt Befehle auf dem Rechner eines Entwicklers aus, mit der Reichweite dieses Entwicklers. Irgendein Team wird einen Bug mitbringen, den noch niemand gesehen hat. Die Hersteller werden ihn innerhalb von 90 Tagen patchen, und der nächste Wettbewerb beginnt die Zählung von vorn.

Halten Sie Ihre Agents aktuell, und lassen Sie sie in einer Maschine laufen, in der die Beute hinter der Sandbox des Agents eine VM mit Platzhalter-Schlüsseln ist. Mehr dazu, warum diese Grenze auf dem Host liegt, lesen Sie in Der Wächter und die Shell waren sich uneinig und Elf Tests bestanden.