Sicherheit · 23. September 2026
Forscher umgehen OpenAI Codex-Sandbox und führen Befehle auf Host aus
Sicherheitsforscher fanden zwei Möglichkeiten, den OpenAI Codex-Sandbox zu verlassen, wobei eine Möglichkeit Befehle auf einem Entwicklersystem ausführen kann, ohne Bestätigungsaufforderung und ohne Bildschirmanzeige. Beide Fehler wurden am 12. August OpenAI gemeldet und innerhalb von acht Tagen behoben, wie Oren Yomtov von Accomplish AI berichtete.
Der schwerwiegendere Fehler, Heapjack genannt, verwandelt eine routinemäßige Aktion in Remote-Codeausführung: ein Repository eines anderen Entwicklers in Codex öffnen, eine Frage zum Code stellen, und der Urheber des Repositorys erhält unbeschränkten Befehlsausführungszugriff auf dem Computer des Angreifers.
Codex ist das Code-Agent von OpenAI, verfügbar als Befehlszeilentool und Desktop-Anwendung. Wie rivalisierende Agenten führt es die Aktionen des Modells in einem Sandbox aus, sodass nicht vertrauenswürdiger Code das breitere System nicht berühren kann. Beide Umgehungen überwinden diese Grenze von innen.
Heapjack nutzt einen Komponenten namens node_repl, die Codex Desktop in die globale Datei ~/.codex/config.toml schreibt, wenn sie installiert wird. Es gibt keine Option zum Ein- oder Ausschalten, und da die Einstellung in der gemeinsamen Konfiguration liegt, erben auch reine Codex CLI-Benutzer dieses Tool ohne weitere Abfrage.
node_repl startet einen einzelnen Node.js-Prozess mit zwei getrennten JavaScript-Ausführungskontexten. Einer ist vertrauenswürdig und enthält OpenAIs eigenen Code, der andere ist nicht vertrauenswürdig und führt den Code des Agents aus. Der vertrauenswürdige Kontext beweist seine Vertrauenswürdigkeit durch ein zufällig generiertes Token, das bei jedem Lauf neu erzeugt wird.
Der Fehler liegt darin, dass beide Kontexte in einem Node-Prozess und in einem gemeinsamen Speicherbereich liegen, sodass das Token lediglich ein String im Speicher ist, den die nicht vertrauenswürdige Seite lesen kann.
Die nicht vertrauenswürdige Seite nimmt einen Snapshot des Speichers mit v8.getHeapSnapshot() und versucht jede Zeichenkette, die wie eine UUID aussieht. Ein falscher Versuch gibt "nicht autorisiert" zurück, ein korrekter Versuch mit falscher Argumentation liefert einen echten Validierungsfehler, der dem Angreifer bestätigt, dass das Token stimmt.
Mit dem Token schreibt die nicht vertrauenswürdige Seite ihre eigene Anfrage auf denselben Kanal, den der vertrauenswürdige Kontext verwendet, um mit einem nativen, nicht sandboxierten Elterneprozess zu kommunizieren.
Der Elterneprozess prüft das Token, erkennt es als gültig, und führt die Arbeit aus. Der Proof-of-Concept nutzte das Systemkommando open, um eine Anwendung außerhalb des Codex-Prozessbaums zu starten. Diese Zugriffsmöglichkeit erreicht jeden Unix-Socket, insbesondere den Docker-Daemon-Socket, und ein Tool zur Bearbeitung der globalen Konfigurationsdatei.
Alles läuft im Lesemodus, dem strengsten Sandbox-Modus, in dem der Agent eigentlich nichts schreiben darf.
Der zweite Fehler, Overpatch, befindet sich im Open-Source-Codex-Command-Line-Interface. Im workspace-write-Modus darf der Agent nur innerhalb des Projektordners schreiben, und ein Shellbefehl, der auf das Home-Verzeichnis abzielt, wird abgelehnt.
Die Forscher nutzten das eigene Patch-Tool von Codex, apply_patch, um dort zu schreiben. Das Tool gewährt Schreibzugriff auf das übergeordnete Verzeichnis jedes im Patch genannten Pfads. Nennen Sie "/tmp", so wird Schreibzugriff auf die Festplattenwurzel gewährt.
Der funktionierende Exploit verwendet einen Patch mit zwei Änderungen: eine, die "/tmp" benennt und lediglich die Berechtigung erweitert, und eine, die über einen Symlink eine Zeile in .zshrc in das Home-Verzeichnis anhängt.
Entfernt man die erste Änderung, wird das Schreiben abgelehnt. Mit ihr führt das nächste geöffnete Terminal die Zeile des Angreifers ohne Sandbox aus.
Beide Fehler teilen ein gemeinsames Muster: die Durchsetzungsmechanik lebte innerhalb des zu schützenden Systems. apply_patch bestimmte seine Berechtigungen aus von Angreifern gelieferter Eingabe, und node_repl hielt das Trennungsmerkmal zwischen vertrauenswürdig und nicht vertrauenswürdig im selben Speicher wie der nicht vertrauenswürdige Code.
In beiden Fällen wurde das Sandbox von innen angewiesen, etwas durchzulassen.
Die Art des Fehlers ist nicht neu. Im Juli 2026 demonstrierten Pillar Security-Forscher das gleiche Prinzip bei Cursor, Codex, Gemini CLI und Googles Antigravity, wo ein Agent innerhalb seines Sandboxes eine Datei schreibt, die von einem vertrauenswürdigen Tool außerhalb des Sandboxes später ausgeführt wird.
Auf Yomtov’s Beitrag auf X reagierten Kommentatoren mit der Bemerkung, dass "V8-Kontexte globale Variablen isolieren, nicht Speicher, also war das Sandbox wirklich ein Versprechen, das der Speicher nie zugesagt hatte." Ein anderer bezeichnete die Vertrauensgrenze als "Raumteiler." Das standardmäßig aktive Verhalten löste eigene Skepsis aus, wobei ein Fragender fragte, warum ein privilegiertes Token überhaupt von nicht vertrauenswürdigem JavaScript erreichbar sei.
OpenAI behebt Heapjack in Codex Desktop Build 26.818.21641 und Overpatch in Codex CLI 0.149.0, wie Accomplish berichtete.
Benutzer sollten auf diese Versionen oder neuere aktualisieren. Yomtov dankte OpenAI dafür, dass beide Probleme innerhalb von acht Tagen nach seiner Meldung gelöst wurden.
BleepingComputer kontaktierte OpenAI vor Veröffentlichung.
In einer Erklärung an BleepingComputer heute bedankte sich ein OpenAI-Sprecher:
"Wir danken den Forschern für die Meldung und das Teilen ihrer Erkenntnisse. Wir haben beide Probleme im August behoben, aber wir stärken kontinuierlich unsere Sandboxes, mit jüngsten Updates, die Schreibzugriffsbegrenzungen verschärfen und Tests dieser Schutzmechanismen auf allen Plattformen erweitern."
Update, 21. September, 05:29 Uhr ET: Eine Erklärung von OpenAI wurde nach der Veröffentlichung hinzugefügt.
Erstellen Sie Ihr Sicherheitskonzept für KI-gestützte Angriffe
Nehmen Sie an einer zweistündigen digitalen Konferenz mit Mikko Hyppönen und Sicherheitsexperten aus NFL, CHANEL und Atlassian teil, um zu erfahren, wie KI-geschwindigkeit Angriffe verändert, welche Abwehrstrategien aufgegeben werden sollten und wie man auf maschineller Geschwindigkeit validiert, entscheidet, behebt und erneut validiert.