SHA Pinning n'est pas une vérification : Plugin4Shell et le premier RCE de chaîne d'approvisionnement des agents IA

925 skills de plugins ont déjà été détournées de leurs mainteneurs d'origine, et ces skills atteignent 134 000 agents. Le 17 septembre 2026, AIR Security a divulgué Plugin4Shell — la première vulnérabilité de chaîne d'approvisionnement de l'écosystème des agents IA : une exécution de code à distance (RCE) zero-click touchant Claude Code, OpenAI Codex, GitHub Copilot et Google Gemini CLI, toutes par la même vérification manquante. Le mécanisme tient en une seule assertion git que chaque agent concerné omet : l'agent vérifie le SHA de commit épinglé par la marketplace mais ne vérifie jamais que l'arborescence de travail s'est réellement retrouvée sur ce commit. Un attaquant qui contrôle le dépôt d'un plugin nomme une branche du SHA épinglé de 40 caractères, la définit comme branche par défaut du dépôt, et l'agent installe du code contrôlé par l'attaquant tout en signalant une installation propre au commit épinglé (Cyber Security News ; Help Net Security).

Cela importe à toute équipe exécutant des agents de code contre des systèmes de production, car l'épingle était le contrôle. Les organisations qui vont au-delà d'une marketplace communautaire — examinant le code des plugins, épinglant les installations à un commit révisé — comptaient sur le pinning SHA comme protection, et Plugin4Shell l'annule silencieusement : la revue passe, l'épingle est écrite, et un code différent s'exécute (AIR). Cet article couvre les quatre choses qu'un directeur de l'ingénierie doit savoir avant que la prochaine mise à jour automatique d'un plugin ne se déclenche : le mécanisme en une commande git, l'attaque en cinq étapes de l'adoption bénigne au RCE en arrière-plan, le tableau de réponse des vendeurs (deux corrigés, un non corrigé, un déprécié non corrigé), et les points de vérification qui referment la brèche pour chaque artefact épinglé que vos agents installent — plugins, serveurs MCP et skills.

Points clés

• Un RCE zero-click a touché les quatre agents de code majeurs — Claude Code, Codex, GitHub Copilot et Gemini CLI — par une même assertion git manquante — AIR a divulgué Plugin4Shell le 17 septembre 2026 : les agents vérifient le SHA de commit épinglé par la marketplace mais ne vérifient jamais que le checkout a résolu vers lui (AIR).
• 925 skills ont déjà été détournées de leurs mainteneurs, atteignant 134 000 agents — la recherche SkillJacking d'AIR ; Plugin4Shell neutralise le mécanisme de pinning SHA justement construit pour contenir ce type de prise de contrôle de dépôt (AIR).
• Git préfère une branche nommée comme un hachage au hachage lui-même — une branche portant le SHA épinglé de 40 caractères comme nom, définie comme branche par défaut, redirige git checkout <sha> vers du code d'attaquant ; la variante de Gemini CLI éclipse FETCH_HEAD à la place (Cyber Security News).
• Le tableau des vendeurs s'établit à 2 corrigés, 1 non corrigé, 1 déprécié non corrigé — Anthropic a corrigé Claude Code en 2.1.179 et OpenAI a corrigé Codex en 0.146.0 ; Microsoft n'a publié aucun correctif Copilot, et Google a déprécié Gemini CLI sans le corriger, de sorte que chaque installation existante reste exposée (Help Net Security).
• Une seule assertion referme les deux variantes : vérifier le HEAD résolu contre le SHA épinglé après le checkout — test "$(git rev-parse HEAD)" = "<pinned-sha>" || abort — et elle doit s'exécuter dans l'agent, car aucune marketplace ne peut imposer une épingle qu'elle ne résout pas (AIR).

Le diagramme ci-dessous compresse la divulgation en une minute : la chaîne d'attaque en cinq étapes, le tableau des vendeurs à trois jours, et l'assertion qui referme la brèche.

Le mécanisme : une assertion, quatre agents

