Plugin4Shell : quatre agents de codage IA ont fait confiance à un code PIN qu’ils n’ont jamais vérifié

Le 17 septembre 2026, AIR Security, une startup qui conçoit des outils de sécurité pour les agents IA d'entreprise, a publié des recherches décrivant Plugin4Shell — une faille d'exécution de code à distance sans clic dans quatre agents de codage IA : Claude Code d'Anthropic, Codex d'OpenAI, GitHub Copilot et Gemini CLI de Google. Le bug ne se trouve dans aucun modèle. Il réside dans le checkout git que chaque agent effectue lorsqu'il installe un plugin, et dans le fait qu'aucun des quatre n'a vérifié que le code reçu était bien celui qu'il avait épinglé. Deux des quatre disposaient d'un correctif au moment de la publication des recherches. Deux n'en disposaient pas. Cet incident est une entrée dans l'Orca AI Incident Archive, qui le consigne comme une vulnérabilité de chaîne d'approvisionnement de gravité élevée, sans exploitation signalée.

Ce que les agents ont vraiment mal fait

Chaque agent concerné installe des plugins depuis une marketplace, et chaque marketplace épingle un plugin sur un commit git précis — un SHA de 40 caractères — une fois le plugin examiné. Cet épinglage constitue tout le modèle de sécurité : un évaluateur approuve une version immuable, et l’agent est censé continuer d’exécuter cette version même si le dépôt sous-jacent change ensuite. AIR décrit la faille comme un contournement de l’épinglage SHA des plugins. L’agent extrait exactement le commit épinglé par la marketplace, mais ne vérifie jamais que l’arborescence de travail obtenue correspond à ce commit. Selon les chercheurs, l’agent « extrait exactement le commit épinglé par la marketplace mais ne vérifie jamais qu’il y est bien arrivé, de sorte qu’un attaquant qui contrôle le dépôt du plugin fait pointer l’extraction vers du code malveillant tandis que l’épinglage semble toujours respecté ».

Git comble cette lacune. Lorsqu'un nom est à la fois une branche valide et un objet commit, Git privilégie la branche et ne fait qu'afficher un avertissement d'ambiguïté. Un attaquant qui contrôle le dépôt du plugin crée une branche dont le nom est exactement le SHA épinglé de 40 caractères hexadécimaux, la pointe vers du code malveillant et en fait la branche par défaut du dépôt. Un simple clone ramène alors cette branche localement sous le nom en forme de SHA, et le checkout suivant la résout. Le commit épinglé lui-même peut rester intact, donc rien dans la version examinée ne semble suspect. Selon AIR, deux conditions doivent être réunies : la branche nommée d'après le SHA doit être la branche par défaut, car une branche non par défaut n'est récupérée que comme référence de suivi distant et le checkout retomberait sur le vrai commit ; et l'hébergeur Git doit accepter un nom de branche de 40 caractères hexadécimaux. GitHub rejette catégoriquement ces noms. Bitbucket et les serveurs Git auto-hébergés ne le font pas.

Gemini CLI a échoué par une autre voie. Il a récupéré le commit épinglé, l'a consigné dans le fichier FETCH_HEAD du dépôt, puis a exécuté un checkout de FETCH_HEAD — un checkout qui n'a pas besoin de lire ce fichier. Un dépôt dont la branche par défaut s'appelle elle-même FETCH_HEAD redirige le checkout vers un contenu contrôlé par l'attaquant et écarte silencieusement le commit qui a été récupéré. Le récit de Cybersecurity News sur le mécanisme correspond à celui d'AIR, y compris la distinction entre les deux variantes.

Pourquoi personne n'a eu besoin de cliquer quoi que ce soit

Le même checkout s'exécute à nouveau lors de la mise à jour automatique des plugins en arrière-plan, qui est le comportement par défaut dans Claude Code et Codex. C'est ce qui rend l'attaque zero-click plutôt que simplement discrète : lorsqu'une place de marché fait passer un SHA épinglé à une nouvelle version de routine, chaque agent qui a déjà le plugin installé relance le checkout sans demande de confirmation ni action de l'utilisateur. Le point d'AIR est que la victime n'a pas besoin d'installer quoi que ce soit avec négligence. Il suffit qu'elle ait installé un plugin, depuis une place de marché à laquelle elle fait confiance, qui a été examiné et épinglé exactement comme le prévoit la conception.

Il existe deux façons d’atteindre cette position, et aucune ne nécessite de contrôler la place de marché. Dans la première, un attaquant publie une extension véritablement bénigne qui passe la revue, se constitue une base d’installations, livre une mise à jour normale, et seulement ensuite crée la branche au nom malveillant. Dans la seconde, l’attaquant s’empare du dépôt derrière une extension écrite par quelqu’un d’autre et à laquelle la place de marché fait déjà confiance, puis diffuse la version malveillante à tous ceux qui l’ont installée.

