La vulnérabilité Plugin4Shell des agents IA a contourné les plugins de confiance, laissant deux outils de programmation sans correctif

Plugin4Shell a compromis une protection essentielle dans quatre agents de programmation IA, alors même que les utilisateurs suivaient le processus prévu pour installer des plugins examinés. L’entreprise de sécurité AIR affirme que la faille touchait Claude Code, OpenAI Codex, GitHub Copilot et Gemini CLI. Ses chercheurs ont démontré une exécution de code à distance fonctionnelle contre les quatre produits.

Anthropic et OpenAI ont publié des correctifs après avoir reçu la divulgation d’AIR. Lors de la publication de ses conclusions, le 17 septembre 2026, AIR n’avait signalé aucun correctif correspondant pour GitHub Copilot. L’entreprise a également indiqué que Google ne corrigerait pas le comportement affectant Gemini CLI, orientant les utilisateurs vers Antigravity.

Cette réponse inégale constitue le problème central. Les places de marché de plugins promettent que l’examen et l’épinglage de commits protègent les développeurs contre les modifications de code après approbation. La vulnérabilité Plugin4Shell des agents IA aurait rompu cette promesse sans nécessiter une installation imprudente, une approbation suspecte ou un nouveau clic.

Plugin4Shell a transformé une mise à jour de confiance en exécution de code à distance

L’attaque visait le processus de distribution des plugins, et non le modèle de langage chargé de répondre à une invite.

Les agents de programmation IA prennent de plus en plus en charge les plugins, compétences, extensions et autres modules complémentaires. Ces paquets peuvent personnaliser les flux de travail, connecter des services ou exécuter du code dans des environnements de développement. Ils héritent souvent de la capacité de l’agent à accéder aux fichiers, exécuter des commandes shell et interagir avec des systèmes authentifiés.

Cet accès rapproche un plugin d’agent d’une application locale plutôt que d’une simple invite textuelle passive. Si un code malveillant atteint le répertoire des plugins, il peut fonctionner avec les autorisations accordées au développeur qui exécute l’agent.

AIR affirme que Plugin4Shell a atteint ce stade en contournant l’épinglage SHA. Un SHA est un identifiant cryptographique couramment utilisé pour désigner un commit Git précis. Épingler un plugin à cet identifiant devrait maintenir son code installé inchangé, même si son dépôt évolue ultérieurement.

Selon la recherche sur Plugin4Shell, les agents concernés demandaient un commit épinglé, mais ne vérifiaient pas que ce commit était réellement extrait. Un attaquant contrôlant le dépôt en amont pouvait exploiter le comportement de résolution des noms de Git et substituer un code différent.

L’enregistrement de la place de marché pouvait toujours afficher l’identifiant de commit attendu. L’agent pouvait également signaler une installation réussie. Cependant, les fichiers du répertoire de travail provenaient d’une branche contrôlée par l’attaquant plutôt que du commit examiné.

AIR a décrit deux voies d’intrusion pratiques. Un attaquant pouvait publier un plugin légitime, développer son adoption, puis rendre le dépôt malveillant lors d’une mise à jour ultérieure. Il pouvait également prendre le contrôle du dépôt prenant en charge un plugin existant.

La seconde voie importe, car elle déplace la responsabilité au-delà des seuls auteurs de plugins. Un plugin peut démarrer comme un projet légitime et passer tous les examens. Son dépôt ne peut devenir hostile qu’après que les développeurs et les équipes de sécurité lui ont accordé leur confiance.

AIR indique que les chercheurs ont découvert le problème en mai 2026 et l’ont divulgué aux quatre fournisseurs en juin. L’entreprise a publié son compte rendu technique le 17 septembre. Help Net Security a rapporté ces conclusions le lendemain.

Aucune preuve publique citée par l’une ou l’autre organisation ne montrait que Plugin4Shell avait été exploité contre de véritables victimes avant sa divulgation. L’impact démontré provient des tests de preuve de concept d’AIR, et non d’une campagne criminelle documentée.

Cette distinction limite ce qui peut être affirmé concernant une compromission immédiate. Elle ne réduit pas l’importance du contrôle défaillant. Une attaque réussie exécuterait du code via un composant que les organisations avaient déjà examiné et approuvé.

Le problème s’inscrit également dans la continuité de précédentes recherches d’AIR sur la distribution de plugins. L’entreprise affirme qu’une compétence de test a atteint plus de 26 000 agents avant son retrait. Des recherches distinctes auraient identifié 925 compétences détournées touchant 134 000 agents.

