Zwei Auswege aus der OpenAI Codex-Sandbox: Heapjack und Overpatch

Am 15. September 2026 veröffentlichte Oren Yomtov, leitender Sicherheitsforscher bei Accomplish AI, einen technischen Bericht über zwei separate Wege aus der Sandbox, die den Codex-Coding-Agenten von OpenAI umgibt. Beide wurden am 12. August 2026 an OpenAI gemeldet und beide wurden laut seinem Bericht innerhalb von acht Tagen behoben: Heapjack in Codex Desktop Build 26.818.21641 und Overpatch in Codex CLI 0.149.0. Heapjack ist die schwerwiegendere der beiden. Für die angegriffene Person ist nichts weiter nötig, als ein Repository in Codex zu öffnen und eine Frage zum Code zu stellen, und es läuft im Nur-Lese-Modus, dem strengsten Modus, den das Produkt bietet, ohne Genehmigungsabfrage und ohne dass auf dem Bildschirm etwas angezeigt wird. Keiner der beiden Schwachstellen wurde eine CVE zugewiesen, und es wurde keine eigenständige OpenAI-Warnung veröffentlicht, so die Cloud Security Alliance, und niemand wurde als durch sie geschädigt gemeldet. Es ist zusammen mit den anderen Einträgen des Jahres zur Agentensteuerung in dem KI-Vorfallarchiv katalogisiert, wobei jeder Datensatz seine Quelldokumente, seinen Vertrauensgrad und seine Kennzeichnung als umstritten enthält.

Heapjack: Das Token lag in einem Heap, den die nicht vertrauenswürdige Seite lesen konnte.

Codex Desktop fragt nicht nach, bevor es die Komponente installiert, die Yomtov angegriffen hat. Zum Installationszeitpunkt schreibt es einen node_repl-Block in die globale Konfigurationsdatei unter ~/.codex/config.toml, und Yomtov berichtet, dass es weder eine Opt-in-Möglichkeit noch eine Einstellung gibt, die es abschaltet. Da der Eintrag in der gemeinsamen Konfiguration und nicht in einer benutzerspezifischen Auswahl liegt, erbt ein normaler Codex-CLI-Nutzer dasselbe Tool, ohne jemals gefragt zu werden.

Das Tool node_repl ist selbst ein natives Programm, das außerhalb der Sandbox läuft. Es kann Anwendungen öffnen, sich mit Unix-Sockets verbinden und die globale Konfigurationsdatei bearbeiten. Was es innerhalb der Sandbox startet, ist ein einzelner Node.js-Prozess, und dieser Prozess enthält zwei JavaScript-Ausführungskontexte: einen vertrauenswürdigen, der OpenAIs eigenen Code enthält, und einen nicht vertrauenswürdigen, der ausführt, wozu der Agent aufgefordert wurde.

Der vertrauenswürdige Kontext beweist seine Vertrauenswürdigkeit, indem er ein zufälliges Token vorlegt, das bei jedem Lauf neu erzeugt wird. Das soll die Grenze zwischen den beiden Kontexten sein. Sie ist es nicht, weil beide Kontexte in einer einzigen V8-Isolate leben, die sich einen einzigen Speicher-Heap teilt, sodass das Token eine Zeichenkette im Speicher ist, die der nicht vertrauenswürdige Code lesen kann. Ein Kommentator, der auf die Offenlegung auf X reagierte, formulierte den Punkt in einer von BleepingComputer zitierten Zeile unverblümter: „V8-Kontexte isolieren Globals, nicht den Speicher, also war die Sandbox in Wahrheit ein Versprechen, dem der Heap nie zugestimmt hat.“ Das ist eine Charakterisierung, kein Beweis; der Beweis ist der Proof of Concept.

Yomtovs Exploit tut genau das, was diese Beschreibung impliziert. Nicht vertrauenswürdiges JavaScript ruft v8.getHeapSnapshot() auf, durchsucht den resultierenden Snapshot nach Zeichenfolgen, die wie eine UUID aussehen, und testet jeden Kandidaten. Eine falsche Vermutung führt zu „not authorized“. Ein korrektes Token, kombiniert mit einem ungültigen Argument, liefert stattdessen einen echten Validierungsfehler. Der Unterschied zwischen den beiden Fehlermeldungen ist das Orakel, das den richtigen Wert identifiziert.

