Une défaillance du verrouillage des plugins expose les agents de programmation IA à des substitutions furtives dans la chaîne d’approvisionnement

Le propriétaire d’un dépôt peut contourner le verrouillage des versions des plugins dans quatre agents de programmation IA très utilisés, et ainsi leur faire installer du code non vérifié tout en continuant à afficher la version attendue.

Cette vulnérabilité de la chaîne d’approvisionnement, baptisée Plugin4Shell par Air Security, affecte Anthropic Claude Code, OpenAI Codex, GitHub Copilot et Google Gemini CLI. Air a testé avec succès l’attaque contre les quatre produits en mai et en a informé leurs éditeurs en juin.

Anthropic et OpenAI ont publié des correctifs. GitHub Copilot n’est toujours pas corrigé, selon Air, tandis que Google ne prévoit pas de corriger Gemini CLI, dont le retrait est programmé. Aucun CVE ni avis de sécurité des éditeurs n’avait été publié au 18 septembre 2026, et rien n’indiquait une exploitation dans le cadre d’attaques réelles.

Un commit verrouillé ne garantit pas un code verrouillé

Les agents de programmation IA peuvent étendre leurs fonctionnalités en téléchargeant des plugins depuis des marketplaces et des dépôts de code source externes. Pour empêcher toute modification du code après sa validation, une marketplace peut identifier chaque plugin approuvé à l’aide d’un hash de commit Git.

Ce hash devrait correspondre à un instantané immuable du dépôt. Or, dans les agents concernés, le processus d’installation ne vérifie pas correctement que le contenu téléchargé correspond au commit indiqué.

Plugin4Shell exploite une ambiguïté dans la manière dont Git résout les références. Sur un service d’hébergement qui l’autorise, le propriétaire d’un dépôt peut créer une branche dont le nom ressemble au hash du commit verrouillé du plugin. Il lui suffit ensuite de faire pointer cette branche vers un autre commit contenant du code malveillant.

Lorsque l’agent demande ce qu’il croit être le commit approuvé, Git peut interpréter la valeur comme le nom d’une branche contrôlée par l’attaquant. L’installateur récupère alors le code d’un autre commit, mais l’agent continue d’indiquer que le plugin correspond à la version attendue et verrouillée.

Cette faille compromet à la fois la revue du code et la transparence des versions. Un plugin peut sembler inchangé aux yeux de l’utilisateur alors que son contenu exécutable a été remplacé.

La modification publique apportée par OpenAI à Codex décrit le même mode opératoire : Git peut traiter un commit SHA demandé comme une référence de branche, ce qui permet à la source d’un plugin de pointer vers un commit différent de celui enregistré dans le fichier de verrouillage. Le correctif est inclus dans Codex 0.146.0.

L’exploitation dépend de l’hébergeur du dépôt

La technique de la branche dont le nom ressemble à un hash ne fonctionne pas de la même manière sur toutes les plateformes d’hébergement. GitHub interdit les noms de branches et de tags qui ressemblent à des hash de commit, ce qui bloque cette méthode particulière pour les dépôts qui y sont hébergés.

Air a constaté que l’attaque fonctionnait sur Bitbucket et sur des serveurs Git exploités en interne, qui peuvent autoriser ce type de nom. Les agents de programmation concernés prennent en charge les plugins provenant de ces dépôts externes.

Cette distinction réduit considérablement l’exposition des utilisateurs qui s’appuient uniquement sur les marketplaces par défaut. Une analyse des catalogues des agents et de la vulnérabilité sous-jacente réalisée le 18 septembre a montré que le catalogue communautaire d’Anthropic ainsi que les catalogues par défaut de Claude Code et de Copilot faisaient référence à des dépôts GitHub.

L’hébergement sur GitHub ne constitue toutefois pas une solution générale au problème de validation. Copilot, par exemple, peut installer des plugins depuis des dépôts situés en dehors de GitHub. Les utilisateurs qui ajoutent un dépôt Bitbucket, un serveur Git privé ou un autre hébergeur autorisant les noms de références ambigus restent exposés s’ils utilisent un agent non corrigé.

Gemini CLI présente également un problème distinct de résolution des dépôts. Selon Air, son installateur peut être influencé par un dépôt dont la branche principale est nommée FETCH_HEAD. La restriction documentée par GitHub concernant les noms ressemblant à des hash n’exclut pas clairement FETCH_HEAD. Les plugins Gemini CLI hébergés sur GitHub ne peuvent donc pas être considérés comme définitivement protégés contre cette variante.

Les mises à jour automatiques peuvent supprimer la nécessité d’une nouvelle confirmation

La configuration la plus risquée est celle dans laquelle un agent met à jour en arrière-plan un plugin déjà approuvé. Une fois l’installation initiale validée par l’utilisateur, le propriétaire d’un dépôt peut modifier la cible d’une référence ambiguë et fournir un code de remplacement sans nouvelle confirmation.

Air a indiqué que les mises à jour en arrière-plan des plugins étaient activées par défaut dans Claude Code et Codex. Cela ne signifie toutefois pas que toute installation par défaut est immédiatement exposée.

Les mises à jour automatiques sont activées par défaut uniquement pour les marketplaces intégrées aux produits, qui sont hébergées sur GitHub. La documentation d’Anthropic et de GitHub indique que les mises à jour depuis des marketplaces externes sont désactivées ou facultatives. Les règles de nommage de GitHub bloquent donc la principale technique fondée sur une branche ressemblant à un hash dans ces catalogues par défaut.

