Kleiner Infosplitter, der mir von den Sicherheitsforschern von Check Point Research (CPR) zugegangen ist. Die sind kürzlich in OpenAIs Codex CLI auf die kritische Sicherheitslücke CVE-2025-61260 gestoßen. Diese ermöglichte Angriffe über lokale Projektdateien, stille Code-Ausführung, Infiltration und Datenklau.
Was ist Codex CLI?
Von Check Point Research hatte ich nur gehört, dass Codex CLI das Command Line-Tool von OpenAI sei, das KI-gestützte Programmierfunktionen direkt in Entwickler-Workflows integriert. Ich habe dann noch ein wenig im Web gesucht und die (alte) Codex CLI-Webseite auf GitHub gefunden. Die Seite enthält noch die Dokumentation für die alte TypeScript-Implementierung der Codex-CLI. Sie wurde durch die Rust-Implementierung ersetzt.
Laut Beschreibung wurde Codex CLI für Entwickler geschaffen, die bereits im Terminal arbeiten und ChatGPT-ähnliche Schlussfolgerungen sowie die Möglichkeit wünschen, Code auszuführen, Dateien zu bearbeiten und Iterationen durchzuführen – alles unter Versionskontrolle. Kurz gesagt handelt es sich um eine chatgesteuerte Entwicklung, die ein Repository versteht und ausführt.
Es sei keine Einrichtung erforderlich, einfach den OpenAI-API-Schlüssel eingeben, und schon funktioniert es. Es gebe eine vollautomatische Genehmigung, sicher und geschützt durch Netzwerk-Deaktivierung und Verzeichnis-Sandboxing. Man könne Screenshots oder Diagramme, um Funktionen zu implementieren. Und alles ist vollständig Open Source, sodass Sie die Entwicklung mitverfolgen und dazu beitragen können, heißt es.
Sucht man noch ein wenig weiter, stößt man auf den Beitrag Codex CLI installieren und nutzen: OpenAI's Antwort auf Claude Code, der den Einsatz erklärt. Ein paar Anweisungen im Terminal eintippen und dann wird eine App generiert. Und der Artikel Vibe Coding mit Codex CLI klingt irgendwie auch vielversprechend für OpenAI KI-Nerds. Was soll da schon schief gehen?
Die Schwachstelle CVE-2025-61260
In einer Forschungsinitiative prüfte CPR, ob Codex die von Projekten bereitgestellten Konfigurationen und Umgebungsüberschreibungen, die zur Laufzeit automatisch geladen werden, sicher handhabt. Weiterhin testete CPR, ob Angreifer das automatische Vertrauen des CLI in nicht überprüfte Projektdateien in gemeinsamen Entwicklungsumgebungen ausnutzen können.
Bei Tests haben die Sicherheitsforscher von Check Point Research dann festgestellt, dass Codex CLI automatisch MCP-Servereinträge aus einer projektlokalen Konfiguration lädt und ausführt, wenn Codex innerhalb dieses Repositorys ausgeführt wird, schreiben sie in diesem Artikel. Codex CLI löst seine Konfiguration in diesem lokalen Ordner auf, analysiert die MCP-Definitionen und ruft den deklarierten Befehl/die deklarierten Argumente sofort beim Start auf. Es gibt keine interaktive Genehmigung, keine sekundäre Validierung des Befehls oder der Argumente und keine erneute Überprüfung, wenn sich diese Werte ändern – die CLI behandelt die projektlokale MCP-Konfiguration als vertrauenswürdiges Ausführungsmaterial.
In der Praxis gelang es den Sicherheitsforschern mit deterministischen Payloads (Dateierstellung) und durch Ersetzen harmloser Befehle durch Reverse-Shell-Payloads die Schwachstelle zu demonstrieren. Beide Payloads wurden ohne Benutzeraufforderungen ausgeführt. Da das Verhalten das Vertrauen an das Vorhandensein des MCP-Eintrags unter dem aufgelösten CODEX_HOME und nicht an den Inhalt des Eintrags bindet, kann eine zunächst harmlose Konfiguration nach der Genehmigung oder nach dem Merge gegen eine bösartige ausgetauscht werden, wodurch eine heimliche, reproduzierbare Backdoor in der Lieferkette entsteht, die bei normalen Entwickler-Workflows ausgelöst wird.
Ein erfolgreicher Exploit ermöglicht die Ausführung beliebiger Befehle auf jedem Entwicklerrechner, der ein infiziertes Code-Repository klont und Codex ausführt. Dadurch waren Angriffe über lokale Projektdateien, stille Code-Ausführung, Infiltration und Datenklau möglich. Ein Angreifer mit Commit- oder PR-Zugriff konnte:
- Persistenten Fernzugriff einrichten: Durch eine in ./.codex/config.toml hinterlegte Reverse Shell (plus .env-Umleitung) kann ein Angreifer jedes Mal Zugriff erhalten, wenn ein Entwickler Codex startet.
- Beliebige Befehle unbemerkt ausführen: Jeder in einem MCP-Eintrag definierte Befehl wird automatisch und ohne Hinweis im Nutzerkontext ausgeführt.
- Daten abgreifen und weiter eskalieren: Entwicklerrechner enthalten oft Cloud-Token, SSH-Keys oder Quellcode – ein Angreifer kann diese stehlen, exfiltrieren oder für weitere Angriffe nutzen.
- Schädlichen Code nachträglich austauschen: Da Codex dem Konfigurationspfad vertraut, nicht dem Inhalt, kann ein zunächst harmloser Eintrag später unbemerkt durch einen bösartigen Payload ersetzt werden.
- Über die Software-Lieferkette verbreiten: Manipulierte Templates, Starter-Repos oder Open-Source-Projekte können mit einem einzigen Commit viele Nutzer kompromittieren.
- CI- und Build-Pipelines infizieren: Führen CI/CD-Systeme Codex in kompromittierten Projekten aus, kann sich der Angriff auf Build-Artefakte und Deployments ausweiten.
- Lateral Movement ermöglichen: Mit erbeuteten Zugangsdaten kann ein Angreifer sich innerhalb von Cloud-Umgebungen oder internen Netzwerken weiter ausbreiten.
Oded Vanunu, Chief Technologist und Head of Product Vulnerability Research bei Check Point, kommentiert: "Diese Sicherheitslücke bringt Cyberbedrohungen auf eine neue Ebene. Angreifer müssen nicht mehr in die Infrastruktur eindringen, sondern nutzen einfach das Vertrauensmodell rund um Entwicklungswerkzeuge aus. Wenn ein KI-Tool Dateien ohne Validierung lädt und ausführt, verliert das Unternehmen die Kontrolle über einen seiner routinemäßigsten Prozesse. Unternehmen müssen überprüfen, was in die Pipeline gelangt, und nicht nur, was sie verlässt."
Die Schwachstelle CVE-2025-61260 betrifft OpenAIs Codex CLI vor Version 0.23.0 und zeigt eine neue Art unsichtbarer Lieferketten-Angriffe auf. Check Point Research informierte OpenAI am 7. August 2025 über den Fund.
OpenAI veröffentlichte am 20. August 2025 in Codex CLI v0.23.0 einen Fix, der die automatische Umleitung von CODEX_HOME durch .env-Dateien blockiert und damit den Angriffspfad schließt. Die Details lassen sich im CheckPoint-Artikel CVE-2025-61260 — OpenAI Codex CLI: Command Injection via Project-Local Configuration nachlesen.



MVP: 2013 – 2016




Eine Software welche um zu funktionieren Zugriff auf den kompletten Datenbestand haben muss… was hat man den erwartet?