Les développeurs qui utilisent le Codex CLI d’OpenAI peuvent, sans le savoir, exécuter des commandes fournies par un attaquant dès qu’ils lancent l’outil dans un dépôt compromis.
Une faille récemment révélée montre comment de simples fichiers de projet comme .env et config.toml peuvent être transformés en vecteurs d’exécution silencieux et reproductibles dans les workflows de développement courants.
Il en résulte une faiblesse de la chaîne d’approvisionnement qui ne nécessite ni ingénierie sociale, ni binaire piégé, ni approbation de l’utilisateur.
La vulnérabilité crée « … une porte dérobée furtive et reproductible dans la chaîne d’approvisionnement, qui se déclenche lors des workflows normaux des développeurs », ont déclaré les chercheurs de Check Point.
La faille de configuration de Codex à l’origine de cette RCE furtive
Au fond, CVE-2025-61260 est une vulnérabilité d’injection de commandes déclenchée par la confiance implicite de Codex envers les fichiers de configuration locaux au projet.
Au démarrage, Codex résout le chemin de configuration, charge les définitions des serveurs MCP et invoque automatiquement la commande et les arguments déclarés.
Le problème est que cela se produit sans validation secondaire, sans confirmation de l’utilisateur et sans nouvelle approbation si la configuration est modifiée ultérieurement.
Cela signifie qu’un attaquant disposant de droits de commit ou de pull request peut :
- Rediriger CODEX_HOME à l’aide d’un fichier .env du projet
- Ajouter un fichier .codex/config.toml contenant une entrée MCP
- Intégrer n’importe quelle commande shell (opérations sur les fichiers, exfiltration d’identifiants, shell inversé, etc.)
Lorsque le développeur clone ou met ensuite à jour le dépôt et exécute codex, la charge utile s’exécute instantanément dans le contexte du développeur.
Dans leur preuve de concept, les chercheurs ont démontré des charges utiles inoffensives (création de fichiers) ainsi que des charges plus dangereuses, comme le lancement d’un shell inversé ou l’ouverture d’applications système.
Comme aucune validation n’a lieu lorsque les entrées sont modifiées, les attaquants peuvent remplacer une configuration inoffensive par une configuration malveillante après la fusion, créant une porte dérobée furtive dans la chaîne d’approvisionnement qui persiste au fil des opérations de développement courantes.
D’un poste de travail à l’ensemble du pipeline
Les conséquences concrètes de la vulnérabilité dépassent le cadre d’un seul poste de travail compromis.
Les environnements de développement contiennent généralement des actifs de grande valeur — identifiants cloud, clés SSH, jetons d’API, accès aux registres de conteneurs et code source — ce qui en fait des cibles privilégiées dès qu’un attaquant a pris pied.
Une commande malveillante qui s’exécute silencieusement au démarrage peut fournir un accès distant persistant chaque fois que Codex est lancé, permettre l’exfiltration de secrets de développeurs et de code interne sensibles, et autoriser des déplacements latéraux vers des services cloud ou des réseaux sur site.
Le risque ne s’arrête pas là : les dépôts empoisonnés peuvent se propager via des modèles open source, des projets de démarrage ou des forks, tandis que les systèmes d’intégration continue qui exécutent Codex pendant les builds peuvent contaminer involontairement les pipelines et les artefacts en aval.
Comme le vecteur d’attaque est un commit de dépôt standard, une seule charge utile malveillante peut se propager rapidement entre les équipes, les contributeurs et les projets dépendants, amplifiant l’ampleur des dommages dans l’ensemble de la chaîne d’approvisionnement logicielle.
Renforcer la sécurité de Codex dans les environnements à haut risque
Comme Codex fait automatiquement confiance aux fichiers locaux au projet, les entreprises doivent mettre en place des contrôles plus stricts concernant les modalités et les environnements d’utilisation de l’outil.
- Auditer les dépôts à la recherche de fichiers de configuration Codex suspects, notamment les fichiers .env qui redéfinissent CODEX_HOME et les répertoires .codex inattendus.
- Restreindre ou désactiver les configurations Codex locales au projet et exiger des sources de configuration centralisées et approuvées.
- Imposer une hygiène stricte des pull requests et des commits afin de signaler et d’examiner tout fichier de configuration ou d’environnement susceptible de déclencher l’exécution de code.
- Surveillez l’activité anormale de Codex en journalisant les commandes shell, les modifications du système de fichiers et le trafic réseau sortant associés à Codex.
- Révoquer et renouveler tous les identifiants de développeurs exposés, les jetons et les clés SSH, et réduire la dépendance aux secrets persistants.
- Exécuter Codex dans des environnements en bac à sable ou à privilèges minimaux tels que des conteneurs de développement isolés ou des postes de travail verrouillés.
- Intégrer l’utilisation de Codex à la gouvernance de la sécurité de l’entreprise en établissant des politiques d’utilisation, en formant les développeurs aux risques et en acheminant la télémétrie de Codex vers les outils SIEM et EDR.
Ces mesures d’atténuation aident les entreprises à se protéger contre l’exécution silencieuse de code, à protéger leurs identifiants et à renforcer leurs défenses de la chaîne d’approvisionnement.
Comment l’automatisation élargit la surface d’attaque
CVE-2025-61260 met en évidence une évolution plus large du paysage des menaces : les outils de développement enrichis par l’IA créent de nouvelles frontières de confiance que les attaquants apprennent rapidement à exploiter.
À mesure que les outils automatisent davantage la lecture, la modification et l’exécution du code, toute confiance implicite accordée aux métadonnées fournies par un projet devient un puissant vecteur d’attaque.
Dans ce nouvel environnement, les compromissions de la chaîne d’approvisionnement ne se limitent plus aux binaires malveillants : les fichiers de configuration, les variables d’environnement et les métadonnées de workflow deviennent des cibles privilégiées.
À mesure que l’automatisation du développement s’accélère, les entreprises doivent reconnaître que le maillon le plus faible de la chaîne pourrait désormais être constitué des fichiers qui orientent ces outils pilotés par l’IA, et non du code qu’ils produisent au final.
La sécurité complète de la chaîne d’approvisionnement logicielle est devenue.