Ces chiffres proviennent d’AIR et n’ont pas été reproduits indépendamment dans la divulgation de Plugin4Shell. Ils illustrent l’argument plus large des chercheurs : obtenir une distribution et compromettre des dépôts en amont sont des étapes réalistes, et non de simples prérequis théoriques.

Comment la vulnérabilité Plugin4Shell des agents IA a contourné l’épinglage SHA

Plugin4Shell a fonctionné parce que chaque agent concerné faisait confiance à la référence Git demandée au lieu de vérifier le commit finalement extrait.

Claude Code, Codex et GitHub Copilot auraient partagé une même variante. Leurs installateurs de plugins clonaient un dépôt et transmettaient l’identifiant de commit épinglé de 40 caractères à git checkout.

Git autorise, dans de nombreuses configurations d’hébergement, des noms de branches ressemblant à des identifiants de commits. Lorsqu’un nom peut désigner à la fois une branche et un objet, Git peut le résoudre comme une référence tout en affichant un avertissement d’ambiguïté.

Un attaquant contrôlant le dépôt du plugin pouvait créer une branche portant exactement le nom du commit épinglé. L’attaquant pouvait ensuite faire de cette branche la branche par défaut du dépôt et la faire pointer vers un code malveillant.

Le clonage initial récupérait la branche par défaut de l’attaquant. L’extraction suivante pouvait résoudre l’identifiant apparent du commit vers cette branche locale. L’agent chargeait ou exécutait alors des fichiers différents de ceux examinés par la place de marché.

Cette technique ne fonctionne pas de manière identique sur tous les services d’hébergement. GitHub bloque les noms de branches et d’étiquettes qui ressemblent à des identifiants complets d’objets Git, selon ses restrictions sur les noms de branches.

Cependant, AIR affirme que Bitbucket et les services Git auto-hébergés peuvent accepter de tels noms. Certaines places de marché d’agents prennent officiellement en charge des dépôts hébergés en dehors de GitHub, laissant cette configuration plus large exposée.

Gemini CLI aurait emprunté une voie distincte pour parvenir au même résultat. Son installateur récupérait le commit épinglé, puis exécutait une extraction sur FETCH_HEAD, une référence Git pointant normalement vers du contenu récupéré.

AIR a constaté qu’un dépôt pouvait utiliser FETCH_HEAD comme nom de branche par défaut. L’extraction pouvait alors se résoudre vers cette branche plutôt que vers le fichier spécial contenant le commit récupéré.

Les deux variantes dépendaient d’une comparaison finale manquante. Après avoir terminé l’extraction, l’agent devait résoudre HEAD et vérifier qu’il correspondait au SHA épinglé par la place de marché.

Cette vérification est modeste, mais son emplacement compte. Une place de marché ne peut pas confirmer ce qu’un client a finalement placé dans son arborescence de travail locale. La vérification doit avoir lieu dans l’agent qui effectue le clonage et l’extraction.

L’appellation « zéro clic » provient des mises à jour en arrière-plan. AIR indique que Claude Code et Codex mettent automatiquement à jour les plugins installés par défaut. Un remplacement malveillant pouvait donc arriver après qu’une place de marché a modifié son épingle, sans nouvelle décision d’installation.

La victime n’aurait pas besoin de trouver un nouveau plugin malveillant. L’attaquant ciblerait un plugin déjà présent sur la machine et attendrait le processus de mise à jour de l’agent.

L’exécution de code à distance, ou RCE, signifie que des instructions contrôlées par l’attaquant s’exécutent sur le système cible. La portée qui en résulte dépend du compte, de l’environnement, du bac à sable, des identifiants et de l’accès réseau disponibles pour l’agent affecté.

AIR décrit l’impact potentiel comme équivalent à l’accès détenu par l’employé exécutant l’outil. Il s’agit d’une description du pire scénario, et non d’une mesure universelle de chaque installation.

Un agent fortement isolé pourrait n’exposer qu’un espace de travail temporaire. Un agent installé localement disposant d’identifiants cloud, de dépôts source, de clés de signature ou d’un accès à la production crée un rayon d’impact potentiel bien plus large.

Cette variabilité explique pourquoi un simple inventaire des versions est insuffisant. Les équipes de sécurité doivent également savoir où chaque agent s’exécute, quels plugins il charge et quels identifiants sont disponibles dans cette limite d’exécution.

L’examen des plugins a fonctionné comme prévu, mais le code installé a tout de même changé