Le risque augmente lorsque les organisations configurent des marketplaces privées ou installent directement des plugins depuis des dépôts pris en charge qui ne sont pas hébergés sur GitHub. L’opérateur d’une marketplace ne peut pas corriger les agents déjà déployés, car la validation des références s’effectue sur le poste de chaque utilisateur. L’agent lui-même doit confirmer que l’objet récupéré correspond exactement au commit verrouillé.

Des correctifs très différents selon les quatre agents

Produit	Situation actuelle	Réponse recommandée
Anthropic Claude Code	Air indique que le problème est corrigé dans la version 2.1.179	Passer à la version 2.1.179 ou ultérieure
OpenAI Codex	Corrigé dans la version 0.146.0	Passer à la version 0.146.0 ou ultérieure
GitHub Copilot	Aucun correctif n’a été publié, selon Air	Éviter les plugins provenant d’hébergeurs de dépôts externes non fiables
Google Gemini CLI	Google ne prévoit pas de corriger ce produit en cours de retrait	Migrer vers Antigravity lorsque cela est possible

Les notes de version d’Anthropic pour Claude Code 2.1.179 ne mentionnent pas Plugin4Shell. L’affirmation selon laquelle cette version corrige le problème vient de l’analyse d’Air. OpenAI a en revanche documenté publiquement la correction concernée de la résolution des références Git.

Air a indiqué avoir informé Microsoft en juin, mais aucune mise à jour correspondante de Copilot n’avait été publiée. En attendant, les utilisateurs de Copilot devraient considérer les plugins hébergés sur Bitbucket, des serveurs Git privés et des services similaires comme potentiellement vulnérables.

Google a cessé de distribuer Gemini CLI aux particuliers en juin et oriente désormais les utilisateurs vers Antigravity. Air a déclaré qu’Antigravity n’était pas vulnérable à cette attaque. Google a indiqué que l’accès à Gemini CLI pour les entreprises continuerait de recevoir des mises à jour, sans préciser si celles-ci corrigeraient Plugin4Shell.

Les plugins malveillants héritent des droits d’accès de l’utilisateur

Un plugin substitué s’exécute avec les privilèges dont dispose la personne qui utilise l’agent de programmation. Sa portée dépend donc des autorisations locales, des secrets stockés, de la configuration de l’agent et des sessions authentifiées.

Les conséquences possibles comprennent la lecture du code source et des fichiers locaux, l’extraction d’identifiants enregistrés ainsi que l’accès aux systèmes de développement ou d’entreprise accessibles via l’authentification existante de l’utilisateur. Les postes de travail des développeurs sont particulièrement sensibles, car ils regroupent souvent des accès aux dépôts, des identifiants cloud, du matériel de signature et une connectivité au réseau interne.

Aucune compromission confirmée ni campagne d’exploitation active n’était connue au 18 septembre 2026. Aucun identifiant CVE n’avait été attribué et aucun des quatre éditeurs n’avait publié d’avis de sécurité dédié.

Plugin4Shell montre néanmoins qu’une version affichée ne prouve pas l’identité du code installé. Le verrouillage n’a de valeur que si l’installateur vérifie l’objet Git obtenu au lieu de faire confiance à la résolution du nom.

Les installations existantes doivent faire l’objet d’une vérification distincte

La mise à niveau de Claude Code ou de Codex devrait empêcher de futures substitutions, mais les informations disponibles ne permettent pas de déterminer si l’une ou l’autre de ces mises à jour détecte ou supprime les plugins précédemment remplacés. Les organisations doivent donc traiter la remédiation et l’inspection rétrospective comme deux tâches distinctes.

Les administrateurs et les développeurs devraient :

• Mettre à niveau Claude Code vers la version 2.1.179 ou ultérieure.
• Mettre à niveau Codex vers la version 0.146.0 ou ultérieure.
• Éviter les sources de plugins externes de Copilot jusqu’à la publication d’un correctif par GitHub.
• Migrer de Gemini CLI vers Antigravity lorsque cela est possible sur le plan opérationnel.
• Comparer indépendamment le contenu des plugins installés avec celui du commit approuvé dans le dépôt.
• Examiner les plugins installés avant la mise à niveau de l’agent, plutôt que de supposer que le correctif les nettoie.
• Restreindre l’accès des plugins aux fichiers, identifiants, jetons et systèmes authentifiés.
• Examiner les dépôts de plugins et l’activité de mise à jour afin de détecter toute modification inexpliquée des références.
• Surveiller les identifiants et les services connectés afin de repérer tout accès inattendu après des mises à jour suspectes de plugins.

Les utilisateurs peuvent réduire leur exposition en privilégiant les catalogues par défaut hébergés sur GitHub, où la restriction de nommage documentée bloque l’attaque par branche ressemblant à un hash. Cette protection reste conditionnelle, notamment pour Gemini CLI en raison de la variante FETCH_HEAD.

La solution durable consiste à renforcer la validation côté client : après la récupération, l’agent doit établir que la source installée correspond exactement au commit enregistré par la marketplace ou le fichier de verrouillage. Toute validation moins stricte laisse subsister un écart entre la version affichée à l’utilisateur et le code qui s’exécute réellement.