Faille dans Claude Code: une issue GitHub atteint les secrets de la CI

Une issue GitHub ouverte par quelqu'un sans le moindre droit sur le dépôt a suffi à atteindre les secrets de sa chaîne de build. Novee Security l'a montré à la Black Hat USA le 5 août 2026, sur trois agents de code IA à la fois: Claude Code d'Anthropic, Gemini CLI de Google et Codex d'OpenAI. Aucune de ces attaques n'a cassé un modèle. Elles ont cassé le harnais autour de lui, le code ordinaire qui décide quelles commandes le modèle a le droit d'exécuter.

Comment une issue GitHub atteint les secrets de la CI

Les trois agents se branchent à l'intégration continue de la même manière. Un événement du dépôt, une issue ou une pull request, déclenche un workflow, le workflow lance l'agent sur un runner, et l'agent lit le texte de l'événement dans le cadre de sa tâche. Ce texte est écrit par celui qui a ouvert l'issue. Sur un dépôt public, c'est-à-dire n'importe qui.

L'injection de prompt par ce biais est un problème connu, et chacun de ces outils dispose d'une couche de validation censée la contenir. La recherche porte sur l'échec de cette couche, pas sur la crédulité du modèle. Un runner détient les identifiants dont la chaîne a besoin: jetons de dépôt, clés cloud, clés d'API de l'agent lui-même. Qui exécute une commande sur le runner atteint tout cela.

La faille de Claude Code: un désaccord sur les guillemets et un compteur de téléchargements

La chaîne visant Claude Code a commencé par un désaccord sur les guillemets. Le validateur de commandes retirait le texte entre guillemets simples avant d'appliquer ses vingt-trois contrôles de sécurité, en supposant qu'un shell traiterait ce contenu comme de simples données. Le harnais transmettait ensuite la commande sans ces guillemets. Une valeur glissée dans le drapeau --receive-pack de git paraissait donc inoffensive à la validation et s'exécutait sur le runner.

La suite est le plus intéressant. Anthropic a corrigé, et les chercheurs ont trouvé une deuxième voie avec tac, une commande en lecture seule qui inverse le contenu d'un fichier, pour imprimer une clé d'API à l'envers dans un journal de build public. Corrigé aussi. Le troisième tour, suivi sous CVE-2026-54316, a renoncé à imprimer quoi que ce soit: la clé a fui caractère par caractère via le compteur public de téléchargements d'un modèle Hugging Face, la réponse étant lue depuis l'extérieur. La note est de 9,1 en CVSS v3.1 et 6,0 en CVSS v4; Anthropic classe le problème comme modéré au motif qu'un attaquant doit d'abord faire entrer du contenu non fiable dans le contexte de l'agent. Les versions à partir de 0.2.54 sont concernées, le correctif est arrivé en 2.1.163, avis GHSA-fg94-h982-f3mm.

Gemini CLI: la pire note des trois

L'outil de Google a écopé plus lourdement. CVE-2026-12537 porte un score CVSS de 10,0: le lanceur de conteneur analysait sa liste d'outils autorisés une seule fois, à l'enregistrement, sans rien vérifier à l'exécution. Sous le drapeau --yolo, toute commande demandée par le modèle était approuvée automatiquement, et une injection de commandes système via un fichier .gemini/.env préparé exécutait du code sur l'hôte de CI avant même le démarrage du bac à sable. Toutes les versions jusqu'à 0.39.0 incluse sont vulnérables, le correctif est dans 0.39.1, l'action GitHub passant à run-gemini-cli 0.1.22, avis GHSA-wpqr-6v78-jr5g.

Codex se distingue. Deux passes de Codex partageaient un même checkout dans un seul job, si bien que la première pouvait écrire un fichier AGENTS.md que la seconde chargeait ensuite comme instructions. La position d'OpenAI: le bac à sable s'est comporté exactement comme documenté, donc aucun correctif de version n'a été publié. Ce sont les recommandations de workflow qui ont changé, séparant les passes en jobs distincts et désignant explicitement les fichiers d'instructions du dépôt comme faisant partie de la surface d'entrée non fiable.

