OpenAI patcht zwei von Forschern entdeckte Codex-Sandbox-Ausbrüche

Zwei neu offengelegte Techniken zum Ausbruch aus der Codex-Sandbox zeigen, wie ein KI-Coding-Assistent aus dem geschützten Bereich herausgedrängt werden kann, in dem er eigentlich bleiben soll – und beide wurden innerhalb von acht Tagen nach der Meldung behoben. Die Ergebnisse stammen von Oren Yomtov von Accomplish AI, der die Schwachstellen am 12. August an OpenAI meldete. Codex ist OpenAIs Coding-Agent, der als Kommandozeilenwerkzeug und als Desktop-Anwendung angeboten wird, und wie ähnliche Agenten anderer Anbieter ist er so gebaut, dass er die Aktionen des Modells in einer Sandbox ausführt, einem abgeschotteten Bereich, der verhindert, dass nicht vertrauenswürdiger Code den Rest des Rechners berührt. Beide Ausbrüche funktionieren, indem sie diese Grenze von innen heraus überwinden, statt von außen einzudringen.

Die schwerwiegendere Schwachstelle, die die Forscher Heapjack nennen, verwandelt eine gewöhnliche Aktion in Remote-Code-Ausführung, was bedeutet, dass Angreifercode auf dem Rechner des Opfers selbst läuft. Der Weg ist kurz: Öffnen Sie das Code-Repository eines anderen in Codex, stellen Sie dem Agenten eine Frage zu diesem Code, und die Person, die das Repository geschrieben hat, erhält unsandboxed Befehlsausführung auf Ihrem Rechner. Laut Yomtovs Bericht zielt die Technik auf eine Komponente namens node_repl ab, die Codex Desktop bei der Installation in die globale Konfigurationsdatei unter ~/.codex/config.toml schreibt. Es gibt keine Opt-in-Möglichkeit und keine Einstellung, um sie abzuschalten, und weil der Eintrag in der gemeinsamen Konfiguration liegt, erben Nutzer des reinen Codex-Kommandozeilenwerkzeugs dieselbe Komponente, ohne jemals gefragt zu werden.

Der Grund, warum der Ausbruch funktioniert, ist eine Designentscheidung innerhalb von node_repl. Es führt einen einzelnen Node.js-Prozess aus, eine Laufzeitumgebung für JavaScript-Programme, die zwei getrennte JavaScript-Ausführungskontexte enthält. Einer davon ist vertrauenswürdig und enthält OpenAIs eigenen Code, der andere ist nicht vertrauenswürdig und führt den Code des Agenten aus. Die vertrauenswürdige Seite weist sich als vertrauenswürdig aus, indem sie ein zufälliges Token vorlegt, das bei jedem Lauf neu erzeugt wird. Das Problem ist, dass beide Kontexte im selben Prozess sitzen und denselben Speicher-Heap teilen, sodass dieses geheime Token einfach als Zeichenkette im Speicher liegt, wo die nicht vertrauenswürdige Seite es lesen kann.

Der nicht vertrauenswürdige Code erstellt mit einer Funktion namens v8.getHeapSnapshot() einen Schnappschuss des Heaps und probiert dann jede Zeichenkette aus, die wie eine universell eindeutige Kennung (UUID) aussieht. Eine falsche Vermutung kommt mit einer Meldung zurück, die besagt, dass keine Autorisierung vorliegt. Ein korrektes Token, das mit einem absichtlich fehlerhaften Argument gesendet wird, erzeugt einen echten Validierungsfehler, der dem Angreifer sagt, dass das Token das richtige ist. Mit dem Token in der Hand schreibt der nicht vertrauenswürdige Code seine eigene Anfrage auf dieselbe Pipe, die der vertrauenswürdige Kontext verwendet, um mit einem nativen, nicht gesandboxten Elternprozess zu sprechen. Der Elternprozess prüft das Token, sieht ein gültiges und erledigt die Arbeit. Der Proof of Concept verwendete den Systembefehl 'open', um eine Anwendung völlig außerhalb des Prozessbaums von Codex zu starten. Der Bericht merkt an, dass derselbe Zugriff jeden Unix-Socket erreicht, wobei ein Docker-Daemon-Socket das offensichtliche Ziel ist, sowie ein Werkzeug zum Bearbeiten der globalen Konfigurationsdatei. All dies läuft im schreibgeschützten Modus, dem strengsten Sandbox-Modus, in dem der Agent eigentlich gar nichts schreiben können soll.

