Heapjack zielt laut Yomtovs Beschreibung auf eine Komponente namens node_repl, die Codex Desktop bei der Installation in die globale Datei „~/.codex/config.toml" schreibt. Es gibt weder eine Zustimmungsabfrage noch eine Option zum Abschalten — und weil der Eintrag in der gemeinsam genutzten Konfiguration liegt, erben auch reine Nutzer der Codex CLI dasselbe Werkzeug, ohne je gefragt worden zu sein.
node_repl betreibt einen einzigen Node.js-Prozess mit zwei getrennten JavaScript-Ausführungskontexten: einem vertrauenswürdigen mit OpenAIs eigenem Code und einem nicht vertrauenswürdigen, in dem der Code des Agenten läuft. Der vertrauenswürdige Kontext weist sich über ein zufälliges, bei jedem Start neu erzeugtes Token aus. Das Problem: Beide Kontexte teilen sich denselben Speicher-Heap, das Token ist also nichts weiter als eine Zeichenkette, die die nicht vertrauenswürdige Seite auslesen kann.
Der untrusted Code erzeugt mit „v8.getHeapSnapshot()" eine Momentaufnahme des Heaps und probiert jede Zeichenkette durch, die wie eine UUID aussieht. Ein falscher Versuch liefert „nicht autorisiert" zurück; ein korrektes Token mit ungültigem Argument erzeugt dagegen einen echten Validierungsfehler — und verrät dem Angreifer damit den Treffer.
Mit dem Token schreibt der Code eigene Anfragen auf dieselbe Leitung, über die der vertrauenswürdige Kontext mit einem nativen, nicht eingesperrten Elternprozess kommuniziert. Dieser prüft das Token, hält es für gültig und führt die Arbeit aus. Der Proof of Concept nutzte den Systembefehl „open", um eine Anwendung vollständig außerhalb des Prozessbaums von Codex zu starten. Derselbe Zugriff erreicht jeden Unix-Socket — ein Docker-Daemon-Socket ist das naheliegende Ziel — sowie ein Werkzeug zum Bearbeiten der globalen Konfigurationsdatei. All das funktioniert im Modus „read-only", der strengsten Sandbox-Stufe, in der der Agent überhaupt nichts schreiben dürfte.
Die zweite Schwachstelle, Overpatch, steckt in der quelloffenen Codex CLI. Im Modus „workspace-write" darf der Agent nur innerhalb des Projektordners schreiben, ein auf das Home-Verzeichnis gerichteter Shell-Befehl wird abgelehnt. Die Forscher brachten Codex’ eigenes Patch-Werkzeug apply_patch dazu, es trotzdem zu tun: Das Tool gewährt Schreibrechte für den übergeordneten Ordner jedes im Patch genannten Pfads. Wer „/tmp" nennt, erhält Schreibrechte auf die Wurzel der Platte.
Der funktionierende Exploit kombiniert zwei Änderungen: eine, die lediglich „/tmp" nennt und damit die Berechtigung ausweitet, und eine zweite, die über einen Symlink eine Zeile an die „.zshrc" im Home-Verzeichnis anhängt. Ohne die erste Änderung wird der Schreibvorgang verweigert; mit ihr führt das nächste geöffnete Terminal die Zeile des Angreifers außerhalb der Sandbox aus.
Beiden Fehlern liegt dasselbe Muster zugrunde: Der Durchsetzungsmechanismus lebte in genau dem Bereich, den er kontrollieren sollte. apply_patch leitete seine Rechte aus Angreifer-Eingaben ab, node_repl bewahrte das Geheimnis zwischen vertrauenswürdigem und nicht vertrauenswürdigem Code im selben Speicher auf.
Neu ist die Fehlerklasse nicht: Im Juli 2026 zeigten Forscher von Pillar Security dieselbe Idee bei Cursor, Codex, Gemini CLI und Googles Antigravity — ein Agent bleibt in seiner Sandbox, schreibt aber eine Datei, die ein vertrauenswürdiges Werkzeug außerhalb später ausführt.
In Reaktionen auf Yomtovs Beitrag auf X hieß es, V8-Kontexte isolierten globale Variablen, nicht den Speicher, die Sandbox sei daher „ein Versprechen gewesen, dem der Heap nie zugestimmt hat"; ein anderer Kommentator nannte die Vertrauensgrenze „eine Raumteiler-Wand". Kritik gab es auch daran, dass die Funktion standardmäßig aktiv ist und ein privilegiertes Token überhaupt aus nicht vertrauenswürdigem JavaScript erreichbar war.
Laut Accomplish behob OpenAI Heapjack in Codex Desktop Build 26.818.21641 und Overpatch in Codex CLI 0.149.0. Nutzer sollten auf diese oder neuere Versionen aktualisieren. BleepingComputer bat OpenAI vor Veröffentlichung um eine Stellungnahme.