Zwei Sandbox-Ausbrüche aus OpenAI Codex: Heapjack und Overpatch gepatcht
Forscher haben zwei Wege aus der Sandbox des OpenAI-Coding-Agenten Codex gefunden. Heapjack erreichte Befehlsausführung außerhalb der Sandbox aus dem striktesten Modus heraus, Overpatch weitete Schreibrechte der Codex CLI auf das gesamte Dateisystem aus. Beide Lücken sind behoben, der Fall zeigt aber, wie dünn die Sandbox-Grenze bei KI-Coding-Agenten ist.
Zwei Wege aus der Sandbox des OpenAI-Coding-Agenten Codex sind öffentlich dokumentiert, und beide sind bereits geschlossen. Gemeldet wurden sie am 12. August 2026, laut dem Forscher Oren Yomtov von Accomplish AI hat OpenAI beide Lücken innerhalb von acht Tagen behoben. Wer Codex Desktop oder die Codex CLI im Unternehmen einsetzt, muss heute nicht in den Notfallmodus, sollte aber den Versionsstand der Installationen prüfen und gegebenenfalls in einem regulären Wartungsfenster aktualisieren.
Betroffen sind Entwicklerarbeitsplätze, auf denen Codex läuft und fremde Repositories geöffnet werden. Nicht betroffen sind Umgebungen ohne Codex. Andere KI-Coding-Agenten sind von genau diesen beiden Fehlern nicht betroffen, deshalb aber nicht automatisch sicher. Der Angriffspfad ist ausdrücklich keine Remote Code Execution auf einem Server, sondern Codeausführung auf dem Rechner der Entwicklerin oder des Entwicklers, ausgelöst durch ein präpariertes fremdes Repository. Genau das macht den Fall für Administratoren interessant, denn solche Rechner halten oft Quellcode, Cloud-Zugangsdaten, Docker-Sockets und Produktionsschlüssel vor.
Was ist passiert?
Codex ist OpenAIs Coding-Agent und steht als Kommandozeilenwerkzeug sowie als Desktop-Anwendung bereit. Wie konkurrierende Agenten führt er die Aktionen des Modells in einer Sandbox aus, damit nicht vertrauenswürdiger Code nicht auf das übrige System zugreifen kann. Die beiden nun veröffentlichten Funde durchbrechen genau diese Grenze, und zwar von innen heraus.
Der schwerwiegendere Fund trägt den Namen Heapjack. Er verwandelt eine alltägliche Handlung in Codeausführung: Man öffnet ein fremdes Repository in Codex und stellt eine Frage zum Code. Wer dieses Repository geschrieben hat, erhält dadurch Befehlsausführung außerhalb der Sandbox auf dem Rechner des Nutzers, ohne Bestätigungsdialog und ohne sichtbaren Hinweis auf dem Bildschirm.
Technisch zielt Heapjack auf eine Komponente namens node_repl, die Codex Desktop bei der Installation in die globale Datei ~/.codex/config.toml schreibt. Es gibt dafür kein Opt-in und keine Einstellung zum Abschalten. Weil der Eintrag in der gemeinsamen Konfiguration landet, erben auch reine Nutzer der Codex CLI dasselbe Werkzeug, ohne je gefragt worden zu sein.
node_repl betreibt einen einzelnen Node.js-Prozess, der zwei getrennte JavaScript-Ausführungskontexte hält: einen vertrauenswürdigen mit OpenAIs eigenem Code und einen nicht vertrauenswürdigen mit dem Code des Agenten. Der vertrauenswürdige Kontext weist sich mit einem bei jedem Start neu erzeugten Zufallstoken aus. Das Problem liegt darin, dass beide Kontexte in einem Node-Prozess leben und sich einen Speicher-Heap teilen. Der Token ist damit nur eine Zeichenkette im Speicher, die die nicht vertrauenswürdige Seite lesen kann.
Der Ablauf des Angriffs ist entsprechend geradlinig: Der nicht vertrauenswürdige Code erstellt mit v8.getHeapSnapshot() einen Speicherabzug und probiert jede Zeichenkette durch, die wie eine UUID aussieht. Ein falscher Versuch liefert not authorized zurück, ein korrekter Token mit falschem Argument dagegen einen echten Validierungsfehler. Damit weiß der Angreifer, dass er den richtigen Token gefunden hat. Mit diesem Token schreibt der nicht vertrauenswürdige Code eigene Anfragen auf dieselbe Pipe, über die der vertrauenswürdige Kontext mit einem nativen, nicht sandboxed Elternprozess spricht.
Der Machbarkeitsnachweis startete über den Systembefehl open eine Anwendung komplett außerhalb des Codex-Prozessbaums. Derselbe Zugang erreicht jeden Unix-Socket, wobei ein Docker-Daemon-Socket das naheliegende Ziel ist, sowie ein Werkzeug zum Bearbeiten der globalen Konfigurationsdatei. All das lief im Modus read-only, dem striktesten Sandbox-Modus, in dem der Agent eigentlich gar nichts schreiben darf.
Der zweite Fund heißt Overpatch und steckt in der quelloffenen Codex CLI. Im Modus workspace-write darf der Agent nur innerhalb des Projektordners schreiben, ein Shell-Befehl auf das Home-Verzeichnis 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 im Patch genannten Pfades. Nennt man /tmp, gewährt es Schreibzugriff auf die Wurzel des Dateisystems.
Der funktionierende Exploit nutzt einen Patch mit zwei Änderungen: eine, die /tmp nennt und außer der Rechteausweitung nichts bewirkt, und eine zweite, die über einen Symlink ins Home-Verzeichnis eine Zeile an .zshrc anhängt. Entfernt man die erste Änderung, wird der Schreibzugriff verweigert. Mit ihr führt das nächste geöffnete Terminal die Zeile des Angreifers außerhalb der Sandbox aus.
Wer ist betroffen?
Relevant ist die Meldung überall dort, wo Entwicklerinnen und Entwickler Codex Desktop oder die Codex CLI verwenden und dabei fremde oder geklonte Repositories öffnen. Heapjack betrifft dabei auch reine CLI-Nutzer, sobald Codex Desktop auf demselben Rechner einmal installiert wurde, weil der Eintrag für node_repl in der gemeinsamen Datei ~/.codex/config.toml steht. Overpatch liegt in der quelloffenen CLI selbst.
- Betroffen: Arbeitsplätze mit installiertem Codex Desktop oder Codex CLI, insbesondere wenn dort regelmäßig fremder Code analysiert wird.
- Besonders heikel: Rechner, auf denen zusätzlich Cloud-Zugangsdaten, SSH-Schlüssel, ein erreichbarer Docker-Socket oder Produktionszugänge liegen.
- Nicht betroffen: Umgebungen ohne Codex sowie aktuelle Installationen, in denen beide Fehler bereits behoben sind.
- Kein Freibrief: Andere KI-Coding-Agenten sind von diesen beiden konkreten Fehlern nicht betroffen, sie verwenden aber vergleichbare Sandbox-Konstruktionen.
Wie kritisch ist das?
Für sich genommen entschärft der Patchstand die Lage deutlich. Beide Fehler wurden vor der Veröffentlichung gemeldet und nach Angaben des Forschers binnen acht Tagen behoben. Wer aktuelle Versionen einsetzt, muss nichts überstürzen. Es gibt in den vorliegenden Quellen auch keinen Hinweis auf aktive Ausnutzung vor der Veröffentlichung.
Die technische Schwere ist trotzdem hoch. Heapjack erreicht Codeausführung ohne Bestätigungsdialog aus dem striktesten Sandbox-Modus heraus, also genau aus dem Zustand, in dem Anwender die geringste Gefahr erwarten. Der Zugriff entspricht laut Beschreibung dem, was ein Angreifer hätte, wenn man die Sandbox abschaltet und sein Skript selbst ausführt. Overpatch ist etwas enger gefasst, reicht aber aus, um Startdateien der Shell zu manipulieren und damit beim nächsten Terminalstart Code außerhalb der Sandbox auszuführen.
Wichtig für die richtige Einordnung: Es handelt sich nicht um eine serverseitige Remote Code Execution. Der Angreifer muss den Nutzer dazu bringen, sein Repository in Codex zu öffnen. Das ist im Alltag allerdings eine harmlose Routinehandlung, was die Hürde niedrig hält. Da ein Entwicklerrechner häufig Zugriff auf Quellcode, Cloud-Konten und Produktionsschlüssel hat, ist der potenzielle Schaden kein Randthema.
Beide Fehler haben dieselbe Form: Der Durchsetzungsmechanismus lebte innerhalb dessen, was er durchsetzen sollte. apply_patch ermittelte seine eigenen Rechte aus vom Angreifer gelieferter Eingabe, node_repl bewahrte das Geheimnis, das vertrauenswürdigen von nicht vertrauenswürdigem Code trennt, im selben Speicher wie den nicht vertrauenswürdigen Code auf. Diese Fehlerklasse ist nicht neu, im Juli 2026 demonstrierten Forscher von Pillar Security dieselbe Idee.
Was sollten Admins jetzt tun?
- Inventar erstellen: Zuerst feststellen, auf welchen Arbeitsplätzen Codex Desktop oder die Codex CLI überhaupt installiert ist. Ohne diese Liste lässt sich der Rest nicht bewerten.
- Versionsstand prüfen und aktualisieren: Installierte Codex-Versionen erfassen und auf einen aktuellen Stand bringen. Nach der Inventur reicht dafür ein reguläres Wartungsfenster.
- Konfiguration kontrollieren: Den Inhalt von
~/.codex/config.tomlsichten, insbesondere die dort eingetragenen Werkzeuge. Unbekannte oder nicht benötigte Einträge hinterfragen. - Hochrisikosysteme zuerst: Arbeitsplätze mit Produktionszugängen, Cloud-Schlüsseln oder erreichbarem Docker-Socket vorziehen, alle übrigen danach.
- Umgang mit fremdem Code regeln: Fremde Repositories nicht ungeprüft in einem Agenten öffnen. Unbekannter Code gehört in eine Wegwerfumgebung, nicht auf den Hauptarbeitsplatz.
- Docker-Socket nicht unnötig exponieren: Ein erreichbarer Daemon-Socket macht aus einem Sandbox-Ausbruch schnell eine vollständige Übernahme des Hosts.
- Produktionszugänge vom Entwicklerrechner trennen: Dauerhaft hinterlegte Produktionsschlüssel auf Arbeitsplätzen sind der eigentliche Hebel des Angriffs.
- Logs und Verdachtsfälle prüfen: Bei konkretem Verdacht auf einen Vorfall Shell-Startdateien wie
.zshrcund.bashrcauf ungewollte Zeilen kontrollieren und betroffene Secrets rotieren. - Agenten kapseln: KI-Coding-Agenten grundsätzlich in Containern oder virtuellen Maschinen betreiben, statt sich allein auf die eingebaute Sandbox zu verlassen.
- Vorgehen dokumentieren: Ergebnis der Inventur und den erreichten Patchstand festhalten, damit beim nächsten Fund dieser Art nicht wieder bei null begonnen wird.
Einordnung für Unternehmen
Für kleine und mittlere Unternehmen ist die eigentliche Lehre nicht der einzelne Fehler, sondern die Zuverlässigkeit der Schutzschicht. KI-Coding-Agenten werden häufig mit dem Argument eingeführt, ihre Sandbox fange schon ab, was schiefgehen kann. Beide Funde zeigen, wie dünn diese Grenze sein kann, wenn die Durchsetzung im selben Prozess und im selben Speicher läuft wie der zu kontrollierende Code.
Praktisch heißt das, den Entwicklerarbeitsplatz wie ein Zielsystem zu behandeln und nicht wie eine Nebensache. Ein Arbeitsplatz mit Cloud-Zugängen, Repository-Rechten und Container-Werkzeugen ist für Angreifer wertvoller als mancher Server. Wer Agenten einsetzt, sollte deren Rechte vorab begrenzen, statt sie nachträglich einzufangen.
Sinnvoll ist außerdem eine klare Regel im Team, wie mit fremdem Code umgegangen wird. Ein geklontes Repository aus einer unbekannten Quelle gehört in eine isolierte Umgebung, die man nach der Analyse verwirft. Das kostet wenig und entzieht genau dem Szenario die Grundlage, das Heapjack ausnutzt.
Passende Anleitungen auf S-EDV
- KI-Agenten absichern und gegen Prompt Injection härten zeigt, wie Sie Agentenzugriffe eingrenzen, bevor ein Ausbruch überhaupt etwas erreichen kann.
- OpenHands als KI-Coding-Agent in Docker selbst hosten beschreibt den Weg, einen Coding-Agenten in einem eigenen Container statt direkt auf dem Arbeitsplatz zu betreiben.
- Corebreak: Tool-Bypass in KI-Agenten von AWS, Google und Vercel ordnet ein, dass Schwächen in der Werkzeugabsicherung von Agenten kein Einzelfall sind.
