Sicherheitsforscher entdeckten zwei Möglichkeiten, aus der OpenAI-Codex-Sandbox auszubrechen und auf Ressourcen des Hostcomputers zuzugreifen. OpenAI soll beide Sicherheitslücken innerhalb von acht Tagen behoben haben. Eine davon ermöglichte jedoch die Ausführung von Befehlen aus dem strengsten Sandbox-Modus heraus.
Forscher entdecken zwei Codex-Sicherheitslücken
Oren Yomtov von Accomplish AI und weitere Forscher meldeten beide Sicherheitslücken am 12. August an OpenAI.
Die erste Technik namens Heapjack betraf eine Komponente, die Codex Desktop und Codex CLI verwendeten. Laut den Forschern konnte sie Befehle außerhalb der Sandbox ausführen, ohne eine Genehmigung anzufordern oder sichtbare Aktivitäten anzuzeigen.
Die zweite Sicherheitslücke namens Overpatch ermöglichte es dem Patch-Tool von Codex, außerhalb des zulässigen Projektverzeichnisses zu schreiben.
OpenAI behob Heapjack in Codex Desktop Build 26.818.21641. Overpatch beseitigte das Unternehmen unterdessen in Codex CLI Version 0.149.0.
Benutzer sollten diese oder spätere Versionen installieren.
Heapjack zielt auf gemeinsam genutzten Speicher
Heapjack zielte auf eine Komponente namens node_repl. Codex Desktop fügte die Komponente während der Installation der globalen Codex-Konfigurationsdatei hinzu.
Laut den Forschern mussten Benutzer die Funktion nicht manuell aktivieren. Darüber hinaus ermöglichte die globale Konfiguration den Benutzern von Codex CLI, das Tool zu übernehmen.
Die Komponente führte einen einzelnen Node.js-Prozess mit zwei JavaScript-Ausführungskontexten aus. Ein vertrauenswürdiger Kontext enthielt den Code von OpenAI, während ein nicht vertrauenswürdiger Kontext den Code des Agenten verarbeitete.
Der vertrauenswürdige Kontext authentifizierte sich mit einem zufälligen Token, das bei jeder Sitzung erstellt wurde. Beide Kontexte arbeiteten jedoch innerhalb desselben Node.js-Prozesses und teilten sich denselben Heap-Speicher.
Dadurch konnte der nicht vertrauenswürdige Kontext den gemeinsam genutzten Speicher nach dem Authentifizierungstoken durchsuchen.
Nicht vertrauenswürdiger Code findet das geheime Token
Die Forscher nutzten eine Node.js-Funktion, um eine Momentaufnahme des Prozessspeichers zu erstellen.
Anschließend suchte der nicht vertrauenswürdige Code nach Zeichenfolgen, die dem erwarteten Tokenformat entsprachen. Er übermittelte mögliche Token und beobachtete die Antworten.
Ein falsches Token verursachte einen Autorisierungsfehler. Das richtige Token gab in Verbindung mit einem ungültigen Argument jedoch eine andere Validierungsantwort zurück.
Dieser Verhaltensunterschied bestätigte, wann der Code das gültige Token identifiziert hatte.
Der Angriff konnte anschließend eine eigene Anfrage in den Kommunikationskanal schreiben, den der vertrauenswürdige Kontext nutzte. Dieser Kanal stellte eine Verbindung zu einem nativen übergeordneten Prozess her, der außerhalb der Sandbox lief.
Da die Anfrage das gültige Token enthielt, akzeptierte der übergeordnete Prozess sie als vertrauenswürdig.
Heapjack ermöglicht Befehlsausführung auf dem Hostsystem
Der Proof of Concept für Heapjack nutzte den Befehl open des Hostsystems, um eine Anwendung zu starten.
Diese Anwendung lief außerhalb des Prozessbaums von Codex. Daher konnte die Sandbox ihre Aktivitäten nicht mehr kontrollieren.
Laut den Forschern konnte derselbe Zugriff Unix-Sockets und andere Ressourcen auf dem Hostsystem erreichen. Zu möglichen Zielen gehörten Sockets des Docker-Daemons und Tools, welche die globale Codex-Konfiguration verändern.
Der Angriff funktionierte Berichten zufolge im schreibgeschützten Modus, der die strengsten Sandbox-Beschränkungen bietet. In diesem Modus sollte der Agent weder Dateien schreiben noch Befehle außerhalb seiner isolierten Umgebung ausführen können.
Der Ausbruch aus der Codex-Sandbox untergrub somit den zentralen Schutzmechanismus, der nicht vertrauenswürdige Repository-Inhalte eindämmen sollte.
Schädliches Repository könnte Heapjack auslösen
Die Forscher beschrieben ein Szenario mit einem schädlichen Software-Repository.
Ein Entwickler könnte das Repository einer anderen Person in Codex öffnen und dem Agenten eine gewöhnliche Frage zum Code stellen. Versteckte Anweisungen innerhalb des Repositorys könnten den Agenten anschließend beeinflussen.
Diese Anweisungen könnten Codex dazu veranlassen, Heapjack auszunutzen. Dadurch könnte der Ersteller des Repositorys möglicherweise Befehle außerhalb der Sandbox auf dem Computer des Entwicklers ausführen.
Der Entwickler müsste die Aktion nicht genehmigen. Darüber hinaus zeigte die Benutzeroberfläche während des Angriffs möglicherweise keine sichtbare Warnung an.
Dieser Angriffsweg machte die Sicherheitslücke besonders schwerwiegend. Entwickler nutzen Coding-Agenten häufig, um unbekannte Repositorys zu untersuchen, Fehler in Projekten zu beheben und Quellcode zu erklären.
Overpatch umgeht Workspace-Beschränkungen
Der zweite Ausbruch aus der Codex-Sandbox namens Overpatch betraf die quelloffene Codex CLI.
Im Workspace-Write-Modus kann Codex Dateien innerhalb des aktiven Projektverzeichnisses verändern. Die Sandbox sollte jedoch Versuche blockieren, Dateien an anderen Orten zu schreiben.
Ein direkter Shell-Befehl, der auf das Home-Verzeichnis des Benutzers abzielt, sollte beispielsweise fehlschlagen.
Die Forscher stellten fest, dass das Codex-Tool apply_patch diese Einschränkung umgehen konnte. Das Tool berechnete seine eigenen Schreibberechtigungen anhand der in einem Patch enthaltenen Pfade.
Wenn ein Patch auf ein Verzeichnis verwies, gewährte das System Zugriff auf das übergeordnete Verzeichnis dieses Pfads. Daher konnte ein sorgfältig ausgewählter Pfad den zulässigen Bereich erweitern.
Patch-Exploit erreicht das Home-Verzeichnis
Die Forscher erstellten einen Patch mit zwei Änderungen.
Die erste Änderung verwies auf ein temporäres Verzeichnis. Obwohl sie keine bedeutende Veränderung vornahm, erweiterte sie den Bereich, auf den das Patch-Tool zugreifen konnte.
Die zweite Änderung zielte auf einen symbolischen Link ab, der in das Home-Verzeichnis des Benutzers führte. Über diesen Link fügte der Patch der Konfigurationsdatei .zshrc einen Befehl hinzu.
Ohne die erste Änderung lehnte die Sandbox den Schreibvorgang ab. Die Kombination beider Änderungen ermöglichte jedoch die erfolgreiche Ausführung.
Die schädliche Zeile wurde anschließend außerhalb der Sandbox ausgeführt, sobald der Entwickler eine neue Terminalsitzung öffnete.
Anders als Heapjack erforderte Overpatch den Workspace-Write-Modus. Dennoch überschritt der Angriff eine Grenze, die Änderungen auf den Projektordner beschränken sollte.
Beide Sicherheitslücken haben dasselbe Designproblem
Heapjack und Overpatch betrafen unterschiedliche Komponenten. Die Forscher identifizierten jedoch einen gemeinsamen Sicherheitsfehler.
In beiden Fällen vertraute das System Informationen, die aus der Umgebung heraus kontrolliert wurden, welche es eigentlich beschränken sollte.
Das Patch-Tool berechnete Berechtigungen anhand von Pfaden, die der Angreifer kontrollierte. node_repl speicherte sein Authentifizierungsgeheimnis unterdessen in einem Speicherbereich, den es mit nicht vertrauenswürdigem Code teilte.
Die geschützte Komponente wirkte somit an der Entscheidung mit, ob eine Aktion ihre eigene Sicherheitsgrenze überschreiten durfte.
Ein stärkeres Design würde die Grenze durch einen separaten Prozess oder eine separate Komponente durchsetzen. Nicht vertrauenswürdiger Code sollte weder auf das Geheimnis zugreifen noch die Daten kontrollieren können, die zur Berechnung von Berechtigungen dienen.
KI-Coding-Agenten sind umfassenderen Sandbox-Risiken ausgesetzt
Die Erkenntnisse zum Ausbruch aus der Codex-Sandbox spiegeln eine umfassendere Herausforderung für KI-Coding-Tools wider.
Coding-Agenten interagieren regelmäßig mit nicht vertrauenswürdigen Quelldateien, Konfigurationsdaten und Projektanweisungen. Gleichzeitig benötigen sie genügend Systemzugriff, um Tests auszuführen und Code zu verändern.
Angreifer können diese Kombination durch schädliche Repositorys missbrauchen. Versteckte Anweisungen könnten einen Agenten dazu bringen, Dateien zu erstellen oder vertrauenswürdige Tools außerhalb seiner Sandbox auszulösen.
Forscher demonstrierten im Juli 2026 ähnliche Techniken gegen mehrere Coding-Agenten. Diese Angriffe hielten den Agenten innerhalb seiner Sandbox, erstellten jedoch Dateien, die vertrauenswürdige externe Tools später ausführten.
Daher reicht es möglicherweise nicht aus, nur den Agenten abzusichern. Entwickler müssen ebenfalls berücksichtigen, wie Aktionen innerhalb der Sandbox mit Software interagieren, die auf dem Hostsystem läuft.
Codex-Benutzer sollten sofort aktualisieren
OpenAI behob beide Sicherheitslücken Berichten zufolge innerhalb von acht Tagen nach Eingang des Forscherberichts.
Benutzer sollten Codex Desktop auf Build 26.818.21641 oder eine spätere Version aktualisieren. Außerdem sollten sie Codex CLI Version 0.149.0 oder eine neuere Version installieren.
Entwickler sollten beim Öffnen unbekannter Repositorys mit KI-Coding-Agenten besonders vorsichtig sein. Ein Projekt kann schädliche Anweisungen enthalten, selbst wenn sein Quellcode harmlos erscheint.
Ein aktueller Codex-Versionsstand schließt die beiden gemeldeten Sicherheitslücken. Entwickler sollten nicht vertrauenswürdige Repositorys jedoch weiterhin als potenziell gefährliche Inhalte behandeln.
0 Kommentare zu „Forscher brechen aus der OpenAI-Codex-Sandbox aus und führen Befehle auf dem Hostsystem aus“