Le conflit central oppose la promesse d’un examen immuable à la réalité de la résolution Git côté client.

Les contrôles de la chaîne logistique logicielle séparent souvent l’approbation de l’exécution. Un examinateur évalue une version connue, enregistre son condensat et autorise les systèmes à n’installer que cette version.

Ce modèle suppose que le condensat identifie les fichiers qui seront exécutés. Plugin4Shell aurait préservé l’épingle visible tout en rompant le lien entre cette épingle et l’arborescence de travail finale.

C’est plus grave que de simplement mettre les utilisateurs en garde contre des extensions inconnues. Les chercheurs affirment que l’attaque fonctionne toujours lorsqu’un plugin provient d’une place de marché de confiance, passe un examen et reste épinglé.

Des recommandations de sécurité fondées uniquement sur la réputation de la place de marché manqueraient donc l’étape vulnérable. L’attaquant n’a pas besoin de compromettre la base de données de la place de marché si l’agent local peut être trompé lors de l’extraction.

La même limite s’applique aux catalogues internes de plugins. Une entreprise peut examiner chaque paquet et mettre en miroir les métadonnées approuvées. Ces contrôles restent incomplets si les clients des employés ne valident pas le commit résolu.

AIR qualifie Plugin4Shell de première vulnérabilité de chaîne logistique de l’écosystème des agents IA. Cette formulation est la caractérisation de l’entreprise et mérite une certaine prudence.

Les outils de développement IA ont déjà fait face à l’empoisonnement de dépôts, à l’injection d’invites, à des fichiers de configuration malveillants et à des vulnérabilités liées aux extensions. Plugin4Shell est plus limité dans un sens, car il se concentre sur les modules complémentaires d’agents épinglés et leur voie de mise à jour.

Néanmoins, le mécanisme révèle une défaillance de confiance distincte. Il s’attaque à la façon dont une fonctionnalité d’agent examinée passe d’un dépôt à la machine d’un développeur.

Des recherches récentes montrent qu’il ne s’agit pas d’un point de pression isolé. Wiz a divulgué GhostApproval en juillet 2026 après avoir testé six assistants de programmation IA. Ce problème utilisait des liens symboliques pour atteindre des fichiers en dehors des limites attendues de l’espace de travail.

Les conclusions sur GhostApproval affectaient des produits d’Amazon, Anthropic, Augment, Cursor, Google et Windsurf. Les réponses des fournisseurs ont varié, avec plusieurs correctifs et au moins une décision contestée concernant le modèle de menace.

GhostApproval et Plugin4Shell utilisent des primitives techniques différentes. L’un exploite la résolution de chemins via des liens symboliques. L’autre exploiterait la résolution de références Git lors de l’installation et des mises à jour de plugins.

Le schéma qui les relie est un écart entre la décision visible de l’utilisateur et l’action réelle du système. Un chemin semble local mais se résout ailleurs. Une épingle semble immuable mais se résout vers un code différent.

Les invites d’autorisation ne peuvent pas, à elles seules, corriger cette divergence. Les utilisateurs ne peuvent pas prendre des décisions éclairées lorsque l’interface affiche le nom de confiance tandis que l’opération sous-jacente cible autre chose.

Anthropic a publiquement décrit l’isolation du système de fichiers et du réseau comme des protections complémentaires pour Claude Code. Son modèle de sandboxing vise à empêcher qu’un processus injecté accède à des fichiers sensibles ou à des destinations réseau non autorisées.

Le sandboxing peut réduire l’impact d’un code de plugin malveillant. Il ne remplace pas une vérification exacte des paquets, en particulier lorsque les plugins s’exécutent en dehors des mêmes restrictions ou reçoivent des autorisations plus larges.

Les entreprises ont donc besoin de deux limites indépendantes. Le processus d’installation doit vérifier que le code examiné est réellement installé. L’environnement d’exécution doit limiter ce que ce code peut atteindre après son exécution.

Une défaillance dans l’une ou l’autre couche ne devrait pas automatiquement mener à la compromission d’un poste de travail ou d’un compte cloud. Plugin4Shell est important, car de nombreux déploiements d’agents combinent encore des extensions modifiables avec de précieux identifiants locaux.

Quatre agents de programmation ont produit quatre résultats de sécurité différents

La divulgation a révélé un processus de correction fragmenté entre des outils qui mettent en œuvre des flux de travail de plugins similaires.

AIR indique qu’Anthropic a corrigé la vulnérabilité de Claude Code dans la version 2.1.179. L’entreprise a consigné le 17 juin 2026 comme date de confirmation de la correction par Anthropic.

