Les chercheurs ont découvert que les fichiers .env contenus dans des référentiels clonés pouvaient être utilisés pour modifier le chemin du répertoire de base de la CLI Codex et charger un fichier de configuration malveillant conduisant à l’exécution de commandes arbitraires.
Dans un nouvel exemple de la façon dont les outils d’IA élargissent la surface d’attaque des machines de développement, les chercheurs ont découvert une grave faille d’exécution de code à distance dans la CLI Codex d’OpenAI, l’un des agents de codage basés sur LLM les plus populaires.
« Cette vulnérabilité permet une exécution de code à distance silencieuse et reproductible dans n’importe quel environnement dans lequel les développeurs exécutent du codex sur un référentiel », ont déclaré les chercheurs de la société de sécurité CheckPoint, qui ont découvert la faille, dans leur rapport. « En abusant du chargement de la configuration locale du projet, un attaquant capable d’effectuer un commit ou un PR peut transformer un dépôt par ailleurs innocent en une porte dérobée persistante qui se déclenche chaque fois qu’un développeur exécute un codex, sans invites ni approbations supplémentaires. »
La vulnérabilité a été signalée à OpenAI et a été corrigée dans la version 0.23.0 du Codex CLI en empêchant les fichiers .env de rediriger silencieusement la variable d’environnement CODEX_HOME vers des emplacements contrôlés par les attaquants.
Tromper le Codex pour exécuter des entrées MCP malveillantes
Comme tous les agents de codage assistés par l’IA, Codex dispose de privilèges puissants puisqu’il doit pouvoir lire, modifier et exécuter du code directement depuis le terminal. Dans le mode par défaut, l’outil peut effectuer des tâches sans approbation dans le répertoire de travail, mais les utilisateurs peuvent le modifier en lecture seule ou en accès complet.
Permettre à l’outil d’exécuter des commandes et de modifier des fichiers dans un répertoire contrôlé peut ne pas sembler trop risqué à première vue, mais les chercheurs de CheckPoint ont trouvé un moyen créatif d’en abuser.
Premièrement, comme de nombreux agents d’IA, Codex prend en charge le Model Context Protocol (MCP). Développé par la société d’IA Anthropic, MCP est devenu la méthode industrielle de facto permettant de relier les LLM à des sources de données et des applications externes. En d’autres termes, il s’agit d’un élément de base pour créer des agents d’IA autonomes capables de découvrir et d’utiliser automatiquement des outils tiers.
Codex CLI charge et exécute les serveurs MCP configurés au démarrage en vérifiant les entrées mcp_servers dans son fichier de configuration .codex/config.toml. Si un attaquant parvient à modifier ce fichier, il peut forcer Codex à exécuter des commandes malveillantes en ajoutant une entrée de serveur MCP malveillant à la liste.
Codex recherchera son fichier de configuration dans son répertoire personnel, et ce répertoire est défini via une variable d’environnement appelée CODEX_HOME. Les chercheurs se sont demandés si cette variable pouvait être remplacée lors de l’analyse des fichiers .env inclus dans un référentiel, car l’inclusion de tels fichiers dans des projets n’est pas inhabituelle.
Les chercheurs ont découvert qu’un référentiel pouvait avoir un fichier .env qui définit CODEX_HOME sur un chemin de la forme ./.codex, essentiellement le dossier .codex à partir du répertoire de travail actuel – le répertoire du référentiel lui-même. De plus, si le référentiel dispose alors d’un fichier config.toml dans le répertoire .codex, l’agent Codex le traitera comme son propre fichier de configuration et analysera les entrées mcp_servers.
« Comme le comportement lie la confiance à la présence de l’entrée MCP sous le CODEX_HOME résolu plutôt qu’au contenu de l’entrée, une configuration initialement inoffensive peut être remplacée par une configuration malveillante après l’approbation ou après la fusion, créant une porte dérobée furtive et reproductible de la chaîne d’approvisionnement qui se déclenche sur les flux de travail normaux des développeurs », ont déclaré les chercheurs.
Les chercheurs ont démontré cette attaque en remplaçant les commandes inoffensives dans les entrées du serveur MCP par des commandes permettant de créer des fichiers ou d’ouvrir un shell inversé sur la machine. Ces commandes ont été exécutées sans l’approbation de l’utilisateur dans la configuration par défaut.
Plusieurs vecteurs d’attaque
Pour que cette faille soit exploitée, la victime doit cloner le référentiel et exécuter le Codex dessus et un attaquant doit avoir un accès de validation au référentiel ou faire accepter sa demande d’extraction malveillante.
« Les modèles compromis, les dépôts de démarrage ou les projets open source populaires peuvent transformer de nombreux consommateurs en aval avec un seul commit », préviennent les chercheurs.
De plus, les outils CI ou les agents de build exécutent automatiquement Codex sur le code extrait, la compromission pourrait se propager depuis un poste de travail de développeur vers les artefacts de build et les déploiements en aval du code.
Les machines de développement contiennent souvent des jetons API pour divers services cloud, ainsi que des clés SSH et du code source propriétaire, qui peuvent tous être exfiltrés et abusés pour migrer latéralement vers des actifs supplémentaires.
« Cela brise les limites de sécurité attendues de la CLI : les fichiers fournis par le projet deviennent un matériau d’exécution fiable, et cette confiance implicite peut être exploitée avec un minimum d’effort et sans aucune interaction de l’utilisateur au-delà du flux de développement standard », ont découvert les chercheurs.
Alors que Codex CLI bloque désormais la redirection locale du projet de la variable d’environnement CODEX_HOME, l’incident souligne que de tels oublis de sécurité peuvent exister même dans les agents créés par les principales sociétés d’IA. La semaine dernière, des chercheurs ont mis en garde contre une faille qui permet aux instructions d’un référentiel cloné de s’échapper des limites de l’espace de travail actuel dans le nouvel outil IDE Antigravity de Google, alimenté par l’IA. Plus tôt ce mois-ci, une autre équipe de chercheurs a montré comment des serveurs MCP malveillants peuvent prendre le contrôle du navigateur intégré de Cursor et potentiellement compromettre complètement la machine du développeur.
Les organisations qui permettent à leurs développeurs de travailler avec des agents de codage d’IA et des outils IDE doivent avoir des politiques en place concernant le niveau d’automatisation avec lequel ces outils sont configurés, car ils peuvent facilement devenir de puissantes portes dérobées en cas de vulnérabilités ou de mauvaises configurations. Les experts en sécurité ont mis en garde à plusieurs reprises contre l’utilisation de modes entièrement automatisés qui ne nécessitent pas d’examen ni d’approbation humaine des étapes d’exécution.
