Claude Code, Gemini CLI, Codex : la même faille à Black Hat

N’importe qui peut ouvrir un ticket public sur GitHub. Un compte gratuit suffit, pas besoin d’accès particulier, pas besoin de confiance préalable. Cette barrière quasi inexistante a suffi à obtenir une exécution de code et le vol d’identifiants dans les outils de codage IA de trois entreprises différentes, avec à chaque fois la même ficelle. Ces découvertes, présentées à Black Hat USA 2026 à Las Vegas, ne racontent pas trois bugs isolés. Elles racontent ce qui se passe quand un outil conçu pour lire du code se met à tout lire, sans plus savoir faire la différence.

Ce que fait vraiment un agent de codage une fois branché sur votre pipeline

Le zero trust, ce principe qui refuse d’accorder une confiance automatique à quoi que ce soit sous prétexte que c’est déjà dans le réseau, est précisément ce que ces outils ignorent par défaut. Un agent de codage est un logiciel qui lit une consigne, décide seul des changements de code ou des commandes nécessaires, puis les exécute, souvent depuis un pipeline d’intégration continue (un système automatisé qui fait tourner du code, des tests et des scripts à chaque modification d’un dépôt, sans qu’un humain ait besoin de cliquer quoi que ce soit). Branchez-en un sur un dépôt de code public, et il peut trier les rapports de bugs, ébaucher des correctifs, répondre aux commentaires ou exécuter des tâches de maintenance tout seul.

Le confort est réel. C’est aussi l’exposition. Un agent connecté à ce genre d’automatisation ne voit pas seulement le code que vous avez écrit. Il voit tout ce qui atterrit sur la surface publique du dépôt : le texte d’un ticket soumis par un inconnu, un commentaire, un fichier de configuration, tout ce qui transite par le pipeline qu’il surveille. Si vous avez branché, ou envisagez de brancher, un assistant de codage sur ce type d’installation, la question à se poser n’est pas de savoir si l’outil est assez intelligent. C’est de savoir s’il sait vraiment distinguer un contenu à résumer d’une instruction à exécuter.

La même confusion, retrouvée trois fois de suite

À Black Hat, des chercheurs de la société de sécurité Novee Security ont présenté une intervention intitulée « Trusted Enough to Run: Breaking AI Agents in Official Workflows ». Ils y détaillent trois agents de codage, de trois éditeurs différents, tombant dans le même piège. Dans chaque cas, un attaquant extérieur, sans aucun droit sur le dépôt, avait glissé des instructions cachées dans un contenu que l’agent traitait de façon routinière, le plus souvent un ticket GitHub public. Quand le pipeline automatisé récupérait ce contenu, l’agent ne le lisait pas comme un rapport de bug. Il l’exécutait comme un ordre. Les chercheurs en sécurité appellent ça une prompt injection (littéralement, une instruction injectée dans le texte que l’agent traite, censée passer inaperçue).

Cette confusion, une fois déclenchée, ouvrait la porte à des conséquences sérieuses : exécuter n’importe quelle commande sur la machine qui fait tourner le pipeline, lire des fichiers et des secrets censés rester privés, ou implanter des instructions qui persisteraient discrètement et seraient rejouées plus tard. Rien de tout cela n’exigeait de deviner un mot de passe ou d’exploiter une faille réseau au préalable. Le point d’entrée était un simple texte public, non authentifié, que le logiciel avait pour mission de traiter automatiquement.

Elad Meged, ingénieur fondateur chez Novee et l’un des chercheurs à l’origine de cette intervention, résume la logique sans détour dans le compte-rendu de l’équipe : ces outils ont été conçus pour être utiles dans l’automatisation, et c’est ce même design qui les a rendus accessibles à quiconque sait écrire du texte dans le bon champ. Le compte-rendu de Novee reste la source la plus précise sur le détail technique, à lire en entier si vous faites tourner l’un de ces produits en intégration continue.

Claude Code : une chaîne qui finit en fuite de données via un simple compteur public

L’outil de codage en ligne de commande d’Anthropic, Claude Code (à ne pas confondre avec l’application de chat Claude), était touché par une faille répertoriée sous le nom CVE-2026-54316, corrigée dans la version 2.1.163. Une CVE, pour Common Vulnerabilities and Exposures, est simplement l’entrée du catalogue public que l’organisme MITRE attribue à chaque faille de sécurité rendue publique, pour que chercheurs, éditeurs et équipes de défense puissent tous parler du même problème avec le même numéro.

Claude Code — l’outil de codage agentique d’Anthropic, utilisable en terminal et dans les pipelines d’intégration continue.