Selon AIR, OpenAI a corrigé le comportement affecté de Codex dans la version 0.146.0. La chronologie de recherche indique que l’entreprise a vérifié cette version comme corrigée le 12 août.

Les utilisateurs de ces produits ne doivent pas supposer que les mises à jour automatiques se sont achevées avec succès. Les postes de travail administrés, les environnements hors ligne, les verrous de paquets et les systèmes de distribution internes peuvent laisser des versions plus anciennes installées.

Les organisations devraient interroger les terminaux réels et comparer leurs versions avec les versions corrigées. Elles devraient également redémarrer les sessions de longue durée si leur processus de déploiement ne remplace pas les processus d’agents actifs.

GitHub Copilot pose un problème différent. AIR a déclaré que Microsoft avait reçu le même rapport de vulnérabilité, mais n’avait pas publié de correctif lorsque la recherche est devenue publique.

GitHub avait récemment étendu les contrôles centralisés des opérations des agents. Son annonce du 9 septembre indiquait que les administrateurs pouvaient bloquer, autoriser ou exiger une approbation pour les commandes shell, les opérations sur les fichiers et les domaines réseau via les autorisations d’agents gérées.

Ces contrôles peuvent limiter les conséquences, mais ils ne constituent pas la preuve d’un correctif Plugin4Shell. Un installateur non corrigé et une politique d’exécution restrictive traitent différentes étapes de l’attaque.

Les administrateurs de Copilot devraient donc rechercher un avis spécifique au produit, une version corrigée ou une confirmation du fournisseur. En attendant, les organisations peuvent suspendre les mises à jour de plugins de la marketplace ou limiter les agents à des dépôts approuvés sous leur contrôle.

Gemini CLI présente le statut le plus complexe. AIR indique que Google a confirmé le 4 août qu’il ne corrigerait pas le flux de travail affecté et conseillait de migrer vers Antigravity.

Google avait déjà commencé à faire migrer les utilisateurs individuels de Gemini CLI vers Antigravity CLI. Une annonce de juin indiquait que Gemini CLI ne traitait plus les requêtes des comptes individuels, tandis que l’utilisation en entreprise et avec une clé API restait disponible.

Cependant, le précédent avis de transition de Google indiquait également que le projet open source Gemini CLI continuerait à recevoir des mises à jour de modèles, des corrections de bugs et des correctifs de sécurité pour les clients d’entreprise.

Cette formulation publique ne correspond pas parfaitement à l’affirmation selon laquelle chaque installation de Gemini CLI restera vulnérable indéfiniment. Elle laisse une importante lacune de vérification pour les administrateurs.

Le journal des modifications de Google de septembre montre que les versions de Gemini CLI ont continué après la transition des utilisateurs grand public. Il répertorie également un renforcement de la sécurité sans rapport avec la faille précise liée au checkout. Cette activité n’établit pas l’existence d’un correctif Plugin4Shell.

La conclusion prudente est plus limitée. AIR n’a signalé aucun correctif Plugin4Shell pour Gemini CLI au moment de la divulgation et a recommandé Antigravity. Google a continué à maintenir certaines parties de Gemini CLI pour l’usage en entreprise, mais aucune note de version citée n’identifie cette correction spécifique.

Les utilisateurs d’entreprise ne devraient pas déduire un niveau de sécurité à partir d’un langage général sur la maintenance. Ils ont besoin d’une confirmation directe que leur version vérifie le commit final récupéré après l’installation ou la mise à jour d’une extension.

Ils devraient également éviter de considérer la migration comme un simple changement de nom. Migrer des compétences, des hooks, des serveurs MCP et des identifiants vers un nouvel agent peut reproduire d’autres risques si les configurations sont transférées sans examen.

AIR indique qu’Antigravity n’utilise pas le mécanisme d’épinglage SHA de plugins exploité par Plugin4Shell. Cela signifie que ce vecteur précis ne s’applique pas, selon l’analyse des chercheurs.

Cela ne signifie pas qu’Antigravity est immunisé contre les plugins malveillants, l’injection de prompts, les outils non sûrs ou de futures défaillances de la chaîne d’approvisionnement. Les équipes de sécurité devraient conserver les mêmes exigences d’isolation et de moindre privilège après la migration.

Les quatre réponses révèlent un problème de gouvernance qui dépasse ce bug. Des fonctionnalités similaires peuvent être livrées dans plusieurs agents sans conventions de divulgation communes, notation de gravité partagée ni remédiation synchronisée.

