Un commentaire piégé sur GitHub, et l'assistant IA livrait les clés du pipeline

L'assistant a lu une issue, puis a tendu les clés

Les chercheurs de Microsoft ont tendu un piège, et l'ont vu se refermer. Dans un dépôt de test, ils ont relié l'action GitHub de Claude Code, un assistant IA capable de lire les demandes de revue de code et d'y donner suite, puis ils ont ouvert une issue truffée d'instructions dissimulées. L'agent a obéi. Il a localisé le fichier où le système de build conserve ses secrets, en a extrait une clé d'API Anthropic active, puis l'a maquillée assez habilement pour franchir deux contrôles de sécurité distincts. Aucun mot de passe forcé, aucune faille logicielle au sens classique. L'attaquant s'est contenté d'écrire un commentaire.

Si l'affaire compte, c'est à cause de l'endroit où vit cet assistant. Il s'exécute au cœur du pipeline qui compile et livre vos logiciels, entouré des identifiants dont ce pipeline a besoin pour fonctionner. Dès lors qu'on apprend à ce pipeline à exécuter les consignes d'inconnus, une seule phrase devient une porte d'entrée.

Ce que Microsoft a mis au jour

Le montage est devenu banal. De nombreuses équipes greffent un agent IA sur GitHub Actions (l'automatisation intégrée de GitHub, qui déclenche des tâches dès qu'une personne ouvre une issue, laisse un commentaire ou soumet une pull request) pour trier les rapports de bugs ou relire le code. L'action Claude Code d'Anthropic est l'un de ces agents. Elle lit l'issue ou la pull request, y compris le texte rédigé par des personnes extérieures à l'équipe, et décide de la marche à suivre. Cette ouverture fait tout l'intérêt de l'outil. Elle fait aussi tout le problème.

Anthropic avait anticipé le risque et verrouillé l'outil d'exécution de commandes, en l'enfermant dans un bac à sable qui purge les secrets de l'environnement avant le moindre lancement. La faille repérée par Microsoft Threat Intelligence tient à un oubli : l'outil de lecture de fichiers, lui, n'a jamais été placé derrière ce même mur. Les chercheurs ont donc glissé une injection de prompt (des instructions cachées dans le contenu que l'IA consulte, et que le modèle exécute ensuite comme s'il s'agissait de ses propres consignes) à l'intérieur d'une issue GitHub. Pour contourner le réflexe de refus du modèle, ils ont déguisé la requête en banal « contrôle de conformité » et lui ont demandé de retrancher les sept premiers caractères de ce qu'il trouverait. Ce détail a tout changé : en supprimant le préfixe révélateur sk-ant-, il a empêché aussi bien le filtre de sécurité de Claude que le scanner de secrets de GitHub de reconnaître ce qui sortait. L'outil de lecture a alors ouvert /proc/self/environ, le fichier système qui contient les variables d'environnement d'un programme en cours d'exécution, et la clé non protégée s'y trouvait.

• Microsoft a signalé la faille à Anthropic le 29 avril 2026. Anthropic a publié un correctif dans la version 2.1.128 de Claude Code le 5 mai, en interdisant à l'agent la lecture de ces fichiers système sensibles.
• Une fois la clé sortie, elle peut s'échapper par n'importe quel canal autorisé par le workflow : une requête web vers le serveur de l'attaquant, une réponse publiée sous l'issue, ou le journal de build lui-même. Il suffit ensuite de replacer sk-ant- en tête pour reconstituer la clé complète.
• Microsoft a ouvert cette enquête après avoir repéré de véritables tentatives d'injection dans des dépôts publics, dont une visant la copie d'un projet de documentation connu, où un bot IA a été détourné pour y dissimuler du code malveillant.

Pourquoi cela vous concerne, et pas seulement Anthropic

La clé corrigée est le moindre des enjeux. Dans la démonstration, la perte concrète se limitait à une clé d'API, mais le même runner héberge d'ordinaire les identifiants qui permettraient à un intrus d'agir en votre nom : le jeton GitHub, les accès au cloud, le jeton qui publie vos paquets au monde entier. Qu'un attaquant les atteigne, et le commentaire piégé cesse d'être une farce pour devenir une compromission de la chaîne d'approvisionnement, livrée à tous ceux qui installeront votre logiciel. Voilà ce qui change pour vos équipes. Si vous avez relié un agent IA à un workflow que des tiers peuvent déclencher, chaque issue, chaque pull request et chaque commentaire devient une entrée non fiable qui s'exécute à quelques centimètres de vos secrets. Le basculement de fond mérite d'être posé lors de votre prochaine revue d'ingénierie. Les chaînes d'intégration et de livraison continues (les pipelines CI/CD qui testent et publient le code automatiquement) ont été pensées pour dérouler des scripts figés et prévisibles. Or un agent IA brise cette hypothèse, car il traite le langage courant comme une instruction. Autrement dit, le langage naturel est devenu du code exécutable, et rares sont les pipelines conçus pour se défendre contre un paragraphe.

Les bons réflexes

1. Passez Claude Code en version 2.1.128 ou ultérieure, et maintenez à jour chacune de vos actions IA. Cette version ferme précisément le trou de lecture de fichiers, et l'outillage IA se corrige désormais assez vite pour qu'un agent obsolète soit la porte la plus facile à laisser ouverte.
2. N'autorisez jamais un même workflow IA à lire une entrée non fiable, à détenir des secrets et à communiquer avec l'extérieur en même temps. Les ingénieurs de Meta appellent cela la règle des deux : retirez l'une des trois capacités et l'attaque s'effondre, si bien qu'un agent chargé de trier des issues publiques devrait tourner sans secret et sans accès à l'internet ouvert.
3. Réduisez chaque jeton au strict minimum et signifiez à l'agent que ses entrées sont hostiles. Attribuez à chaque workflow une clé aux permissions étroites et surveillez son usage, puis rédigez le system prompt pour énoncer clairement que tout contenu d'issue, de commentaire ou de fichier est une donnée d'auteur non fiable, et jamais une instruction, car un prompt durci arrête les tentatives simples même s'il ne peut toutes les bloquer.

À retenir

L'attaque a réussi non parce que l'IA a déraillé, mais parce qu'elle a fait exactement ce qu'on lui demandait, à la demande de la mauvaise personne. C'est la leçon inconfortable à emporter en réunion de sécurité. À partir du moment où un agent agit sur un texte que n'importe qui peut écrire en ligne, il faut traiter chaque commentaire comme une commande potentielle. Le confort d'un assistant qui lit vos issues et corrige votre code est bien réel, tout comme le fait qu'il lit l'issue d'un attaquant avec exactement la même confiance. Une question vaut la peine d'être posée avant de brancher le prochain outil IA sur votre pipeline. Si le commentaire d'un inconnu peut atteindre nos secrets de build, qu'est-ce qui, dans notre configuration, l'empêche de repartir avec ?