Pourquoi l'accès volé continue de fonctionner

Une recherche distincte de Silverfort, publiée le 28 juillet 2026, explique pourquoi un seul vol vaut si cher. Sous macOS, Claude Code CLI écrit son lot OAuth dans le trousseau comme mot de passe générique, sous le nom de service "Claude Code-credentials", créé via /usr/bin/security sans arguments de contrôle d'accès. L'entrée hérite de la liste d'accès par défaut, qui fait confiance à l'outil qui l'a créée. Comme cet outil est un binaire Apple universel que n'importe quel processus peut appeler, une seule ligne de commande renvoie tout le lot, sans Touch ID ni mot de passe.

Le lot contient un jeton d'accès à durée courte et un jeton de rafraîchissement à durée longue, plus les identifiants des serveurs MCP connectés. Le problème est le jeton de rafraîchissement: il s'échange contre de nouveaux jetons d'accès jusqu'à révocation, et il n'est lié ni à un appareil ni à une adresse. Anthropic ne qualifie pas cela de vulnérabilité, estimant que les processus du même utilisateur sont déjà de confiance, mais indique suivre un durcissement du contrôle d'accès comme amélioration en défense en profondeur. Il vaut la peine de noter que l'application de bureau maison fait l'inverse: les jetons y sont chiffrés avec une clé liée à la signature de code, et toute tentative extérieure d'y accéder déclenche une demande de mot de passe.

Que faire si vous faites tourner ces agents

• Mettre à jour d'abord: Claude Code 2.1.163 ou plus récent, Gemini CLI 0.39.1 avec run-gemini-cli 0.1.22. Pour Codex il n'y a rien à installer, seulement un workflow à modifier.
• Ne pas laisser des événements publics déclencher un agent: un workflow qui démarre sur n'importe quelle issue ou pull request depuis n'importe quel compte remet la surface d'entrée à des inconnus. Exigez un label, le commentaire d'un mainteneur ou un contrôle de fork.
• Restreindre les secrets du runner: donnez au job le jeton le plus étroit possible et tenez les clés cloud à longue durée hors des workflows qu'un agent peut toucher.
• Séparer les passes: si deux exécutions d'agent partagent un checkout, la première peut écrire les instructions que la seconde suivra. Jobs distincts, checkouts distincts.
• Faire tourner les clés au soupçon, pas à la preuve: se déconnecter, se reconnecter, puis renouveler les clés en console. Nettoyer la machine n'invalide pas un jeton de rafraîchissement déjà parti.
• Surveiller la même session sur deux machines: la réutilisation d'identifiants depuis des hôtes différents est précisément le signal que ces jetons rendent possible, puisque rien ne les lie à l'appareil.

Pourquoi cela dépasse les développeurs

Le schéma se répète à mesure que les agents gagnent en autonomie: l'attaque n'arrive pas par le réseau sous forme de trafic inspectable, elle arrive sous forme de contenu et s'exécute dans une session déjà de confiance. Nous avons décrit la même forme quand un navigateur IA pouvait être détourné par une publication que l'utilisateur n'avait jamais cliquée, et c'est pour la même raison qu'une chaîne comme la faille du formulaire de connexion WordPress qui finit en code sur le serveur est dangereuse alors qu'il suffit qu'un administrateur ouvre une page. C'est aussi là que se situe la limite honnête des outils de confidentialité réseau. Un VPN masque votre trafic au réseau où vous êtes et déplace votre localisation apparente; il n'a aucune vue sur ce que votre propre agent décide d'exécuter, et il ne s'interpose pas entre un processus et le trousseau du même ordinateur. Le chiffrement en transit n'a jamais été la frontière que ces attaques franchissent.

Conclusion