Claude Code Action : une confiance aveugle aux « bots » ouvrait une faille de supply chain

De quoi s’agit-il ?

Le 1er juin 2026, RyotaK, de GMO Flatt Security, a publié Poisoning Claude Code: One GitHub Issue to Break the Supply Chain, documentant une faille dans le modèle de permissions de Claude Code GitHub Action — le workflow fourni par Anthropic pour intégrer Claude à la CI/CD (tri des tickets, étiquetage, revue de code, commandes slash). Constat central : le contrôle d’accès en écriture de l’action pouvait être contourné par tout attaquant enregistrant sa propre GitHub App, laissant du contenu non fiable atteindre un workflow conçu pour ne traiter que des entrées de confiance. Enchaîné à une injection de prompt indirecte, ce contournement menait au vol des identifiants servant à générer un jeton de dépôt privilégié — et, comme le dépôt de l’action exécutait lui-même un workflow vulnérable, à une voie de compromission de tous les projets qui en dépendent en aval.

RyotaK a signalé le contournement à Anthropic le 12 janvier 2026 ; Anthropic l’a corrigé quatre jours plus tard puis a durci le dispositif au printemps, avec les correctifs livrés dans claude-code-action v1.0.94. Anthropic a coté les problèmes à 7,8 selon CVSS v4.0 et versé une prime de bug bounty. La publication a suivi la divulgation publique, et le chercheur note que des variantes de mauvaise configuration du même schéma avaient déjà été exploitées en conditions réelles avant la parution.

Comment ça marche

Par défaut, le workflow dispose d’un accès en lecture et écriture au code, aux tickets, aux pull requests, aux discussions et aux fichiers de workflow du dépôt. Ces permissions étant larges, l’action est censée être sélective sur qui peut la déclencher — uniquement des utilisateurs disposant d’un accès en écriture. Ce contrôle résidait dans une fonction checkWritePermissions qui renvoyait true pour tout acteur dont le nom finissait par [bot], en supposant que les GitHub Apps sont des entités de confiance installées par les administrateurs.

Cette hypothèse ne tient pas sur les dépôts publics. N’importe qui peut enregistrer une GitHub App, l’installer sur un dépôt qu’il possède, et utiliser son jeton d’installation pour ouvrir un ticket ou une pull request sur n’importe quel dépôt public — GitHub accorde aux Apps un accès implicite aux ressources publiques. L’action voyait un acteur finissant par [bot] et laissait passer le contenu contrôlé par l’attaquant. Le mode tag comportait une vérification supplémentaire (checkHumanActor) ; le mode agent, à l’époque, non.

Ensuite, l’attaquant s’appuyait sur l’injection de prompt indirecte — des instructions glissées dans le contenu lu par l’agent, pour que le modèle les suive à la place de sa tâche. Dans la preuve de concept documentée, le texte injecté était formulé de sorte que l’agent « récupère » d’une prétendue erreur de lecture en exécutant des commandes intégrées, atteignant /proc/self/environ pour extraire les variables d’environnement du runner. Les valeurs déterminantes sont la paire d’identifiants que GitHub Actions utilise pour demander un jeton OIDC ; ce jeton est échangé contre un jeton d’installation de la Claude GitHub App avec accès en écriture. Volez la paire, rejouez l’échange, et vous détenez l’accès en écriture au code et aux workflows de la cible. Dirigez-le vers le dépôt de l’action elle-même, et le poison se propage en aval. Aucun payload fonctionnel n’est reproduit ici ; l’intérêt réside dans la défaillance de la frontière de confiance, et le chercheur n’a validé la chaîne que dans ses propres dépôts de test.

Une variante plus simple contournait entièrement l’astuce du bot : le workflow d’exemple de tri de tickets livré définissait allowed_non_write_users: "*", et l’agent publiait des résumés de tâches dans le panneau récapitulatif public de l’exécution — un canal d’exfiltration tout prêt, hérité par de nombreux déploiements copiés-collés.

Pourquoi c’est important

C’est le modèle de menace de la CI/CD agentique rendu concret. Un workflow qui (1) ingère du contenu GitHub non fiable, (2) détient des secrets et des jetons, et (3) peut agir via des outils, réunit exactement la combinaison dangereuse contre laquelle mettent en garde la triade létale et la règle de deux des agents — et ici les trois cohabitaient dans une seule action. Le contournement transformait une conception « entrées de confiance uniquement » en une surface « n’importe quel internaute », et le rayon d’impact n’était pas un dépôt mais tout le graphe de dépendances sous une action très utilisée, celui du mainteneur compris. Cela rejoint le schéma « Comment and Control », où des titres de PR et des corps de tickets fuitaient des secrets GitHub Actions chez trois éditeurs, ainsi qu’une fuite via l’outil Read qui atteignait le même fichier /proc/self/environ par une autre voie. La leçon se répète : les contrôles d’identité fondés sur des motifs de chaîne ne sont pas de l’autorisation, et l’injection de prompt reste non résolue partout où un agent porteur de jetons réels lit du texte contrôlé par un attaquant.

Défenses

• Passez à claude-code-action v1.0.94 ou une version ultérieure. Le correctif ajoute une vérification d’acteur humain au mode agent, désactive par défaut le canal du résumé d’exécution, encapsule gh pour bloquer les arguments propices à l’exfiltration, et purge les variables d’environnement des processus enfants.
• Auditez tout workflow autorisant des utilisateurs sans droit d’écriture — ou des bots — à déclencher l’agent. S’il traite des entrées non fiables, n’exposez aucun secret au-delà du minimum, et retirez les outils ou permissions permettant l’exfiltration (WebFetch, Bash arbitraire, git push, voire gh issue view avec un argument URL).
• Appliquez la règle de deux. Ne laissez jamais un même workflow lire des entrées non fiables, détenir des identifiants sensibles et agir vers l’extérieur simultanément. Retirez l’une des trois pattes — fixez la tâche, supprimez le secret, ou placez l’écriture derrière une validation humaine.
• Traitez l’identité de l’acteur comme une donnée, pas une autorisation. Un suffixe [bot], un nom d’auteur ou un badge « vérifié » est un contexte falsifiable ; imposez des contrôles réels de permission et de provenance côté serveur.
• Adoptez des architectures d’agents CI/CD fondées sur l’isolation. Voir notre couverture de l’architecture de sécurité de GitHub Agentic Workflows — agents sans secrets, pare-feu de workflow, écritures mises en attente et vérifiées — comme réponse structurelle plutôt que rustines au niveau du prompt.

Statut

Élément	Détail
Divulgué par	RyotaK, GMO Flatt Security
Signalement / premier correctif	2026-01-12 / 2026-01-16 (quatre jours)
Publication	2026-06-01
Composant affecté	claude-code-action (mode agent + workflow d’exemple de tri de tickets)
Corrigé dans	claude-code-action v1.0.94
Gravité	CVSS v4.0 7,8 (élevée), selon Anthropic
Variantes exploitées	Workflow de tri de Cline (vol de jeton npm, févr. 2026) ; aucun signe public que la voie d’empoisonnement de l’action ait touché une cible réelle

Il s’agit d’une classe de vulnérabilité divulguée et corrigée dans une intégration CI/CD. Les noms de composants et les chiffres sont ceux rapportés par le billet de GMO Flatt Security, The Hacker News et le commit de correctif d’Anthropic.