Les chiffres derrière ces deux routes proviennent de travaux antérieurs d’AIR, et non de Plugin4Shell. Dans une campagne que l’entreprise appelle The Story of Skills, elle indique qu’un plugin qu’elle a développé s’est propagé à plus de 26 000 agents avant d’être retiré. Dans SkillJacking, elle a rapporté que 925 skills déjà activement utilisés avaient été repris à leurs mainteneurs d’origine, touchant 134 000 agents. Le titre du billet d’AIR sur Plugin4Shell affirme que « des millions d’agents sont affectés » ; la recherche ne donne aucun décompte des installations exposées, et aucun tiers n’en a publié.

La chronologie, et où les correctifs ont été appliqués

AIR affirme avoir découvert la faille en mai 2026, avec des exploits de preuve de concept fonctionnels contre les quatre agents, et l’avoir divulguée à chaque fournisseur le mois suivant dans le cadre d’une divulgation coordonnée. Anthropic a confirmé son correctif dans Claude Code 2.1.179 le 17 juin. Google a informé AIR le 4 août qu’aucun correctif ne serait publié, car Gemini CLI est en cours de retrait. Il a été vérifié que Codex 0.146.0 était corrigé le 12 août. Microsoft n’a pas publié de correctif pour GitHub Copilot.

Les versions de correctif sont la seule confirmation publique que la faille était réelle dans les deux produits qui l’ont corrigée. L’entrée de journal des modifications publiée par Anthropic pour la version 2.1.179 mentionne la gestion des coupures de connexion, le défilement sous WSL2, les correctifs liés aux globs et à l’interface du bac à sable, et ne mentionne ni l’épinglage, ni la vérification des plugins, ni un correctif de sécurité de quelque nature que ce soit. The Hacker News a fait la même observation, selon le compte rendu de The Next Web. Au moment de la publication de la recherche, aucun identifiant CVE n’avait été attribué, et la note de recherche de la Cloud Security Alliance sur la faille répète qu’aucun identifiant n’existait trois mois après la notification des fournisseurs.

Quatre fournisseurs, trois réponses différentes

Google est allé plus loin que refuser de corriger. Il a déprécié Gemini CLI, ce qui signifie que les installations existantes restent exposées tant que les gens continuent de les exécuter. Son conseil est de migrer vers Antigravity, l’environnement de développement agentique plus récent, que l’attaque n’atteint pas selon AIR, car il ne dispose pas d’un épinglage SHA des plugins de la place de marché à contourner.

La position de GitHub est encore différente. Un porte-parole de GitHub a déclaré à The Register que la plateforme ne permet pas aux utilisateurs de créer des noms de branches ou de tags qui ressemblent à des SHA de commit, et que « cette atténuation garantit que la vulnérabilité signalée ne peut pas être exploitée sur GitHub ». AIR conteste la portée de cette atténuation plutôt que son existence : les places de marché peuvent être hébergées sur d'autres plateformes telles que Bitbucket, ont indiqué les chercheurs à The Register, et GitHub Copilot prend toujours en charge les places de marché de ces plateformes, de sorte que la variante liée au nom de branche reste accessible aux utilisateurs de Copilot. AIR affirme également que la documentation d'Anthropic elle-même répertorie Bitbucket et Git auto-hébergé comme backends valides pour les places de marché ; la documentation actuelle d'Anthropic sur les places de marché décrit l'ajout d'une place de marché à partir d'une URL de dépôt Git, et pas uniquement depuis GitHub. Microsoft n'a pas répondu à la demande de commentaire de The Register, et AIR a déclaré n'avoir reçu aucune réponse de Microsoft depuis qu'elle a signalé le problème en juin, invoquant le volume de divulgations que l'entreprise traite.

Il s'agit d'un désaccord sur l'ampleur de l'exposition, et non sur l'existence du bug. L'atténuation de GitHub est une restriction au niveau de l'hôte ; la conclusion d'AIR est que la vérification doit avoir lieu à l'intérieur de l'agent, car l'épinglage est résolu côté client.

Ce qui est établi, et ce qui ne l’est pas

• Établi : le mécanisme. L'article d'AIR fournit les commandes git exactes, la règle de résolution ref-over-object, les deux conditions requises par l'astuce de branche, ainsi que la variante distincte FETCH_HEAD pour Gemini CLI. The Register, Help Net Security, Cybersecurity News, InfoWorld et The Next Web le rapportent tous de la même manière.

• Établi : deux versions corrigées. Anthropic a confirmé Claude Code 2.1.179 le 17 juin 2026 et Codex 0.146.0 d'OpenAI a été vérifié comme corrigé le 12 août 2026, selon le calendrier de divulgation d'AIR.

• Établi : deux produits n’avaient pas de correctif au moment de la divulgation. Google ne corrigera pas Gemini CLI et le retire ; Microsoft n’a pas livré de correctif pour Copilot.

• Non établi : reproduction indépendante. Tous les récits publiés remontent à l'article de blog d'AIR lui-même, et la note de recherche de la Cloud Security Alliance ne décrit explicitement ni une validation technique par un tiers ni une reproduction indépendante de l'exploit. C'est pour cette raison que l'archive attribue la note B à la confiance accordée à cette fiche.

• Non établi : combien d’installations ont réellement été exposées. « Millions » est la formulation employée par AIR dans son titre, pas un chiffre mesuré.

