Entwickler, die OpenAI’s Codex-CLI verwenden, führen möglicherweise unwissentlich von Angreifern bereitgestellte Befehle aus, sobald sie das Tool in einem kompromittierten Repository starten.
Eine neu offengelegte Schwachstelle zeigt, wie einfache Projektdateien wie .env und config.toml in alltäglichen Entwicklungs-Workflows in stille, reproduzierbare Ausführungsvektoren verwandelt werden können.
Das Ergebnis ist eine Schwachstelle in der Lieferkette, die kein Social Engineering, keine manipulierten Binärdateien und keine Zustimmung des Benutzers erfordert.
Die Schwachstelle schafft „… eine verdeckte, reproduzierbare Hintertür in der Lieferkette, die bei normalen Entwickler-Workflows ausgelöst wird“, sagten die Forscher von Check Point.
Die Codex-Konfigurationsschwachstelle hinter dieser verdeckten RCE
Im Kern ist CVE-2025-61260 eine Command-Injection-Schwachstelle, die durch Codex’ implizites Vertrauen in lokale Konfigurationsdateien des Projekts ausgelöst wird.
Beim Start ermittelt Codex den Pfad zur Konfiguration, lädt die Definitionen der MCP-Server und ruft automatisch den angegebenen Befehl und die Argumente auf.
Das Problem: Dies geschieht ohne nachgelagerte Validierung, ohne Bestätigung durch den Benutzer und ohne erneute Genehmigung, wenn die Konfiguration später geändert wird.
Das bedeutet, dass ein Angreifer mit Berechtigungen zum Committen oder Erstellen von Pull Requests Folgendes tun kann:
- Über CODEX_HOME mithilfe einer projektweiten .env-Datei umleiten
- Eine .codex/config.toml-Datei mit einem MCP-Eintrag hinzufügen
- Beliebige Shell-Befehle einbetten (Dateioperationen, das Abgreifen von Zugangsdaten, eine Reverse Shell usw.)
Wenn der Entwickler das Repository später klont oder aktualisiert und codex startet, wird die Nutzlast sofort im Kontext des Entwicklers ausgeführt.
In ihrem Proof of Concept demonstrierten die Forscher sowohl harmlose Nutzlasten (das Erstellen von Dateien) als auch gefährlichere Varianten, etwa das Starten einer Reverse Shell oder das Öffnen von Systemanwendungen.
Da beim Ändern von Einträgen keine Validierung erfolgt, können Angreifer nach dem Mergen eine harmlose Konfiguration durch eine bösartige ersetzen und so eine verdeckte Hintertür in der Lieferkette schaffen, die bei routinemäßigen Entwicklungsoperationen bestehen bleibt.
Von einer einzelnen Workstation zur gesamten Pipeline
Die Auswirkungen der Schwachstelle in der Praxis gehen über eine einzelne kompromittierte Workstation hinaus.
In Entwicklerumgebungen liegen typischerweise wertvolle Ressourcen – Cloud-Zugangsdaten, SSH-Schlüssel, API-Token, Zugriff auf Container-Registries und Quellcode –, was sie zu bevorzugten Zielen macht, sobald ein Angreifer Fuß gefasst hat.
Ein bösartiger Befehl, der beim Start unbemerkt ausgeführt wird, kann bei jeder Ausführung von Codex dauerhaften Fernzugriff ermöglichen, das Abgreifen vertraulicher Geheimnisse von Entwicklern und internem Code erlauben und laterale Bewegungen in Cloud-Dienste oder lokale Netzwerke ermöglichen.
Das Risiko endet dort nicht: Manipulierte Repositorys können sich über Open-Source-Vorlagen, Starterprojekte oder Forks verbreiten, während CI-Systeme, die Codex während Builds ausführen, Pipelines und nachgelagerte Artefakte unbeabsichtigt kontaminieren können.
Da der Angriffsvektor aus einem gewöhnlichen Repository-Commit besteht, kann sich eine einzelne bösartige Nutzlast schnell über Teams, Mitwirkende und abhängige Projekte verbreiten und so die Reichweite des Angriffs auf die gesamte Software-Lieferkette vergrößern.
Codex in Hochrisikoumgebungen absichern
Da Codex lokalen Dateien des Projekts automatisch vertraut, müssen Organisationen stärkere Kontrollen dafür einführen, wie und wo das Tool eingesetzt wird.
- Repositorys auf verdächtige Codex-Konfigurationsdateien prüfen, einschließlich .env-Dateien, die CODEX_HOME überschreiben, und unerwarteter .codex-Verzeichnisse.
- Projektlokale Codex-Konfigurationen einschränken oder deaktivieren und zentrale, genehmigte Konfigurationsquellen vorschreiben.
- Strenge Regeln für Pull Requests und Commits durchsetzen, um alle Konfigurations- oder Umgebungsdateien zu markieren und zu prüfen, die Codeausführung auslösen könnten.
- Überwachen Sie auf anomale Codex-Aktivitäten durch die Protokollierung von Shell-Befehlen, Dateisystemänderungen und aus Codex hervorgehendem Datenverkehr nach außen.
- Alle offengelegten Zugangsdaten, Token und SSH-Schlüssel von Entwicklern widerrufen und rotieren, und die Abhängigkeit von langlebigen Geheimnissen verringern.
- Codex in Sandbox- oder Umgebungen mit minimalen Berechtigungen ausführen wie isolierten Entwickler-Containern oder stark eingeschränkten Workstations.
- Die Nutzung von Codex in die Sicherheits-Governance des Unternehmens integrieren durch die Festlegung von Nutzungsrichtlinien, die Schulung von Entwicklern zu Risiken und die Weiterleitung der Codex-Telemetrie an SIEM- und EDR-Tools.
Diese Maßnahmen helfen Organisationen, sich vor unbemerkter Codeausführung zu schützen, Zugangsdaten zu sichern und die Abwehr in der Lieferkette zu stärken.
Wie Automatisierung die Angriffsfläche vergrößert
CVE-2025-61260 verdeutlicht eine umfassendere Entwicklung in der Bedrohungslandschaft: KI-gestützte Entwickler-Tools schaffen neue Vertrauensgrenzen, deren Ausnutzung Angreifer rasch erlernen.
Da Tools zunehmend das Lesen, Ändern und Ausführen von Code automatisieren, wird jedes implizite Vertrauen in vom Projekt bereitgestellte Metadaten zu einem mächtigen Angriffsvektor.
In dieser neuen Umgebung beschränken sich Kompromittierungen der Lieferkette nicht mehr auf bösartige Binärdateien – Konfigurationsdateien, Umgebungsvariablen und Workflow-Metadaten werden zu bevorzugten Zielen.
Da die Automatisierung der Entwicklung immer schneller voranschreitet, müssen Organisationen erkennen, dass das schwächste Glied der Kette nun möglicherweise die Dateien sind, die diese KI-gestützten Tools steuern, und nicht der Code, den sie letztlich erzeugen.
Solche Entwicklungen zeigen, wie wichtig eine umfassende Sicherheit der Software-Lieferkette geworden ist.