Les développeurs doivent suivre des journaux de modifications et déclarations de fournisseurs distincts. Les administrateurs d’entreprise doivent ensuite traduire ces informations inégales en une posture de sécurité unique et applicable.

Ce que les équipes de développement devraient changer immédiatement

La première priorité est d’arrêter les mises à jour de plugins vulnérables, de vérifier les versions des agents et de réduire les identifiants accessibles à chaque agent de programmation.

Pour Claude Code, les organisations devraient mettre toutes les installations à jour vers la version 2.1.179 ou ultérieure. Pour Codex, AIR identifie la version 0.146.0 comme la version corrigée.

Les équipes devraient vérifier les versions par l’inventaire des terminaux plutôt que par des enquêtes. Les développeurs peuvent utiliser plusieurs agents de programmation dans des terminaux locaux, des extensions d’IDE, des espaces de travail distants et des systèmes CI.

Pour GitHub Copilot, les administrateurs devraient demander des recommandations explicites de remédiation à GitHub ou Microsoft. Ils ne devraient pas considérer des améliorations d’autorisations sans rapport comme la confirmation que la vulnérabilité de checkout a été corrigée.

Lorsque la fonctionnalité de plugins n’est pas essentielle, désactiver les paquets tiers de la marketplace offre la réduction temporaire la plus claire. Les organisations qui ne peuvent pas les désactiver devraient suspendre les mises à jour automatiques et restreindre les sources de dépôts.

Les utilisateurs de Gemini CLI devraient évaluer la migration vers Antigravity, notamment lorsqu’ils utilisent des extensions de marketplace. Les clients d’entreprise devraient également demander une confirmation écrite du statut de leur version exacte de Gemini CLI.

Supprimer un plugin affecté après la divulgation est utile, mais incomplet. Un paquet compromis aurait pu créer un mécanisme de persistance, modifier des fichiers de démarrage, copier des identifiants ou altérer des dépôts avant sa suppression.

Les intervenants en réponse aux incidents devraient examiner l’historique des mises à jour de plugins, l’activité Git, l’exécution des processus, les connexions réseau et les modifications de fichiers sensibles. La fenêtre temporelle pertinente commence avant la divulgation publique si des mises à jour automatiques vulnérables étaient actives.

Les équipes devraient faire pivoter les identifiants lorsque la télémétrie indique que du code de plugin inattendu a été exécuté. Les cibles prioritaires comprennent les jetons de contrôle de code source, les identifiants cloud, les clés de publication de paquets, le matériel de signature et les secrets stockés dans les environnements shell.

La portée des identifiants compte autant que leur rotation. Un agent de programmation IA ne devrait pas hériter d’un accès illimité à la production simplement parce que le développeur qui le lance détient ces autorisations.

Des identités d’agents distinctes facilitent le confinement et l’audit des actions anormales. Des jetons de courte durée limitent également la valeur des identifiants collectés depuis un poste de travail.

L’isolation à l’exécution fournit une couche supplémentaire. L’accès aux fichiers devrait par défaut être limité au projet actif, tandis que l’accès réseau devrait utiliser une liste d’autorisation restreinte adaptée à la tâche.

L’exécution de commandes shell exige des limites similaires. Un plugin capable d’invoquer n’importe quelle commande sous le compte d’un développeur peut contourner de nombreux contrôles appliqués uniquement au code source généré.

Les organisations devraient vérifier si les règles de sandbox couvrent les sous-processus créés par les plugins, les hooks, les gestionnaires de paquets et les serveurs MCP. Une restriction sur les outils directs du modèle peut ne pas couvrir chaque processus d’extension.

La gouvernance des plugins nécessite également des preuves plus solides. Un catalogue interne devrait stocker le commit examiné, l’origine du dépôt, l’identifiant d’arborescence résolu, le relecteur, la date d’approbation et la version déployée.

L’installateur devrait valider le HEAD résolu après le checkout. S’il ne correspond pas au commit approuvé, l’installation doit s’arrêter plutôt que d’afficher un avertissement et de continuer.

Les équipes de sécurité peuvent tester ce comportement sans reproduire une exécution malveillante. Un dépôt contrôlé peut présenter des références ambiguës tandis que le système de validation vérifie que l’installation échoue de façon sûre.

Le résultat devrait faire partie des tests d’approvisionnement et d’acceptation interne. Les fournisseurs devraient être en mesure d’expliquer comment leurs agents vérifient le contenu des plugins après clonage, récupération et mise à jour.