Mit dem Token in der Hand schreibt der in der Sandbox laufende Prozess seine eigene JSON-Anfrage auf Dateideskriptor 1 – dieselbe stdout-Pipe, über die der vertrauenswürdige Kontext den nativen Elternprozess erreicht. Der Elternprozess validiert das Token, findet ein gültiges vor und erledigt die Arbeit. Im Proof of Concept war diese Arbeit der System-open-Befehl, der die Anfrage an launchd übergibt und die Anwendung vollständig außerhalb von Codex' Prozessbaum startet. Dasselbe Token erlaubt Verbindungen zu beliebigen Unix-Sockets – darunter ein Docker-Daemon-Socket – und erreicht ein Tool zum Bearbeiten der globalen Konfigurationsdatei.

All das läuft im schreibgeschützten Modus ab – dem Modus, den ein vorsichtiger Nutzer genau deshalb wählt, weil dem Repository vor ihm nicht vertraut wird. Zu keinem Zeitpunkt erschien eine Genehmigungsaufforderung. Das praktische Szenario ist kurz: ein geklontes Repository in Codex im schreibgeschützten Modus öffnen und eine Frage zum Code stellen. Wer dieses Repository geschrieben hat, erhält die Möglichkeit, Befehle ohne Sandbox auf dem Rechner auszuführen, und auf dem Bildschirm deutet nichts darauf hin.

Overpatch: ein Patch-Tool, das allem, was es berührte, das Elternobjekt gewährte

Der zweite Fehler steckt in Codex CLI, dem quelloffenen Kommandozeilen-Agenten, und es handelt sich um einen Berechtigungsfehler, nicht um einen Speicherfehler. Im Modus workspace-write darf der Agent nur innerhalb des Projektordners schreiben und sonst nirgends; ein Shell-Befehl, der auf das Home-Verzeichnis abzielt, wird abgelehnt. Das Tool apply_patch sollte diese Grenze wahren. Stattdessen leitete es seine Berechtigungen von den im Patch genannten Pfaden ab und gewährte Schreibzugriff auf das übergeordnete Verzeichnis jedes einzelnen davon.

Nennen Sie in einem Patch einen Pfad unter /tmp, und die Berechtigung weitet sich auf das Wurzelverzeichnis der Festplatte aus, weil das übergeordnete Verzeichnis von /tmp / ist. Das ist der ganze Trick.

Der funktionierende Exploit verwendet zwei Einträge in einem einzelnen Patch. Der erste benennt /tmp und bewirkt nichts Nützliches – er schlägt fehl, da eine Datei kein Verzeichnis überschreiben kann – und dient nur dazu, die Berechtigung zu erweitern. Der zweite hängt über einen Symlink ins Home-Verzeichnis eine Zeile an .zshrc an. Entfernt man den ersten Eintrag, wird der Schreibvorgang verweigert. Behält man ihn, führt das nächste Terminal, das der Entwickler öffnet, die Zeile des Angreifers ohne Sandbox aus, wobei die Sandbox überhaupt nicht mehr beteiligt ist.

Das macht Overpatch zu einem Persistenz-Bug statt zu einem einmaligen Vorfall. Die vergiftete Startdatei wird bei jeder Shell, die der Entwickler öffnet, erneut ausgeführt, bis jemand .zshrc liest und die angehängte Zeile bemerkt — weshalb die Cloud Security Alliance empfiehlt, gezielt danach zu suchen, statt auf ein Symptom zu warten.

Beide Bugs stecken die Durchsetzung in das, was durchgesetzt wird.

Yomtovs eigene Rahmung ist der Teil, der über Codex hinausreicht. apply_patch berechnete seine eigenen Berechtigungen aus einer Eingabe, die ein Angreifer geliefert hatte. node_repl bewahrte das Geheimnis, das vertrauenswürdigen von nicht vertrauenswürdigem Code trennt, in einem Speicher auf, den der nicht vertrauenswürdige Code lesen konnte. In jedem Fall wurde der Sandbox von innen gesagt, etwas durchzulassen.

