Codex Sandbox-Ausbruch: Wenn der Wächter im selben Speicher wohnt

Der Codex Sandbox-Ausbruch ist aus zwei Gründen lehrreich: weil er im strengsten Schutzmodus funktionierte – und weil beide Fehler dieselbe Denkfehler-Familie teilen. Wer KI-Coding-Agenten einsetzt, bekommt hier eine sehr konkrete Antwort auf die Frage, was so eine Sandbox eigentlich wert ist.

Was beim Codex Sandbox-Ausbruch passiert ist

Oren Yomtov von Accomplish AI fand zwei Wege aus der Sandbox von OpenAIs Coding-Agent Codex. Beide wurden am 12. August 2026 gemeldet und laut Accomplish innerhalb von acht Tagen behoben. Accomplish veröffentlichte die Details am 15. September 2026, die breitere Berichterstattung folgte am 20. September.

Heapjack

Die gravierendere Variante trifft Codex Desktop. Beim Installieren trägt es eine Komponente namens node_repl in die globale Datei ~/.codex/config.toml ein – ohne Opt-in und ohne Schalter zum Abstellen. Weil die Konfiguration geteilt wird, erben auch reine CLI-Nutzer dieses Werkzeug.

node_repl betreibt einen einzigen Node.js-Prozess mit zwei JavaScript-Kontexten: einem vertrauenswürdigen mit OpenAIs Code und einem nicht vertrauenswürdigen für den Agenten. Der vertrauenswürdige Kontext weist sich mit einem bei jedem Start neu erzeugten Zufallstoken aus. Das Problem: Beide Kontexte teilen sich einen Speicher-Heap. Der untrusted Code zieht per v8.getHeapSnapshot() einen Abzug, probiert alle Zeichenketten in UUID-Form durch und erkennt am unterschiedlichen Fehlertext, welche die richtige ist. Mit dem Token schreibt er eigene Anfragen auf denselben Kanal zum nicht gesandboxten Elternprozess – und der führt sie aus. Das gelingt im Modus read-only, in dem der Agent eigentlich gar nichts schreiben darf. Praktische Folge: Ein fremdes Repository öffnen und eine Frage zum Code stellen genügt, damit dessen Autor Befehle auf dem eigenen Rechner ausführt.

Overpatch

Der zweite Fehler sitzt in der quelloffenen Codex CLI. Im Modus workspace-write darf der Agent nur im Projektordner schreiben. Das eigene Patch-Werkzeug apply_patch leitet seine Schreibrechte jedoch aus den im Patch genannten Pfaden ab: Wer /tmp nennt, bekommt Schreibrecht bis zur Wurzel. Der funktionierende Exploit kombiniert eine wirkungslose Änderung an /tmp mit einer zweiten, die über einen Symlink eine Zeile an .zshrc anhängt. Das nächste geöffnete Terminal führt sie aus.

Newsletter

Klartext zu KI, Security, Crypto

Einordnung statt Hype: was hinter den Tech-News steckt und was davon für dich zählt. Startbonus: die AD-Checkliste mit 12 Sofortmaßnahmen als PDF.

E-Mail-Adresse *

Mit der Anmeldung erhältst du die AD-Checkliste als PDF und danach den Tech-&-Tacheles-Newsletter mit Einordnungen zu Security, KI und Crypto sowie gelegentlichen Hinweisen auf meine Bücher und Produktempfehlungen (auch Affiliate-Links) – eingetragen bist du erst nach Klick auf den Bestätigungslink in der E-Mail (Double-Opt-in). Abmeldung jederzeit über den Link in jeder E-Mail, Details in der Datenschutzerklärung.

Was das für dich bedeutet

Beide Fehler haben dieselbe Form: Die Durchsetzung saß innerhalb dessen, was sie durchsetzen sollte. apply_patch errechnete seine Rechte aus Angreifer-Eingaben. node_repl bewahrte das Geheimnis zwischen vertrauenswürdig und nicht vertrauenswürdig im selben Speicher auf wie den nicht vertrauenswürdigen Code. Ein Kommentator nannte diese Grenze treffend einen Raumteiler.

Nach 25 Jahren IT und einigem an Identity- und Berechtigungsarbeit kommt mir das sehr bekannt vor: Es ist derselbe Fehler wie ein Client, der dem Server sagt, welche Rolle er hat. Neu ist nur die Kulisse. Und die Klasse ist nicht exotisch – im Juli 2026 zeigten Forscher von Pillar Security dieselbe Fehlerklasse quer über Cursor, Codex, Gemini CLI und Googles Antigravity – dort über einen anderen Weg: Der Agent blieb in der Sandbox und schrieb nur Dateien, die eine vertrauenswürdige Komponente außerhalb später ausführte.

Für die Praxis heißt das: Die Sandbox eines Coding-Agenten ist eine Komfortfunktion, keine Sicherheitsgrenze. Sie soll Versehen abfangen; Angriffe hält sie nur so lange auf, bis jemand genau hinsieht. Wer ein unbekanntes Repository von einem Agenten „nur analysieren“ lässt, führt fremden Einfluss auf seinem Arbeitsgerät aus – auch im strengsten Modus. Besonders unangenehm ist der Detailbefund, dass eine privilegierte Komponente per Default und ohne Abschaltmöglichkeit in einer globalen Konfiguration landet. Das ist eine Designentscheidung, keine Programmierschwäche.

Fairerweise: OpenAI hat innerhalb von acht Tagen reagiert, und das Unternehmen erklärte gegenüber BleepingComputer, man härte die Sandboxes laufend nach. Das ist eine gute Reaktionszeit. Sie ersetzt aber keine Grenze auf der richtigen Seite.

Konkrete Handlungsempfehlung

• Jetzt aktualisieren: Codex Desktop auf Build 26.818.21641 oder neuer, Codex CLI auf 0.149.0 oder neuer.
• ~/.codex/config.toml einmal selbst ansehen. Wer nicht weiß, welche Werkzeuge dort eingetragen sind, kennt die tatsächliche Angriffsfläche seines Agenten nicht.
• Fremde Repositories als nicht vertrauenswürdige Eingabe behandeln – egal in welchem Sandbox-Modus. „Nur eine Frage zum Code“ ist kein Lesevorgang, sondern eine Ausführung.
• Die echte Grenze außen ziehen: Agenten auf unbekanntem Code laufen in einer Wegwerf-VM oder einem Container ohne Zugriff auf Schlüssel, SSH-Agent und Cloud-Tokens. Das ist die einzige Schicht, die der Agent nicht selbst aushebeln kann.
• Shell-Startdateien überwachen: Änderungen an .zshrc, .bashrc oder .profile gehören in die Dateiintegritätsprüfung – sie sind der klassische Weg von „geschrieben“ zu „ausgeführt“.

Das Muster hat System: Wie Coding-Agenten ihre eigenen Prüfmechanismen aushebeln, habe ich zuletzt bei Plugin4Shell beschrieben. Wer das Thema systematisch aufarbeiten will, findet Grundlagen in meiner Übersicht zu Fachbüchern zu KI und Cybersecurity.

Quellen

• Accomplish AI: Escaping the OpenAI Codex Sandbox, Twice
• BleepingComputer, 20.09.2026
• DevOps.com: Guardrails can’t live inside the agent
• BleepingComputer: Sandbox-Ausbrüche bei Cursor, Codex, Gemini CLI und Antigravity (Juli 2026)