Il faut ici distinguer ce qui est officiellement confirmé de ce que le chercheur décrit en plus. Le texte de la CVE ne nomme qu’un seul mécanisme : un canal d’exfiltration de données, hors bande, en passant par un domaine que l’outil avait pré-approuvé sans restreindre les chemins autorisés dessus. Un attaquant pouvait faire fuiter une clé API volée, caractère par caractère, en détournant le compteur public de téléchargements de modèles de Hugging Face, un chiffre visible par n’importe qui, transformé en canal détourné improbable mais bien fonctionnel. Novee Security, qui a découvert la faille, décrit une chaîne plus longue menant jusqu’à cette étape, avec une injection de commande et un moyen de lire des fichiers arbitraires, mais ce récit plus large n’a pas été confirmé indépendamment par Anthropic : seul le canal d’exfiltration via Hugging Face figure dans la fiche CVE officielle. La faille touchait les versions 0.2.54 à 2.1.162 de Claude Code et a été corrigée en 2.1.163. Anthropic avait déjà publié plusieurs correctifs progressifs, en retirant des règles de permission shell trop larges et en restreignant le domaine Hugging Face, avant même que la CVE ne soit formellement attribuée.

Gemini CLI : une isolation contournable avant même son démarrage

L’outil Gemini CLI de Google (encore une fois, distinct de l’application de chat Gemini ou du modèle sous-jacent) a reçu la note la plus sévère des trois : CVE-2026-12537, avec un score CVSS de 10.0, le maximum possible sur cette échelle. Le CVSS, pour Common Vulnerability Scoring System, est une formule standard de l’industrie qui note la gravité d’une faille de 0 à 10, selon sa facilité d’exploitation et l’ampleur des dégâts possibles. L’avis complet est documenté sous l’identifiant GitHub GHSA-wpqr-6v78-jr5g.

La cause profonde était une injection de commande système dans le lanceur chargé de démarrer le sandbox de l’outil, ce conteneur isolé censé contenir tout ce que fait l’agent. Un fichier de configuration .gemini/.env piégé pouvait déclencher une exécution de code directement sur la machine hôte, avant même que le sandbox ne démarre, ce qui annulait toute l’isolation. Une seconde faille, liée à la première, permettait à un processus enfant censé être confiné de lire les secrets du processus parent, y compris des jetons GitHub et des clés API Gemini, via un fichier système Linux (/proc/$PPID/environ) qui expose les variables d’environnement d’un processus en cours d’exécution. Google a corrigé les deux problèmes dans la version 0.39.1 de Gemini CLI, accompagnée d’une mise à jour d’un outil compagnon, et le correctif inclut un changement volontaire, non rétrocompatible, du niveau de confiance accordé par défaut aux exécutions sans supervision humaine. Le compte-rendu de Novee note que la ligne de package concernée totalisait environ deux millions d’installations mensuelles, ce qui donne une idée de l’ampleur de la configuration déjà en circulation.

Gemini CLI — l’agent IA open source de Google pour le terminal, construit sur l’API Gemini.

Pourquoi Codex n’a reçu aucune CVE pour le même problème de fond

Codex d’OpenAI (l’agent de codage openai/codex, pas ChatGPT) a été concerné par la même recherche et partageait la même faiblesse de fond, sans pour autant recevoir la moindre CVE. La raison en dit plus long qu’elle ne rassure. Ce n’était pas un bug de code au sens classique. C’était un problème de conception du workflow : une automatisation tournait en deux passes, qui partageaient la même copie du dépôt extraite sur le disque. Une première passe pouvait être piégée, là encore via des instructions glissées dans le texte d’un contributeur extérieur, pour écrire un fichier AGENTS.md malveillant, un fichier d’instructions censé guider le comportement de l’agent. Une seconde passe chargeait ensuite ce fichier et l’exécutait, sans qu’aucun privilège particulier ne soit nécessaire à aucun moment de la chaîne.

Codex — l’agent de codage d’OpenAI pour les tâches d’ingénierie logicielle, accessible en ligne de commande et via ChatGPT.

OpenAI a réagi en séparant les deux passes en tâches indépendantes, avec des copies de dépôt distinctes, et en documentant formellement les fichiers d’instructions comme AGENTS.md comme une surface d’entrée non fiable, à traiter avec la même méfiance qu’un commentaire d’inconnu, jamais comme une configuration de confiance. Pas de nouvelle version, pas de CVE, parce que, dans la lecture des chercheurs, il s’agissait d’un comportement déjà existant et documenté, tout juste reconnu comme risqué, et non d’un défaut ayant nécessité un correctif. Cette nuance compte plus qu’il n’y paraît : une CVE numérote un bug précis dans un produit précis. Ce que Black Hat a vraiment mis au jour, c’est un schéma de conception capable de resurgir dans n’importe quel outil construit sur le même modèle, qu’il finisse ou non par recevoir un numéro.

À quoi ressemblait une divulgation responsable, ici