Das Muster ist nicht neu. BleepingComputer, das die Offenlegung am 20. September 2026 gemeldet hat, merkt an, dass Forscher von Pillar Security im Juli 2026 dieselbe Idee in Cursor, Codex, Gemini CLI und Google Antigravity demonstrierten: Ein Agent, der in seiner Sandbox bleibt, schreibt eine Datei, die ein vertrauenswürdiges Tool außerhalb der Sandbox später ausführt. Was das Codex-Paar heraushebt, ist der Nur-Lese-Bypass in Heapjack und das Fehlen einer Einstellung, mit der sich die Komponente deaktivieren lässt, die ihn mit sich bringt.

Die Korrekturen – und was OpenAI gesagt hat und was nicht.

OpenAI hat Heapjack in Codex Desktop Build 26.818.21641 und Overpatch in Codex CLI 0.149.0 laut Accomplish behoben. Beide kamen innerhalb von acht Tagen nach dem Bericht vom 12. August – bis zum 20. August, bei wörtlicher Lesart dieser Zeitlinie – und Yomtov schrieb OpenAI die Kehrtwende zu.

OpenAI veröffentlichte zu keiner der beiden Schwachstellen eine eigenständige Sicherheitsmeldung, und es wurde keine CVE-Kennung vergeben; die Cloud Security Alliance hält beide Auslassungen in einer Forschungsnotiz vom 22. September 2026 fest. Auf eine Bitte um Stellungnahme erklärte ein OpenAI-Sprecher gegenüber BleepingComputer: „Wir danken den Forschenden für die Kontaktaufnahme und die Weitergabe ihrer Ergebnisse. Wir haben beide Probleme im August behoben, aber wir verstärken unsere Sandboxes fortlaufend, mit jüngsten Updates, die die Kontrollen darüber verschärfen, wo Agenten Dateien schreiben können, und die Tests dieser Schutzmaßnahmen plattformübergreifend ausweiten.“

Diese Erklärung bestätigt die Korrekturen und sagt nichts über die Mechanismen aus. Sie sagt nicht, ob die Änderungen vom August das Designmuster entfernt oder die beiden konkreten Auswege daraus geschlossen haben. Auch niemand außerhalb von OpenAI hat das gesagt.

Was ist gesichert, und was beruht auf einem einzigen Forscher?

Das Archiv führt diesen Eintrag als Forschungsergebnis, Schweregrad hoch, Region global, Konfidenz B – dokumentiert, aber aus einer einzelnen oder sekundären Quelle – nicht umstritten, ohne verzeichneten tatsächlichen Schaden. Diese Einstufung ist die richtige Linse, um den Rest dieses Beitrags zu lesen, denn der Gegensatz zwischen dem, was mehrere Parteien bestätigen, und dem, was nur der Finder behauptet, zieht sich durch die gesamte Geschichte.

Etabliert, in dem Sinne, dass mehr als eine Partei es sagt:

• Die Offenlegung existiert und ist datiert. Yomtovs Bericht wurde am 15. September 2026 veröffentlicht; beide Schwachstellen wurden am 12. August 2026 an OpenAI gemeldet und laut seiner Darstellung innerhalb von acht Tagen behoben.

• {{1}}OpenAI{{/1}} bestätigt, im August gehandelt zu haben. Ein Sprecher des Unternehmens teilte {{2}}BleepingComputer{{/2}} mit, dass beide Probleme behoben wurden, was die Zeitlinie von Meldung und Behebung unabhängig vom Entdecker bestätigt, obwohl das Unternehmen weder einen Sicherheitshinweis noch einen eigenen technischen Bericht veröffentlicht hat.

• Die korrigierten Versionen werden einheitlich angegeben. Build 26.818.21641 für Codex Desktop und Version 0.149.0 für Codex CLI werden von Accomplish genannt, von BleepingComputer wiederholt und in einem Advisory vom 22. September 2026 des Uganda National Computer Emergency Response Team and Coordination Center aufgeführt, das das Paar mit „Red“ bewertete.

• Keine CVE, keine Herstellerwarnung und keine gemeldete Ausnutzung. Die Notiz der Cloud Security Alliance vom 22. September 2026 hält fest, dass weder eine CVE noch eine eigenständige OpenAI-Warnung vorliegt, und berichtet von keinen bestätigten Fällen, in denen eine Organisation den Persistenzmechanismus von Overpatch vorhanden vorgefunden hätte.

