Schwachstellen in der OpenAI-Codex-Sandbox ermöglichen Befehlsausführung auf Host-Ebene

Zwei Schwachstellen in OpenAI Codex ermöglichten es, dass vom Agenten gesteuerte Vorgänge ihre vorgesehenen Sicherheitsgrenzen überschritten und das Hostsystem eines Entwicklers beeinflussten. Eine davon funktionierte sogar unter der strengsten Nur-Lese-Richtlinie, während die andere Beschränkungen für Schreibzugriffe auf den Arbeitsbereich umging.

Die Forscher nannten die Schwachstellen Heapjack und Overpatch. Heapjack betrifft Codex Desktop und kann eine Befehlsausführung außerhalb der Sandbox ohne Bestätigungsabfrage oder sichtbare Warnung ermöglichen. Overpatch betrifft die Open-Source-Codex-CLI und kann Dateien außerhalb des freigegebenen Projektverzeichnisses verändern, darunter auch die Datei .zshrc des Benutzers.

Beide Schwachstellen wurden OpenAI am 12. August 2026 gemeldet. OpenAI behob sie innerhalb von acht Tagen und veröffentlichte für Heapjack Codex Desktop Build 26.818.21641 sowie für Overpatch Codex CLI 0.149.0.

CVE-Kennungen oder formale CVSS-Bewertungen wurden nicht veröffentlicht. Es gibt außerdem keine Hinweise darauf, dass eine der beiden Schwachstellen in freier Wildbahn ausgenutzt wurde.

Heapjack durchbricht die Nur-Lese-Sicherheitsgrenze

Heapjack ist der schwerwiegendere der beiden Befunde, da die Schwachstelle von der Analyse von Code innerhalb der Sandbox zu Aktivitäten auf Host-Ebene führen kann. Ein Entwickler könnte den Angriff auslösen, indem er das Repository einer anderen Person in Codex öffnet und den Agenten nach dessen Inhalten fragt.

Der Exploit funktioniert auch dann, wenn Codex im Nur-Lese-Modus konfiguriert ist. Unter dieser Richtlinie würden Benutzer normalerweise erwarten, dass der Agent Dateien untersuchen kann, ohne das System zu verändern oder ungeschützte Vorgänge auf dem Host auszuführen.

Stattdessen zielt Heapjack auf die von Codex Desktop installierte Komponente node_repl. Bei der Installation fügt Codex Desktop diese Komponente der globalen Konfigurationsdatei unter folgendem Pfad hinzu:

~/.codex/config.toml

Die Komponente ist standardmäßig aktiviert. Eine gesonderte Zustimmung ist nicht erforderlich, und eine dedizierte Option zu ihrer Deaktivierung wurde nicht bekannt gegeben. Da die Konfiguration global gilt, können auch Benutzer der Codex CLI das Tool übernehmen, ohne eine weitere Autorisierungsanfrage zu erhalten.

Damit ist die verwundbare Funktion nicht auf ein einzelnes Repository oder eine ausdrücklich genehmigte Sitzung beschränkt. Sie wird Bestandteil der gemeinsamen Codex-Umgebung des Benutzers.

Ein geheimes Token neben nicht vertrauenswürdigem JavaScript

Das verwundbare Design von node_repl verwendet einen Node.js-Prozess mit zwei getrennten JavaScript-Kontexten. Einer ist vertrauenswürdig und führt OpenAI-Code aus. Der andere ist nicht vertrauenswürdig und führt vom Agenten kontrollierten Code aus.

Der vertrauenswürdige Kontext kommuniziert mit einem nativen übergeordneten Prozess, der außerhalb der Sandbox läuft. Jede Anfrage wird dabei mit einem zufällig generierten Token authentifiziert, das für den jeweiligen Lauf erstellt wird.

Die Trennung der JavaScript-Kontexte trennt jedoch nicht ihren zugrunde liegenden Speicher. Beide Kontexte verwenden denselben Node.js-Heap, sodass das Authentifizierungstoken für Code im nicht vertrauenswürdigen Kontext erreichbar bleibt.

Der Proof of Concept für Heapjack ruft Folgendes auf:

v8.getHeapSnapshot()

Anschließend durchsucht er den resultierenden V8-Heap-Snapshot nach Zeichenfolgen, die der erwarteten UUID-ähnlichen Struktur des Tokens entsprechen. Das Auffinden möglicher Werte ist jedoch nur der erste Schritt. Der Exploit muss außerdem feststellen, welcher der Kandidaten gültig ist.