• Non établi : si la mise à jour d’un agent affecté supprime un plugin déjà remplacé, ou ne fait qu’empêcher le prochain remplacement. Aucune source publiée ne le résout.

• Non établi : aucune utilisation dans le monde réel. Aucune source du dossier ne signale d’exploitation, de sondage ou d’infrastructure d’attaquant, et l’archive consigne les préjudices réels comme faux. C’est une absence de signalement, non la preuve que rien ne s’est produit.

Une vérification tierce réduit tout de même la portée pratique. The Next Web, en résumant les vérifications de The Hacker News, rapporte que les plugins du catalogue communautaire d’Anthropic et des catalogues par défaut de Claude Code et Copilot pointent vers des dépôts GitHub, et que la mise à jour automatique est activée par défaut principalement pour ces places de marché intégrées. Comme GitHub refuse les noms de branche en forme de SHA, la variante fondée sur le nom de branche est plus difficile d’accès pour les utilisateurs qui restent sur les catalogues par défaut. Ce raisonnement ne couvre pas la variante FETCH_HEAD de Gemini CLI, qui ne dépend pas de la façon dont l’hôte nomme les branches.

À quoi doit ressembler un correctif

Le correctif recommandé par AIR tient en une seule assertion : après le checkout, résoudre le commit réellement présent dans l’arbre de travail et abandonner à moins qu’il ne soit égal au SHA épinglé. Les chercheurs insistent sur le fait qu’il doit vérifier le HEAD résolu plutôt que la ref demandée, car c’est précisément cette distinction que la variante Gemini CLI laisse passer, et qu’il doit s’exécuter à l’intérieur de l’agent, car l’épinglage est résolu côté client et aucune place de marché ne peut garantir la garantie qu’elle annonce.

Conseils pratiques à l’intention des équipes qui exploitent ces agents, tirés d’AIR, de Cybersecurity News et des commentaires d’analystes publiés dans InfoWorld :

• Mettez à jour Claude Code vers la version 2.1.179 ou ultérieure, et Codex vers la version 0.146.0 ou ultérieure. La mise à jour est la seule mesure d'atténuation complète lorsqu'un correctif existe.

• Désactivez les mises à jour automatiques des plugins sur tout agent qui ne dispose pas de correctif. Cela fait passer la faille d'une exploitation sans clic à une réinstallation manuelle, ce qui constitue une réduction de l'exposition plutôt qu'un correctif.

• Migrez hors de Gemini CLI plutôt que d’attendre un correctif dont Google a déclaré qu’il ne viendra pas.

• Auditez l’inventaire des plugins et restreignez les sources de marketplace lorsque c’est possible. AIR note qu’une marketplace peut atténuer la variante liée aux noms de branche en n’autorisant que les hôtes qui rejettent les noms au format SHA, ce qui revient de fait à se limiter à GitHub, mais que cela interdit des hôtes officiellement pris en charge par les agents et n’a aucun effet sur la variante Gemini.

• Considérez le poste de travail comme la frontière d’exposition. Les plugins héritent des autorisations de l’agent, de sorte qu’une exploitation réussie donne accès au code source, aux clés SSH, aux identifiants cloud, aux jetons CI/CD et aux dépôts internes avec l’autorité même du développeur. Pareekh Jain, analyste principal chez Pareekh Consulting, a déclaré à InfoWorld que les équipes de sécurité devraient examiner les journaux EDR, git, CI/CD, cloud IAM et d’authentification pour détecter des processus inhabituels, des fichiers de plugins inattendus, des dépôts modifiés et une activité git suspecte — et a ajouté que ces mesures réduisent le risque sans corriger la faille sous-jacente, qu’il attribue au code du fournisseur. « Les entreprises peuvent mettre en place des contrôles autour de l’usage des plugins », a-t-il déclaré à InfoWorld, « mais elles ne peuvent pas corriger une faille dans la manière dont l’agent de codage valide le code qu’il extrait. »

Pourquoi un bug d’épinglage est celui qui comptait

L’épinglage SHA était la réponse de l’industrie précisément au type de prise de contrôle que AIR avait déjà démontré : si un dépôt public est compromis, l’agent continue d’exécuter le hash audité au lieu de récupérer tout ce que l’attaquant a poussé. Plugin4Shell ne casse pas le hash. Il montre que les agents résolvaient l’épinglage vers un nom de branche qui ressemblait simplement au hash, sans jamais comparer le résultat. Tout ce qui découle de cette hypothèse — processus de revue, listes d’autorisation internes, confiance que les développeurs accordent à une version épinglée — hérite de cette défaillance.

Ce que les éléments du dossier ne permettent pas d’étayer, c’est l’affirmation selon laquelle quoi que ce soit aurait été dérobé. Il s’agit d’une vulnérabilité qui a été découverte et, dans deux cas sur quatre, corrigée ; aucune source ne fait état d’une intrusion, et les produits qui n’ont pas publié de correctif attendent toujours. La question qui reste ouverte est la moins satisfaisante : pour quiconque a exécuté un plugin sur un agent non corrigé, aucun moyen publié ne permet de savoir si le code exécuté était bien celui qu’il avait approuvé.