Les équipes ont également besoin d’un registre fiable expliquant pourquoi chaque plugin existe. Une base de connaissances d’ingénierie consultable peut relier les approbations, les responsables, les incidents et les décisions de remplacement.

Cette documentation ne prévient pas l’exploitation. Elle réduit le temps nécessaire pour identifier les équipes affectées et supprimer les intégrations risquées lorsqu’une autre divulgation apparaît.

Enfin, les développeurs ne devraient pas être blâmés pour avoir fait confiance à un épinglage annoncé. Plugin4Shell aurait contourné un contrôle conçu pour rendre cette confiance raisonnable.

L’action corrective relève à la fois du code des fournisseurs, de la politique d’entreprise et de l’architecture d’exécution. Former les utilisateurs à inspecter chaque mise à jour ne peut compenser un installateur qui exécute un code différent de celui dont le condensat a été approuvé.

Trois signaux indiqueront si la sécurité des plugins d’agents s’améliore

Le prochain test consiste à voir si les fournisseurs transforment cette divulgation en contrôles d’installation vérifiables plutôt qu’en promesses de sécurité plus larges.

Le premier signal est une remédiation spécifique pour GitHub Copilot. Les administrateurs devraient rechercher un avis de sécurité, un identifiant de version ou une déclaration technique confirmant la vérification du commit après checkout.

Une mise à jour générale de Copilot ne répondra pas à la question. L’élément de preuve pertinent est de savoir si le client résout le HEAD de l’arborescence de travail et le compare avec l’épinglage de la marketplace.

Si GitHub documente ce comportement et le déploie sur les surfaces Copilot prises en charge, l’actuelle lacune de correction se réduira. Un silence persistant renforcerait les inquiétudes concernant une gestion incohérente des vulnérabilités.

Le deuxième signal est une clarification de Google pour les utilisateurs d’entreprise de Gemini CLI. Le langage public de transition indique que l’accès en entreprise et la maintenance de sécurité se poursuivent, tandis qu’AIR ne signale aucun correctif Plugin4Shell.

Google peut résoudre cette tension en nommant les versions affectées, en expliquant si un correctif existe et en définissant les dates de support. Un avis spécifique aiderait les équipes à décider entre correction et migration.

Si Gemini CLI reçoit une vérification de commit validée, le statut d’AIR au moment de la divulgation deviendra obsolète. Si Google confirme que cela n’arrivera pas, les organisations devraient considérer la migration comme une exigence de sécurité plutôt qu’une préférence produit.

Le troisième signal est l’adoption, au niveau des marketplaces, d’un comportement client vérifiable. Les marketplaces ne peuvent pas imposer seules le checkout final, mais elles peuvent exiger des agents compatibles et rejeter les configurations de dépôts non sûres.

Parmi les changements utiles figureraient des manifestes signés, des artefacts de paquets immuables, des attestations de provenance et des reçus d’installation contenant le commit résolu. Chaque contrôle devrait rester testable indépendamment.

Les fournisseurs d’agents devraient également indiquer si les plugins s’exécutent dans la même sandbox que les commandes générées. Un paquet vérifié peut tout de même être compromis en amont avant examen ou contenir une vulnérabilité passée inaperçue.

La leçon plus large n’est pas que les plugins sont intrinsèquement non sûrs. C’est que les agents autonomes transforment les erreurs de packaging en actions effectuées avec les privilèges des développeurs.

Plugin4Shell aurait traversé quatre produits concurrents parce que leurs implémentations reposaient sur la même hypothèse non vérifiée. L’identifiant Git demandé était traité comme équivalent au code effectivement installé.

Les développeurs et responsables de la sécurité devraient désormais poser une question directe à chaque fournisseur d’agents de programmation : qu’est-ce qui prouve que le code examiné est celui qui s’exécute sur la machine ?

Tant que Copilot et Gemini CLI ne disposent pas de réponses spécifiques au produit, les organisations concernées devraient limiter l’usage des plugins, vérifier chaque version d’agent et isoler les identifiants. Les équipes utilisant Claude Code ou Codex corrigés devraient tout de même auditer les extensions installées et confirmer que les mises à jour ont atteint chaque terminal.

La vulnérabilité de l’agent IA Plugin4Shell est, en définitive, un test de visibilité opérationnelle. Votre organisation peut-elle identifier chaque agent, ses plugins, sa version et ses privilèges avant la prochaine mise à jour en arrière-plan ?