• Das Archiv bestreitet nichts davon. Der Eintrag ist als nicht umstritten markiert, und seine Vertrauensstufe spiegelt das Quellenmuster wider und nicht etwa eine Uneinigkeit über die Fakten.

Nicht festgestellt oder nur durch den Finder festgestellt:

Die Details des Mechanismus stammen von Yomtov. Das Heap-Snapshot-Orakel, der gemeinsam genutzte Dateideskriptor, die Berechtigung für das übergeordnete Verzeichnis – all das stammt aus seiner Ausarbeitung und seinem Proof of Concept. Die Cloud Security Alliance, deren Notiz die detaillierteste kursierende Zusammenfassung eines Dritten ist, beschreibt, dass sie seine Darstellung und die Berichterstattung von BleepingComputer zusammengeführt hat, und gibt nicht an, einen der Exploits reproduziert oder einen der Fixes getestet zu haben. Der Sicherheitshinweis von CERT.UG stellt dasselbe Material zusammen.

• Die anfälligen Versionsbereiche wurden nie veröffentlicht. Es werden nur die Fix-Versionen genannt, daher gibt es keine Liste darüber, welche früheren Builds die jeweilige Schwachstelle enthielten.

• Ob eine gepatchte Installation vor der Fehlerklasse sicher ist – und nicht nur vor diesen beiden Fällen –, wird nicht angegeben. OpenAIs „kontinuierliche Stärkung unserer Sandboxes“ ist eine allgemeine Zusage, keine Aussage über einen bestimmten Mechanismus.

• Es wurde niemand gemeldet, der eine der beiden Schwachstellen ausgenutzt hätte. Das ist eine Abwesenheit von Meldungen, nicht der Befund einer Abwesenheit, und der Proof of Concept zeigt, dass der Heapjack-Pfad nichts auf dem Bildschirm hinterlässt, das ein Nutzer bemerken würde.

Worauf ein Benutzer reagieren kann

Wer Codex Desktop in einer Build älter als 26.818.21641 oder Codex CLI in einer Version älter als 0.149.0 einsetzt, befindet sich auf der anfälligen Seite der Grenze, die Accomplish zieht, und eine Aktualisierung ist das einzige Gegenmittel, das die Offenlegung bietet. Darüber hinaus empfiehlt die Cloud Security Alliance, vergangene Codex Desktop-Sitzungen, an denen nicht vertrauenswürdige Repositories beteiligt waren, auf launchd- oder open-Aktivitäten sowie auf Docker-Socket-Verbindungen zu prüfen und Shell-Startdateien – .zshrc, .bashrc und ihre Entsprechungen – auf Befehle zu prüfen, die angehängt und nicht vom Benutzer geschrieben wurden.

Dieselbe Anmerkung rät davon ab, den schreibgeschützten Modus als Schutz zu behandeln, wenn das Repository nicht vertrauenswürdig ist – genau die Schlussfolgerung, zu der Heapjack aus eigenem Antrieb gelangt. Ihre strukturellen Empfehlungen gehen weiter: physische Prozess- und Speicherisolierung statt gemeinsamer Geheimnisse und Konventionen, Zugangsdaten außerhalb der Reichweite des Agenten und Patches, die Pfade außerhalb des Projekts referenzieren, die sofort als verdächtig gelten. Das sind Vorschläge eines Dritten. Ob OpenAI irgendetwas davon über die beiden Versionssprünge hinaus übernommen hat, ist nicht öffentlich.

Zum Schluss lohnt es sich, zwei Dinge auseinanderzuhalten. Das eine ist ein Paar von Fehlern in einem weit verbreiteten Coding-Agenten, gemeldet am 12. August 2026, innerhalb von acht Tagen behoben und mit zwei Build-Nummern geschlossen. Das andere ist die von Yomtov benannte Designfrage – ob eine Sandbox durch den Code durchgesetzt werden kann, den sie eigentlich enthalten soll – und diese Frage beantwortet keine Versionsnummer. Weder Accomplish noch OpenAI haben gesagt, dass die August-Änderungen sie klären.