Ces derniers mois, les agents de codage et leurs outils en ligne de commande ont pris de l’ampleur. Mais une recherche récente met en lumière un point sensible : quand l’IA influence le contenu qui circule entre un dépôt, un exécuteur et une workflow CI, une faille dans le « chaînage » peut suffire à faire fuiter des informations.
Selon une enquête menée par Novee Security et présentée à Black Hat USA le 5 août, des issues GitHub ouvertes par un compte ne disposant pas de privilèges sur les dépôts d’agents pouvaient déclencher des scénarios dangereux sur des runners d’intégration continue. Deux types de risques ressortent : l’exécution de code côté hôte avant la mise en bac à sable et, pour failles Claude Code, une exfiltration d’une clé API via un compteur de téléchargements public. Les deux axes ont été corrigés.
Pourquoi une issue GitHub peut devenir une porte d’entrée
L’idée centrale de l’étude est simple : la sécurité ne dépend pas seulement de l’agent lui-même, mais aussi de tout le chemin entre « ce que l’agent reçoit » et « ce que la plateforme exécute ». En pratique, une issue peut porter des entrées non fiables, et la configuration par défaut de certains dépôts d’agents peut les transformer en actions.
Novee Security a testé les configurations telles qu’elles sont livrées par chaque éditeur pour leurs dépôts d’agents. Le résultat : une partie de la logique qui décide ce qui peut être exécuté n’empêchait pas correctement certains contenus, laissant la possibilité d’atteindre des secrets présents dans l’environnement CI.
Gemini CLI : injection de commande et exécution avant le bac à sable
La partie la plus sévère côté Gemini CLI concerne une injection de commande dans le lanceur de conteneur. Le problème, référencé CVE-2026-12537, possède un score CVSS v4 de 10.0.
Le mécanisme décrit s’appuie sur un fichier .gemini/.env préparé de manière malveillante. L’attaque peut alors permettre à un attaquant non privilégié d’exécuter du code sur l’hôte d’une plateforme CI headless avant le démarrage du bac à sable. Autrement dit, la protection attendue arrive trop tard dans la chaîne.
Le correctif a été intégré dans Gemini CLI 0.39.1 et run-gemini-cli 0.1.22. La recommandation est claire : mettez ces versions à jour pour fermer ce chemin d’exploitation.
Failles Claude Code : exfiltration via un compteur de téléchargements
Dans le cas de Claude Code, la recherche aboutit à une vulnérabilité nommée CVE-2026-54316. L’angle est différent : au lieu d’exécuter du code directement via une injection, l’attaque détourne un canal de sortie existant.
D’après Novee Security, la faille permettait de transformer un compteur de téléchargements public côté Hugging Face en vecteur d’exfiltration. L’information pouvait être divulguée caractère par caractère, notamment une clé API.
Le correctif a été publié dans Claude Code 2.1.163. La source indique également que toutes les versions de Claude Code à partir de 0.2.54 jusqu’à 2.1.163 sont concernées. Côté conditions d’exploitation, Anthropic précise que l’attaque nécessitait d’insérer un contenu non fiable dans le contexte de Claude Code.
Ce qui cause le contournement
La recherche décrit un détail révélateur : le validateur de commandes de Claude Code supprime le texte entre guillemets simples avant d’effectuer une série de contrôles. Ce comportement est jugé correct pour bash. Toutefois, dans la chaîne observée, une charge utile intégrée dans un paramètre lié à une commande git push –receive-pack peut atteindre le runner sans être arrêtée.
Selon les informations disponibles, cette chaîne d’exploitation n’a pas de version corrective publiquement associée et ne repose pas sur une CVE supplémentaire. Elle illustre surtout un problème d’habilitation et de validation en amont.
Le rôle du « harness » : quand une valeur “safe” ne le reste plus
Un fil conducteur traverse les trois scénarios décrits : la défaillance se situe dans le harness, c’est-à-dire le code qui relie l’IA au monde réel. Dans les observations rapportées, une étape marque une valeur comme sûre, puis une étape ultérieure agit sur cette valeur avec plus d’autorité.
En d’autres termes, ce n’est pas uniquement l’outil qui compte, mais la façon dont les décisions sont transportées et réutilisées tout au long du pipeline.
Cette logique explique pourquoi une issue apparemment anodine peut se traduire par un comportement impactant : les contrôles peuvent être incomplets, appliqués au mauvais moment, ou contournés via des détails de parsing.
Codex et “AGENTS.md” : un fix côté workflow plus que côté produit
La recherche mentionne aussi un autre constat lié à Codex. Ici, il n’y a pas de produit corrigé au sens classique, ni de CVE associée : l’équipe rapporte que le dépôt openai/codex exécute deux passes Codex dans un seul job partageant une même base de travail.
Le problème observé : la première passe pouvait écrire un fichier AGENTS.md. La seconde passe chargeait alors ce fichier comme consignes de travail. Un échec de validation JSON entre les passes a déclenché la suite, rendant possible l’exploitation décrite.
OpenAI a répondu en séparant les passes en jobs distincts et en appliquant un modèle d’exécution plus strict : Codex est lancé avec drop-sudo et un bac à sable en lecture seule. La guidance mise à jour indique aussi que des fichiers d’instructions au niveau du dépôt doivent être considérés comme faisant partie de la surface d’entrée non fiable, et recommande d’exécuter Codex en dernier dans un job, pour éviter qu’il laisse des fichiers exploitables pour des étapes privilégiées suivantes.
Autrement dit, la correction porte surtout sur la manière d’orchestrer le workflow, plus que sur une modification “interne” du comportement de Codex lui-même.
Quelles mises à jour appliquer, et quoi auditer ensuite
Pour réduire le risque, la source propose des actions concrètes :
- Gemini CLI : mettez à jour vers 0.39.1 et run-gemini-cli vers 0.1.22.
- Claude Code : mettez à jour vers 2.1.163.
- Auditez vos workflows : examinez les étapes pouvant être déclenchées par des utilisateurs externes, en particulier celles qui combinent des entrées non fiables, des validations incomplètes et des privilèges élevés.
La publication précise aussi que, pour Gemini CLI, le correctif adressant à la fois l’enjeu de liste d’outils et la faiblesse du lanceur de conteneur s’applique à l’ensemble des GitHub Actions Gemini CLI.
Enfin, la source signale qu’aucune des chaînes décrites n’aurait été observée utilisée contre une cible selon les éléments passés en revue.
Exploitation “réelle” et état public des vulnérabilités
Les enregistrements CVE mentionnés indiquent une exploitation catégorisée comme “none” dans la base CISA pour les entrées Gemini et Claude Code. De plus, au moment de la vérification rapportée, ces vulnérabilités n’étaient pas listées dans le catalogue des vulnérabilités connues comme exploitées.
Cela ne réduit pas la nécessité de corriger : au contraire, ces incidents illustrent comment des mécanismes de contrôle peuvent échouer avant que des attaques ciblées soient largement observées.
La recherche relève également l’existence d’un dépôt GitHub orienté “laboratoire de reproduction” pour le problème lié à Claude Code, actif depuis le 18 juin. Le fait qu’il y ait de la documentation de reproduction renforce l’importance d’appliquer les correctifs sans attendre.
Pourquoi ce sujet concerne aussi les équipes qui n’utilisent pas “encore” ces agents
Même si vous ne déployez pas immédiatement des agents de codage, l’enseignement reste général : toute automatisation qui transforme des entrées non fiables en actions de CI doit être pensée en termes de surface d’attaque globale.
Concrètement, la sécurité doit couvrir : la validation des paramètres, le moment où l’on décide qu’une action est autorisée, l’isolement effectif (bacs à sable, privilèges, lecture seule) et l’absence d’écritures “persistantes” avant des étapes critiques.
Le retour d’expérience de Novee Security insiste sur le fait que le point faible n’est pas toujours là où on regarde en premier : parfois, tout se joue dans l’articulation entre l’agent et l’exécution réelle.
Conclusion
Les failles Claude Code et Gemini CLI rapportées par Novee Security montrent à quel point un pipeline CI peut devenir vulnérable lorsque la chaîne entre entrées non fiables et exécution n’est pas parfaitement maîtrisée. Heureusement, les correctifs existent déjà pour Gemini CLI et Claude Code, avec des versions précises à appliquer.
Au-delà des mises à jour, la meilleure protection consiste à auditer chaque workflow CI/CD susceptible d’être déclenché par des tiers : séparez les étapes, renforcez l’isolement, exécutez l’agent comme dernière étape et traitez les fichiers d’instructions et contenus externes comme non fiables.
Source: https://thehackernews.com/2026/08/claude-code-and-gemini-cli-flaws-let.html