Le pinning SHA est le modèle de sécurité de la marketplace fonctionnant comme prévu. Un réviseur inspecte un plugin sur un commit, la marketplace enregistre le SHA de ce commit, et l'agent est censé installer exactement ce code pour toujours. L'échec réside dans la dernière étape. Chaque agent concerné exécute à peu près cette séquence (AIR) :

git clone  ./
git checkout aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa   # le SHA épinglé

et ne demande jamais si le checkout s'est réellement retrouvé sur le commit épinglé. Cette omission est exploitable parce que git résout les noms avant les objets : lorsqu'un nom est à la fois une ref valide et un hachage de commit, git préfère la ref et se contente d'un avertissement refname is ambiguous. L'attaquant — qui contrôle déjà le dépôt amont — crée une branche portant le nom exact du SHA épinglé de 40 caractères hexadécimaux et la définit comme branche par défaut du dépôt. Un simple git clone ramène cette branche comme ref locale, git checkout <sha> résout vers la branche, et l'arborescence de travail est désormais contrôlée par l'attaquant tandis que l'agent signale une installation réussie au SHA épinglé (Cyber Security News).

Deux conditions rendent l'astuce possible. Premièrement, rien n'interdit universellement une branche nommée comme un hachage : le check-ref-format de git accepte les noms de 40 caractères hexadécimaux, et si GitHub les refuse carrément, Bitbucket et les serveurs git auto-hébergés les autorisent — et la documentation d'Anthropic elle-même liste Bitbucket et git auto-hébergé comme backends de marketplace valides (AIR). Deuxièmement, la branche doit être celle par défaut du dépôt ; une branche non par défaut n'arrive que comme ref de suivi distant, et le checkout retombe sur le vrai commit.

Gemini CLI échoue différemment. Sa séquence d'installation récupère le commit épinglé puis fait un checkout de FETCH_HEAD :

git clone --depth 1  ./
git fetch origin 41d0bc0a4aeb2fbf797dacea39e876d98c95024b
git checkout FETCH_HEAD

Si la branche par défaut du dépôt s'appelle elle-même FETCH_HEAD, le checkout résout vers cette branche et écarte silencieusement le commit récupéré (AIR). Commande différente, même cause racine : l'agent fait confiance au nom qu'il a demandé au lieu de vérifier le commit qu'il a reçu.

L'attaque, de bout en bout : cinq étapes de l'adoption au RCE

Aucun des deux chemins d'attaque ne nécessite de contrôler la marketplace. AIR a démontré les deux :

1. Planter. L'attaquant publie un plugin réellement bénin, épinglé au commit aaa…aaa. Il passe la revue.
2. Adoption. Les utilisateurs l'installent. Chaque installation est épinglée au commit révisé.
3. Ré-épinglage. L'attaquant pousse une mise à jour de routine, toujours bénigne ; la marketplace déplace l'épingle vers bbb…bbb.
4. Rug-pull. L'attaquant crée une branche nommée bbb…bbb, la définit comme branche par défaut du dépôt et la pointe vers du code malveillant. Le commit épinglé lui-même peut rester intact.
5. Mise à jour automatique vers le RCE. L'épingle modifiée déclenche la mise à jour automatique en arrière-plan de chaque agent — comportement par défaut de Claude Code et Codex — le checkout résout la nouvelle épingle vers la branche, et le code s'exécute sans clic, sans invite et sans réinstallation (AIR).

Le chemin alternatif est plus rapide : prendre le contrôle du dépôt d'un mainteneur légitime et sauter entièrement l'étape de plantation. La recherche complémentaire d'AIR quantifie à quel point c'est déjà fréquent — 925 skills détournées de leurs mainteneurs d'origine, atteignant 134 000 agents (AIR). C'est le troisième acte d'une série : The Story of Skills montrait une skill malveillante atteignant 26 000 agents, et MCPJacking a trouvé 155 serveurs MCP détournables dans la marketplace officielle via des domaines expirés, que les chercheurs ont enregistrés pour obtenir l'exécution distante de prompts sur chaque agent qui leur faisait confiance (AIR). Plugin4Shell est la défaillance de périmètre du mécanisme que l'industrie a construit pour contenir tout cela. Le rayon d'impact est aussi plus large que l'agent : les plugins et add-ons héritent des permissions du développeur qui exécute l'agent — code source local, identifiants cloud, clés SSH, dépôts internes et systèmes de production (Cyber Security News).