Die Forscher erreichten dies, indem sie beobachteten, wie der übergeordnete Prozess auf verschiedene Anfragen reagierte. Ein falsches Token führte zu einem Autorisierungsfehler. Wurde ein korrektes Token mit einem ungültigen Argument übermittelt, erschien stattdessen ein anderer Validierungsfehler. Diese Unterscheidung diente als Authentifizierungsorakel und bestätigte, wann das echte Token wiederhergestellt worden war.

Der nicht vertrauenswürdige Kontext konnte anschließend eine gefälschte Anfrage in dieselbe Kommunikationsleitung schreiben, die auch von der vertrauenswürdigen Komponente verwendet wurde. Da die Nachricht das gültige Token enthielt, akzeptierte der ungeschützte übergeordnete Prozess sie und führte den angeforderten Vorgang aus.

Im demonstrierten Angriff rief der übergeordnete Prozess den Systembefehl open auf, um eine Anwendung außerhalb des Codex-Prozessbaums zu starten. Der Vorgang löste weder eine Bestätigungsabfrage noch einen sichtbaren Hinweis innerhalb von Codex aus.

Die gemeldeten technischen Erkenntnisse identifizierten außerdem Unix-Sockets als potenziell wertvolles Ziel. Ein erreichbarer Docker-Daemon-Socket könnte besonders weitreichende Folgen haben, da er Zugriff auf Funktionen ermöglichen kann, die deutlich über eine gewöhnliche Repository-Analyse hinausgehen. Die Forscher stellten außerdem fest, dass ein Tool Zugriff auf die globale Codex-Konfiguration hatte und diese bearbeiten konnte.

Overpatch erweitert Schreibzugriffe über den Arbeitsbereich hinaus

Overpatch greift eine andere Kontrolle in der Open-Source-Codex-CLI an. Die Schwachstelle betrifft den Workspace-Write-Modus, der dem Agenten Änderungen an Projektdateien ermöglichen soll, während Schreibzugriffe an anderen Orten verhindert werden.

Direkte Shell-Versuche, in das Home-Verzeichnis des Entwicklers zu schreiben, werden unter dieser Richtlinie abgelehnt. Die Umgehung nutzt stattdessen Codex’ eigenes Tool apply_patch.

Das Problem liegt darin, wie apply_patch den zulässigen Schreibbereich bestimmt. Das Tool leitet Berechtigungen aus den übergeordneten Verzeichnissen der in einem Patch enthaltenen Pfade ab. Diese Pfade können über vom Agenten kontrollierte Patch-Inhalte vorgegeben werden.

Der funktionierende Exploit umfasst zwei Änderungen. Die erste verweist auf /tmp – nicht unbedingt, weil der Angreifer dort eine Datei verändern muss, sondern weil dieser Pfad das Tool dazu bringt, seinen Berechtigungsbereich auf die Wurzel des Dateisystems auszuweiten.

Die zweite Änderung folgt einem Symlink und hängt einen vom Angreifer kontrollierten Befehl an die Datei .zshrc des Entwicklers an. Da der Eintrag /tmp vorhanden ist, wird der externe Schreibzugriff erfolgreich ausgeführt. Wird dieser Eintrag entfernt, wird derselbe Vorgang abgelehnt.

Der eingeschleuste Befehl wird nicht sofort ausgeführt. Er läuft außerhalb der Codex-Sandbox, wenn der Entwickler später ein Terminal öffnet, das .zshrc verarbeitet.

Overpatch schafft damit einen verzögerten Ausführungspfad und eine Persistenzmöglichkeit. Der Agent scheint innerhalb des Projekts zu arbeiten, doch sein Patch-Vorgang verändert das Startverhalten der Shell im Home-Verzeichnis des Benutzers.

Beide Schwachstellen platzieren die Durchsetzung an der falschen Stelle

Heapjack und Overpatch verwenden unterschiedliche Techniken, doch ihr grundlegender Designfehler ist ähnlich: Die eingeschränkte Komponente darf an der Durchsetzung ihrer eigenen Einschränkungen mitwirken.

Bei Heapjack wird ein privilegiertes Authentifizierungsgeheimnis in einem Speicher abgelegt, den es mit feindlichem JavaScript teilt. Das Sicherheitsmodell vertraut auf ein Token, das die nicht vertrauenswürdige Ausführungsumgebung wiederherstellen und erneut verwenden kann.

Bei Overpatch leitet die Patch-Komponente ihre Berechtigung aus Pfaden ab, die von dem Agenten vorgegeben werden, den sie eigentlich beschränken soll. Ein schädlicher Patch kann daher die Berechnung beeinflussen, anhand derer bestimmt wird, wohin geschrieben werden darf.

