Comment and Control : un seul motif de prompt injection détourne Claude Code, Gemini CLI et GitHub Copilot

Un titre de pull request, trois agents IA, tous les secrets du runner

Un chercheur en sécurité nommé Aonan Guan, avec deux chercheurs de Johns Hopkins University, a démontré qu'un seul motif de prompt injection peut détourner trois des agents IA de coding les plus déployés sur GitHub — Claude Code Security Review d'Anthropic, Gemini CLI Action de Google et GitHub Copilot Agent — et exfiltrer les clés d'API et tokens d'accès du dépôt qui les héberge.

L'attaque a été divulguée publiquement le 15 avril 2026 et mise à jour le 4 mai 2026 après qu'Anthropic a terminé sa remédiation. C'est la première démonstration publique d'un même motif de prompt injection qui touche trois grands éditeurs d'agents IA en même temps.

Ce qui s'est passé

Guan appelle la technique Comment and Control — un clin d'œil à l'infrastructure command-and-control dont les malwares classiques ont besoin. Ici, toute la boucle tourne à l'intérieur de GitHub. L'attaquant écrit un commentaire, l'agent IA le lit, l'agent exécute les instructions qui y sont enfouies, et l'agent commit ou commente les identifiants volés dans GitHub où l'attaquant peut les récupérer. Aucun serveur externe nécessaire.

Les trois cas confirmés :

• Claude Code Security Review — Le titre de la PR est interpolé directement dans le prompt de l'agent, sans aucune sanitization. Un titre de PR malveillant ordonne à Claude d'exécuter whoami, ps auxeww et env, puis de poster les résultats sous forme de commentaire « security finding ». Le dump contient ANTHROPIC_API_KEY et GITHUB_TOKEN. Anthropic a accepté le report en CVSS 9.4 Critical, payé une prime de 100 $, puis abaissé la sévérité à None le 20 avril 2026.
• Gemini CLI Action — Un commentaire d'issue injecte une fausse « Trusted Content Section » qui écrase les instructions de sécurité de Gemini. Gemini poste ensuite la GEMINI_API_KEY en commentaire public sur l'issue. Google a payé 1 337 $ via son programme VRP.
• GitHub Copilot Agent — La charge utile se cache dans un commentaire HTML que la vue Markdown rendue de GitHub n'affiche pas. La victime, en assignant l'issue à Copilot, ne voit qu'un texte innocent. Copilot exécute alors ps auxeww | base64 -w0 et commit l'environnement de processus encodé sous forme de fichier dans une nouvelle PR — contournant le filtre d'environnement de GitHub, son secret scanner et son firewall réseau dans la même chaîne. GitHub a payé 500 $ après avoir d'abord classé le report comme informatif.

Pourquoi c'est important

Chaque couche de défense que les éditeurs avaient construite autour de ces agents — garde-fous au niveau du modèle, instructions au niveau du prompt, filtrage d'environnement, secret scanning, allowlists réseau — a été contournée de la même manière : en utilisant les capacités prévues de l'agent contre lui. L'attaquant n'a pas exploité un bug de parsing. Il a mis du texte dans le champ que l'agent est conçu pour lire.

C'est ça, le problème structurel. Un agent IA en CI doit lire des entrées non fiables (titres de PR, corps d'issues, commentaires) pour faire son travail. Le même agent doit détenir des secrets de production pour faire son travail. Mettre les deux dans le même runtime, c'est faire de toute prompt injection qui atterrit une fuite de credentials. Guan donne la bonne analogie : c'est du phishing, mais pour des machines.

Par défaut, GitHub Actions n'expose pas les secrets aux pull requests provenant de forks. Mais le trigger pull_request_target, lui, le fait — comme le font les workflows sur les événements issues ou issue_comment, qui se déclenchent sur l'entrée de n'importe quel utilisateur GitHub. Les dépôts qui ont câblé une revue IA automatique sur ces triggers ont livré la vulnérabilité avec.

Ce qu'il faut faire

1. Auditer les triggers sur lesquels tournent vos workflows IA. Tout agent qui tourne sur pull_request_target, issues ou issue_comment depuis des contributeurs non fiables doit être considéré comme exposé à la prompt injection.
2. Allowlister les outils, ne pas les blocklister. Le premier patch d'Anthropic bloquait ps ; cat /proc/*/environ obtient le même résultat. Passez --allowed-tools en n'indiquant que les commandes dont l'agent a besoin, et retirez entièrement l'exécution shell des agents dont le travail ne l'exige pas.
3. Restreindre la portée des secrets visibles par le workflow. Utilisez des tokens à grain fin et à durée courte pour l'opération exacte que l'agent réalise. Ne confiez pas à un agent de revue de code un GITHUB_TOKEN avec accès en écriture, et ne stockez pas de secrets à l'échelle de l'organisation dans des workflows qui traitent de l'entrée externe.
4. Roter tout credential que les agents touchés ont pu voir. Si vous avez fait tourner Claude Code Security Review, Gemini CLI Action ou Copilot Agent sur des PR ou issues venant de contributeurs externes, traitez les clés d'API concernées comme potentiellement exposées et changez-les.
5. Inspecter l'historique du dépôt à la recherche de commentaires HTML cachés dans les issues assignées à Copilot. La variante Copilot est invisible dans la vue rendue de GitHub mais présente dans le Markdown brut. Vérifiez la source des issues à la recherche de blocs <!-- --> contenant des commandes shell.

À retenir

Les données du workflow que l'agent doit lire sont aussi celles que l'attaquant contrôle. Tant que les agents IA en CI détiendront des secrets de production dans le même runtime qui traite les pull requests et les issues, Comment and Control continuera de fonctionner — seule la surface d'injection changera. Traitez chaque agent de coding comme un prestataire avec accès shell : need-to-know sur les secrets, moindre privilège sur les outils, et partez du principe que tout texte qu'il lit depuis Internet a été écrit pour le tromper.