Les agents de développement ne font plus que suggérer du code : ils lisent des fichiers, exécutent des commandes et installent des extensions. Leur chaîne de plugins devient donc une vraie chaîne d’approvisionnement logicielle.
Pourquoi le pinning SHA est censé protéger
Une marketplace peut référencer un plugin par le SHA d’un commit précis plutôt que par une branche mouvante. L’objectif est de garantir qu’une version revue aujourd’hui restera identique lors d’une installation ou d’une mise à jour ultérieure.
Plugin4Shell montre que cette garantie n’existe que si l’agent vérifie le résultat final du checkout. AIR Security a observé que les agents concernés pouvaient demander le bon identifiant sans confirmer que HEAD correspondait ensuite réellement au commit attendu.
Où se situe la faille ?
Pour Claude Code, Codex et GitHub Copilot, AIR décrit une ambiguïté possible lorsque l’hébergeur Git autorise une branche dont le nom ressemble exactement à un SHA. Git peut alors résoudre ce nom comme une référence plutôt que comme l’objet attendu.
Ce détail est important : GitHub interdit ce type de nom de branche en SHA complet. Cette variante concerne donc surtout les hébergeurs qui l’acceptent, notamment certains Git auto-hébergés ou Bitbucket. AIR décrit une variante différente pour Gemini CLI autour de FETCH_HEAD.
Le vrai contrôle : vérifier le résultat
Après l’installation, l’agent doit résoudre le commit réellement présent dans le répertoire de travail et refuser de continuer s’il ne correspond pas au SHA attendu. Vérifier l’intention n’est pas équivalent à vérifier l’état final.
Pourquoi le scénario peut devenir « zero-click »
Le risque augmente lorsque les plugins déjà installés sont mis à jour automatiquement. Dans un scénario où le dépôt du plugin passe sous contrôle malveillant et où une nouvelle version est approuvée par la marketplace, l’agent peut récupérer puis exécuter le contenu substitué sans nouvelle action de l’utilisateur.
Le plugin hérite alors des possibilités de l’agent et de la session qui l’exécute : accès aux fichiers, au dépôt de code, à certaines commandes et potentiellement aux identifiants accessibles dans l’environnement.
Quels agents sont concernés ?
Selon l’état publié par AIR Security :
- Claude Code : corrigé à partir de la version 2.1.179.
- OpenAI Codex : corrigé à partir de la version 0.146.0.
- GitHub Copilot : AIR indiquait le 17 septembre qu’aucun correctif équivalent n’était encore disponible.
- Gemini CLI : AIR indique que le produit concerné est déprécié et ne recevra pas ce correctif.
Au 18 septembre, The Hacker News indiquait qu’aucune exploitation réelle connue n’avait été documentée publiquement et qu’aucun CVE n’avait encore été attribué.
Les protections utiles dès maintenant
- Mettre à jour les agents vers une version corrigée lorsqu’elle existe.
- Limiter les plugins installés et supprimer ceux qui ne sont plus nécessaires.
- Réduire les privilèges des sessions qui exécutent un agent ou un plugin.
- Éviter d’exposer inutilement des secrets dans l’environnement de développement.
- Contrôler les mises à jour automatiques dans les environnements sensibles.
- Vérifier le commit réellement checkouté lorsque l’outil ou le workflow permet ce contrôle.
Les plugins d’agents IA sont désormais des dépendances
La leçon dépasse cette vulnérabilité. Skills, plugins, serveurs MCP, dépôts Git et outils externes doivent être traités comme les autres dépendances de la supply chain : provenance, intégrité, permissions minimales, mises à jour maîtrisées et possibilité d’audit.
À mesure que les agents gagnent en autonomie, la question n’est plus seulement « est-ce que je fais confiance à cet agent ? », mais aussi « à quoi cet agent fait-il lui-même confiance ? ».
Sources
Publié le 20 septembre 2026. Les versions et états de correction correspondent aux informations publiques disponibles à cette date.