La Cybersecurity and Infrastructure Security Agency (CISA), l’agence gouvernementale américaine qui recense et coordonne la réponse aux failles de sécurité, ne recensait aucune preuve d’exploitation réelle des failles de Claude Code ou de Gemini CLI au 7 août 2026, selon le compte-rendu de The Hacker News sur cette divulgation. Des chercheurs ont trouvé le schéma en premier et l’ont signalé de façon responsable : ce n’était pas une attaque déjà en cours. Les trois éditeurs ont corrigé ou atténué le problème dans les délais habituels de divulgation, et rien de tout cela n’exigeait qu’un utilisateur final ait commis une erreur. L’exposition venait du comportement ordinaire, par défaut, qui consiste à brancher un agent de codage sur des pipelines traitant des entrées publiques non authentifiées — exactement ce que font la plupart des équipes en laissant un agent trier automatiquement les tickets GitHub.

Ce que ça change pour brancher un agent sur votre pipeline

Les numéros de CVE, les scores CVSS et les numéros de version corrigés cités ici vont vite dater, comme toujours. Ce qui ne datera pas, c’est la question qu’ils posent : quand vous branchez un agent de codage sur une automatisation, vous prenez une décision sur une frontière de confiance, pas seulement une décision de confort. Le logiciel lira tout ce que le pipeline lui tend, et à moins que l’outil et son workflow ne soient explicitement conçus pour séparer les instructions de confiance du contenu non fiable, le texte d’un inconnu peut finir par le piloter. C’est le même problème de frontière qu’on retrouve dans un schéma plus large, celui des attaques de la chaîne d’approvisionnement logicielle, où le danger vient rarement d’une intrusion directe, mais de quelque chose déjà présent dans le pipeline et auquel on accorde plus de confiance qu’il ne le mérite. La question de savoir quel référentiel encadre vraiment cette frontière de confiance, et dans quel ordre, mérite d’être creusée à part : voir comment OWASP, MITRE et NIST se répartissent les responsabilités en sécurité IA.

La leçon pratique n’est pas d’éviter les agents de codage IA en intégration continue. C’est de traiter tout contenu accessible depuis l’extérieur de votre organisation, un ticket, un commentaire, un fichier de configuration, comme une entrée à manipuler avec précaution, jamais comme une instruction à exécuter, et de vérifier que le workflow de votre outil applique réellement cette séparation, plutôt que de la supposer acquise.

Questions fréquentes

Qu’est-ce qu’un agent de codage, en termes simples ? Un agent de codage est un logiciel qui lit une demande, décide seul du code ou des commandes nécessaires, et les exécute automatiquement, souvent au sein d’un pipeline qui tourne sans humain présent. Claude Code, Gemini CLI et Codex fonctionnent tous sur ce principe, ce qui explique pourquoi une entrée non fiable qui les atteint pose problème.

Qu’est-ce que la prompt injection, et pourquoi ça compte ici ? La prompt injection, c’est quand des instructions cachées ou déguisées, glissées dans un contenu d’apparence anodine comme un ticket GitHub, sont traitées par un système IA comme des ordres à suivre plutôt que comme un texte à lire. Ça compte parce que ça permet à un attaquant sans aucun privilège de compte d’influencer ce que fait un outil automatisé, simplement en écrivant les bons mots au bon endroit.

Faut-il arrêter d’utiliser Claude Code, Gemini CLI ou Codex en automatisation ? Non, aucun de ces outils n’est structurellement plus cassé qu’un autre : les trois éditeurs ont corrigé ou atténué les problèmes trouvés, et la CISA n’a relevé aucune preuve d’exploitation réelle. La réponse sensée, c’est de vérifier votre propre installation, pas d’abandonner la catégorie, puisque le schéma de fond peut réapparaître dans n’importe quel agent connecté de la même façon.

Pourquoi Codex n’a-t-il pas reçu de CVE si le problème était tout aussi réel ? Une CVE numérote un bug précis dans une version précise d’un produit. Le problème de Codex tenait à la conception du workflow, le partage d’une seule copie de dépôt entre deux passes d’automatisation, pas à un défaut de code. OpenAI a donc corrigé le workflow et documenté le risque, plutôt que de publier un correctif rattaché à un numéro de version.

Que faut-il vraiment vérifier si on utilise l’un de ces agents en intégration continue ? Confirmez que vous êtes sur une version corrigée du produit concerné, vérifiez que les fichiers d’instructions et le contenu non fiable sont bien isolés des étapes à privilèges de votre pipeline, et évitez les architectures où une seule passe peut à la fois recevoir une entrée publique et agir avec des privilèges.

À retenir

Trois éditeurs, trois causes techniques différentes, une même porte d’entrée : un agent de codage, dans un pipeline automatisé, incapable de distinguer le texte d’un inconnu d’un ordre légitime. C’est la leçon durable de cette affaire, celle qui survivra à chaque numéro de version cité dans cet article. Quiconque fait tourner un agent de codage IA en intégration continue devrait considérer la frontière entre « le contenu que le logiciel lit » et « les instructions qu’il exécute » comme quelque chose à vérifier, jamais à supposer, parce que c’est cette frontière, et non le bug d’un éditeur en particulier, qu’un parfait inconnu a traversée trois fois de suite.