Le tableau des vendeurs : deux corrigés, un non corrigé, un déprécié non corrigé

La chronologie de divulgation montre que la divulgation coordonnée a fonctionné — et où elle s'est arrêtée :

Quand	Quoi
Mai 2026	AIR trouve la faille, avec un PoC fonctionnel contre les quatre agents
Juin 2026	Divulgation coordonnée aux quatre vendeurs
17 juin 2026	Anthropic confirme le correctif dans Claude Code 2.1.179
4 août 2026	Google confirme qu'aucun correctif ne sera publié — Gemini CLI est déprécié ; les utilisateurs sont invités à migrer vers Antigravity
12 août 2026	Codex 0.146.0 d'OpenAI vérifié corrigé
17 septembre 2026	Divulgation publique

Au 18–19 septembre, le tableau est inchangé : Anthropic corrigé, OpenAI corrigé, Microsoft n'a publié aucun correctif Copilot, et Google a déprécié Gemini CLI sans le corriger — ce qui signifie que chaque installation existante de Gemini CLI reste exposée indéfiniment (Help Net Security). La réponse de GitHub — interdire les noms de branches et de tags en forme de SHA sur sa plateforme — ne referme pas la brèche, car les marketplaces peuvent être hébergées sur Bitbucket ou des serveurs git auto-hébergés où ces noms restent légaux (Cyber Security News).

Le résumé d'AIR est le plus honnête : « The fix has to ship in the agent, and updating is the only complete mitigation where one exists » (AIR). La raison structurelle mérite d'être reformulée pour les conversations d'achat : l'épingle est résolue dans l'agent, donc une marketplace ne peut pas imposer la garantie qu'elle annonce. L'analyse des téléversements par les vendeurs (Anthropic a déployé Skill/Plugin Scanning le 6 août 2026) réduit la probabilité qu'un plugin malveillant entre dans la marketplace, mais ne peut pas se substituer à la vérification du checkout côté agent — l'échange se produit après la revue, au moment de la résolution (MCP Security Hardening Checklist). C'est aussi l'exposé de gouvernance : quatre vendeurs, un défaut de conception partagé, et une réponse asymétrique de trois jours qu'une organisation acheteuse peut lire comme la cadence de correctifs de sécurité d'un vendeur en miniature.

Vérification après le checkout : le contrôle qui se généralise

Le correctif d'une ligne d'AIR referme les deux variantes (AIR) :

test "$(git rev-parse HEAD)" = "" || abort

Les détails portent la leçon. git rev-parse HEAD résout ce que l'arborescence de travail contient réellement — pas le nom qui a été demandé. Cette distinction est précisément ce que la variante FETCH_HEAD de Gemini fait passer. Et la vérification doit s'exécuter dans l'agent, car l'épingle est résolue côté client. Une marketplace qui vérifierait après le checkout ne ferait que vérifier son propre enregistrement ; l'agent est le composant qui doit avorter en cas de divergence.

Ce motif — vérifier après la résolution, pas avant — se généralise à chaque contrôle d'artefact épinglé dans une pile d'agents. Une version de serveur MCP épinglée, une skill épinglée, des poids de modèle épinglés, un digest de conteneur épinglé : chacun est une affirmation qu'un installateur est censé honorer et dont personne ne vérifie la résolution. La même assertion manquante vit partout où le checkout se produit. Quatre points à traiter cette semaine :