Die zweite Schwachstelle, Overpatch, sitzt im Open-Source-Codex-CLI. Im Workspace-Write-Modus darf der Agent nur innerhalb des Projektordners schreiben, und ein Shell-Befehl, der auf das Home-Verzeichnis zielt, wird abgelehnt. Die Forscher brachten Codex' eigenes Patch-Werkzeug apply_patch dazu, trotzdem dorthin zu schreiben. Das Werkzeug gewährt Schreibzugriff auf den übergeordneten Ordner jedes in einem Patch genannten Pfads, sodass die Nennung von '/tmp' ausreicht, um Schreibzugriff auf das Wurzelverzeichnis der Festplatte zu gewähren. Der funktionierende Exploit verwendet einen Patch mit zwei Änderungen: eine, die '/tmp' nennt und nichts Nützliches tut, außer die Berechtigung zu erweitern, und eine, die über einen Symlink ins Home-Verzeichnis eine Zeile an '.zshrc' anhängt. Entfernt man die erste Änderung, wird das Schreiben abgelehnt. Behält man sie, führt das nächste Terminal, das der Entwickler öffnet, die Zeile des Angreifers ohne Sandbox aus.

Beide Fehler haben dieselbe Form: Der Durchsetzungsmechanismus lebte in genau dem Ding, das er eigentlich durchsetzen sollte. apply_patch ermittelte seine eigenen Berechtigungen aus vom Angreifer gelieferten Eingaben, und node_repl bewahrte das Geheimnis, das vertrauenswürdigen von nicht vertrauenswürdigem Code trennt, im selben Speicher wie den nicht vertrauenswürdigen Code auf. In beiden Fällen wurde der Sandbox von innen gesagt, etwas durchzulassen.

Diese Art von Fehler ist nicht neu. Im Juli 2026 demonstrierten Forscher von Pillar Security dieselbe Idee bei Cursor, Codex, Gemini CLI und Googles Antigravity und zeigten einen Agenten, der in seiner Sandbox bleibt und eine Datei schreibt, die ein vertrauenswürdiges Werkzeug außerhalb der Sandbox später ausführt. Als Reaktion auf Yomtovs Beitrag auf X schrieb ein Kommentator, dass „V8-Kontexte Globals isolieren, nicht den Speicher, die Sandbox also wirklich ein Versprechen war, dem der Heap nie zugestimmt hat.“ Ein anderer beschrieb die Vertrauensgrenze als Zimmerteiler. Dass die node_repl-Komponente standardmäßig aktiviert ist, zog ebenfalls Kritik auf sich, und ein Kommentator fragte, warum ein privilegiertes Token überhaupt von nicht vertrauenswürdigem JavaScript aus erreichbar war.

OpenAI hat Heapjack in Codex Desktop Build 26.818.21641 und Overpatch in Codex CLI 0.149.0 behoben, so Accomplish. Nutzer sollten auf diese oder spätere Versionen aktualisieren. Yomtov lobte OpenAI dafür, beide Probleme innerhalb von acht Tagen nach seiner Meldung gelöst zu haben. BleepingComputer gab an, vor der Veröffentlichung eine Stellungnahme von OpenAI angefragt zu haben.

Für Teams, die Unterstützung bei der Überprüfung wünschen, wie Entwickler- und Cloud-Tools in ihrer Organisation konfiguriert sind, bietet AEU-I sicherheitsorientierte IT-, Infrastruktur- und Beratungsdienste an.