GitHub Action Claude Code : comment l'outil Read a fait fuiter des secrets CI/CD

De quoi s’agit-il ?

Le 5 juin 2026, l’équipe Microsoft Defender Security Research a publié un chemin d’injection de prompt dans le GitHub Action Claude Code d’Anthropic. Lorsque l’action traitait du contenu GitHub non fiable — corps d’issue, descriptions de pull request, commentaires — une instruction forgée pouvait orienter l’outil Read de l’agent vers l’ouverture de /proc/self/environ et l’extraction des variables d’environnement du runner, dont l’ANTHROPIC_API_KEY. Microsoft a signalé le problème à Anthropic via HackerOne le 29 avril 2026 ; Anthropic a livré un correctif dans Claude Code 2.1.128 le 5 mai 2026, qui rejette désormais sans condition les fichiers sensibles de /proc/. Cet article porte sur une faille corrigée et sur la leçon de frontière de confiance qu’elle illustre, pas sur un mode opératoire.

Comment ça marche

Claude Code Action encapsule le Claude Agent SDK et exécute Claude à l’intérieur d’un runner GitHub Actions — une VM éphémère pouvant détenir le GITHUB_TOKEN, des identifiants cloud, des jetons de publication et des clés d’API tierces. Anthropic avait anticipé le risque : l’outil Bash s’exécute dans un bac à sable Bubblewrap avec un environnement nettoyé (CLAUDE_CODE_SUBPROCESS_ENV_SCRUB, activé automatiquement quand un workflow peut être déclenché par des utilisateurs sans droit d’écriture). La faille trouvée par Microsoft : l’outil Read n’était pas routé par cette même isolation. Les opérations Read étaient des appels in-process directs, donc exécutés avec un accès complet à l’environnement du processus parent — contournant le scrub qui protégeait Bash.

Cela transforme le schéma classique « IA dans la CI/CD » en trifecta létal : entrée non fiable (une issue GitHub), accès à des secrets (l’environnement du runner) et canal sortant (WebFetch, un commentaire via GitHub MCP, ou le log de l’action). Le texte injecté était caché dans un commentaire HTML — invisible dans l’issue rendue, mais bien présent dans le markdown brut que le modèle lit. Deux couches défensives subsistaient ; la charge les a contournées au plan conceptuel :

Couche de défense              Pourquoi elle a échoué
-----------------------------  ------------------------------------------------
Refus du modèle / system prompt  Requête présentée comme une « revue de
                                 conformité », avec consigne de retirer les
                                 premiers caractères de la valeur avant
                                 affichage — la sortie ne ressemblait plus à
                                 une clé « sk-ant-... »
Secret scanner GitHub          La clé étant modifiée avant écriture sur stdout,
                               le détecteur de motifs connus n'a pas matché

L’attaquant reconstruit ensuite la clé complète en rajoutant le préfixe retiré. Aucune charge fonctionnelle n’est reproduite ici ; le mécanisme important est l’idée de blanchiment — muter un secret juste assez pour passer à la fois sous l’heuristique de refus d’un modèle et sous un scanner à base d’expressions régulières. Microsoft rattache la chaîne aux techniques MITRE ATLAS d’injection de prompt (AML.T0051), invocation d’outil (AML.T0053), jailbreak (AML.T0054), collecte d’identifiants (AML.T0098) et fuite de données (AML.T0057).

Pourquoi c’est important

La valeur exposée était un identifiant actif posé dans un runner de build, atteignable par quiconque pouvait ouvrir une issue sur un workflow suffisamment permissif. La même faille de confiance a aussi permis un second résultat observé dans la nature : un bot de triage IA poussé à lire un fichier de docs, à y ajouter une balise image XSS invisible et à ouvrir une pull request — une tentative d’empoisonnement de la chaîne d’approvisionnement ne nécessitant aucun droit d’écriture côté attaquant, seulement ceux de l’agent. Le point de fond est structurel. GitHub Actions a été conçu pour de l’automatisation déterministe ; y greffer un LLM signifie que le langage naturel devient exécutable, et que chaque issue ou commentaire devient une instruction potentielle. Une seule frontière de confiance mal évaluée — un outil ayant sauté le bac à sable — a suffi pour repartir avec des identifiants de production. C’est la même classe de faiblesse que Comment and Control, vue depuis l’intérieur du runner.

Défenses

Le correctif est livré, mais la leçon d’architecture vaut pour tout déploiement d’IA dans la CI :

1. Mettez à jour. Utilisez Claude Code Action / Claude Code 2.1.128 ou plus récent, qui bloque les lectures de /proc/. Épinglez l’action à une version vérifiée plutôt qu’à un tag flottant.
2. Appliquez la règle des deux pour agents. Aucun workflow IA ne doit cumuler en même temps : traitement d’entrée non fiable, détention de secrets et outil d’écriture/communication externe. Retirez une de ces trois branches — en général le canal sortant ou l’accès aux secrets — pour les jobs déclenchés par du contenu non fiable.
3. Moindre privilège sur chaque jeton. Limitez le GITHUB_TOKEN et les clés fournisseur au strict nécessaire, une clé par workflow/environnement, et alertez côté fournisseur sur les nouvelles IP ou les pics de trafic.
4. Traitez tout contenu de dépôt comme des données hostiles. Durcissez le system prompt pour déclarer issues, commentaires, diffs et contenus de fichiers comme des données non fiables, jamais des instructions, et fixez l’agent sur une tâche unique avec refus par défaut hors périmètre.
5. Isolez le runtime et surveillez l’egress. N’exécutez pas les jobs IA déclenchés par du contenu non fiable sur des runners auto-hébergés détenant des identifiants permanents. Restreignez les domaines sortants et relisez le log d’appels d’outils — la piste d’audit transforme une fuite silencieuse en test détecté.

Statut

Élément	Référence	Date	Notes
Signalement à Anthropic (HackerOne)	Microsoft TI	2026-04-29	Recherche black-box → white-box sur Claude Code Action
Correction dans Claude Code 2.1.128	Anthropic	2026-05-05	L’outil Read rejette sans condition les fichiers sensibles de /proc/
Divulgation publique	Microsoft Security Blog	2026-06-05	Contournement du scrub par Read ; /proc/self/environ → ANTHROPIC_API_KEY
Couverture	The Hacker News, CyberSecurityNews	2026-06-05 → 2026-06-06	Reportages corroborants

La leçon n’est pas que l’action d’un fournisseur serait singulièrement dangereuse — toute intégration IA dans la CI partage cette forme. C’est que l’isolation au niveau des outils doit être uniforme : un bac à sable qui protège Bash mais pas Read est un bac à sable avec une porte laissée ouverte, et le contenu GitHub non fiable finira par la trouver.