1. Mettre à jour les agents qui ont des correctifs. Claude Code vers 2.1.179 ou supérieur ; Codex vers 0.146.0 ou supérieur. Copilot et Gemini CLI n'ont pas de correctif — restreins ce que ces agents peuvent atteindre (système de fichiers, identifiants, sortie réseau) jusqu'à publication, ou suis le chemin de migration du vendeur.
2. Inventorier chaque artefact épinglé. Plugins, skills, versions de serveurs MCP, installateurs internes. Pour chacun, confirmer si un chemin de code omet l'assertion du HEAD résolu — cela inclut les outils internes écrits par votre équipe, pas seulement les agents de vendeurs.
3. Auditer les dépôts de plugins pour détecter les signaux de prise de contrôle. Changements de branches inattendus, déplacements de branche par défaut, transferts de propriété. Les 925 skills détournées l'ont été avant cette divulgation ; la prise de contrôle de dépôts est l'étape d'entrée et elle opère déjà à grande échelle (Cyber Security News).
4. Traiter la mise à jour automatique des plugins comme un canal de livraison de chaîne d'approvisionnement, pas comme une commodité. Liste blanche des marketplaces et dépôts dont les agents peuvent tirer ; soumettre les ré-épinglages à une re-revue là où la configuration de l'agent le permet. La propriété zero-click vient de la mise à jour automatique — retirez le « zéro » et l'attaque nécessite à nouveau une action de l'utilisateur.

Deux CVE adjacents, et l'exposition persistante

La même semaine a produit deux CVE de serveurs MCP partageant le thème de Plugin4Shell — une confiance placée dans un composant qui n'a jamais vérifié son appelant. CVE-2026-54618 affecte Obsidian Web MCP avant 0.2.0 : le point de terminaison d'autorisation OAuth émettait des codes à n'importe quel appelant sans authentifier l'utilisateur, accordant à un attaquant distant non authentifié un accès complet en lecture, écriture, recherche, déplacement et suppression à l'ensemble du vault, corrigé en 0.2.0 (Rapid7 ; GitHub advisory GHSA-hwhg-mrjc-8g43). CVE-2026-54446 est un défaut d'authentification manquante (CWE-306) dans NetLicensing-MCP (Practical DevSecOps). Ils s'ajoutent aux chiffres de fond de l'écosystème qui n'ont pas bougé depuis des mois : 97M+ de téléchargements mensuels MCP, 82 % des serveurs échantillonnés vulnérables au path traversal, et seulement 8,5 % utilisant OAuth (Practical DevSecOps).

Le motif à travers les trois divulgations est le même à chaque couche de la pile d'agents : un mécanisme de confiance — une épingle, un flux OAuth, un point de terminaison serveur — qui effectue sa vérification au mauvais moment ou pas du tout. Plugin4Shell est simplement le premier à avoir franchi d'un produit à tout l'écosystème d'un coup.

Lectures associées

• MCP Security Hardening Checklist: 1,467 Exposed Servers and the Controls That Close Them — la ligne de base de 12 contrôles où s'insère cette vulnérabilité : Plugin4Shell appartient à la couche chaîne d'approvisionnement (contrôles 5–7), à côté de la mise à jour Skill/Plugin Scanning
• Shadow AI Agents: 17,800 Add-Ons, 6.7 Million Installations, and the Runtime Control Gap — l'inventaire et l'écart de contrôle à l'exécution qui déterminent si un add-on détourné sera remarqué
• The First MCP CVE on the KEV List Hit Its Federal Deadline: LiteLLM and the Default-Key Vault — le CVE MCP qui a atteint le statut de remédiation fédérale, et les six points de vérification de passerelle qui le referment

---

Un distributeur industriel de taille intermédiaire exécute Claude Code pour ses outils internes et un agent d'approvisionnement qui chiffre contre NetSuite et deux catalogues de fournisseurs. L'équipe inventorie chaque artefact épinglé sur les deux surfaces, met Claude Code à jour en 2.1.179, désactive la mise à jour automatique des plugins en arrière-plan, et ajoute l'assertion du HEAD résolu à son installateur interne de modules MCP. Les sources de plugins passent à une liste autorisée de deux dépôts révisés, et la piste d'audit enregistre chaque ré-épinglage avec son diff. Le prochain incident de marketplace devient un saut de version et une revue, pas une réponse à incident.

Demandez un build à périmètre défini. Une semaine de découverte. Vous obtenez un inventaire système, une carte des flux de travail et un périmètre fixe — que vous construisiez avec nous ou non.