Es handelt sich dabei um Probleme mit fehlgeleitetem Vertrauen und nicht um gewöhnliche Parsing-Fehler. Der Agent muss eine Kernel-Sandbox nicht direkt durchbrechen, wenn er ein vertrauenswürdiges externes Mechanismus dazu bringen kann, die sensible Aktion auszuführen.

Vergleichbare Fehler an Agenten-Vertrauensgrenzen mit Cursor, Codex, Gemini CLI und Googles Antigravity wurden im Juli 2026 gemeldet. In diesen Fällen konnte ein Agent technisch innerhalb seiner Sandbox bleiben und dennoch ein vertrauenswürdigeres Tool dazu bringen, eine vom Agenten erstellte Datei auszuführen.

Die wiederkehrende Erkenntnis ist klar: Eine Sandbox für den Agentenprozess reicht nicht aus, wenn Hilfstools, gemeinsam genutzter Speicher, Konfigurations-Handler oder externe Ausführungsmechanismen Eingaben akzeptieren, die vom Agenten beeinflusst werden können.

Entwickler sollten beide Codex-Produkte aktualisieren

Benutzer sollten Codex Desktop Build 26.818.21641 oder höher installieren, um Heapjack zu beheben. Zusätzlich sollten sie die Codex CLI auf Version 0.149.0 oder höher aktualisieren, um Overpatch zu beseitigen.

Nur eines der beiden Updates zu installieren, reicht nicht aus, da die Schwachstellen unterschiedliche Komponenten und Sicherheitsmodi betreffen.

Bis die Updates eingespielt sind, sollten Entwickler vermeiden, Repositories nicht vertrauenswürdiger Autoren in Codex zu öffnen. Eine Nur-Lese-Analyse sollte nicht als vollständiger Schutz gegen Anweisungen aus dem Repository oder vom Agenten gesteuerte Ausführung betrachtet werden.

Verteidiger und betroffene Benutzer können außerdem Folgendes überprüfen:

• ~/.codex/config.toml auf unerwartete node_repl-Konfigurationen oder andere nicht autorisierte Änderungen.
• .zshrc und andere Shell-Startdateien auf unbekannte angehängte Befehle.
• Codex-bezogene Aufrufe des Systembefehls open.
• Unerwartete Zugriffe auf Unix-Sockets, insbesondere auf Docker-Daemon-Sockets.
• Patch-Aktivitäten mit /tmp, einem Berechtigungsbereich auf Ebene der Dateisystemwurzel oder Symlinks, die aus einem Projekt herausführen.
• Anwendungen, die außerhalb des erwarteten Codex-Prozessbaums gestartet wurden.

Heapjack hinterlässt möglicherweise weniger offensichtliche Spuren, da kein gewöhnlicher Schreibzugriff auf eine Datei erforderlich ist und die Ausführung ohne sichtbare Abfrage erfolgen kann. Telemetriedaten zu Prozessen, Protokolle über Socket-Zugriffe und Aufzeichnungen der Befehlsausführung können daher hilfreicher sein als die alleinige Überprüfung des Repositorys.

Overpatch hinterlässt mit höherer Wahrscheinlichkeit ein dauerhaftes Artefakt in .zshrc, doch der schädliche Befehl wird möglicherweise erst in der nächsten Terminalsitzung ausgeführt.

Keine Ausnutzung gemeldet

Derzeit gibt es keine Hinweise darauf, dass Angreifer Heapjack oder Overpatch vor der Verfügbarkeit der Fehlerbehebungen gegen Codex-Benutzer eingesetzt haben. Dass die Schwachstellen nicht in gemeldeten Angriffen auftauchen, ändert nichts an der Gefährdung, die durch das Öffnen eines von einem Angreifer kontrollierten Repositorys entsteht.

CVE-Kennungen, CVSS-Bewertungen, Bereiche betroffener Versionen oder Einträge im Katalog der CISA zu bekannten ausgenutzten Schwachstellen wurden nicht gemeldet. Auch die genauen verwundbaren Builds vor den behobenen Versionen sind nicht bekannt.

Entscheidend ist daher die installierte Version: Codex Desktop Build 26.818.21641 und Codex CLI 0.149.0. Jede Installation unterhalb dieser jeweiligen Versionen sollte aktualisiert werden, statt sich zum Schutz allein auf den Nur-Lese- oder Workspace-Write-Modus zu verlassen.