Plugin4Shell peut donner aux attaquants un accès sans clic aux secrets d’entreprise

Un agent de programmation doté d’un accès au terminal, aux fichiers et aux secrets d’une entreprise peut devenir une porte d’entrée sans qu’un développeur ne clique sur un lien. La faille « Plugin4Shell » expose précisément ce risque dans Claude Code, Codex, Gemini CLI et GitHub Copilot.

Le verrou des versions épinglées ne suffisait pas

Les agents de codage s’appuient de plus en plus sur des extensions : plugins, outils spécialisés ou skills — des compétences capables d’analyser un dépôt, d’exécuter des commandes ou de modifier du code. Pour éviter qu’une dépendance évolue silencieusement, les équipes peuvent normalement utiliser une version épinglée, associée à une référence précise.

Selon les éléments rapportés par Air Security, cette protection pouvait toutefois être contournée. Un attaquant capable de contrôler ou de modifier le dépôt hébergeant un plugin pouvait remplacer son code par une version malveillante, y compris lorsque l’agent était censé utiliser une version déterminée à l’avance.

Le problème ne tient donc pas uniquement à l’installation d’un plugin compromis. Il concerne la manière dont l’agent retrouve, télécharge et charge ce composant. La référence affichée comme fiable ne garantissait pas nécessairement que le code finalement exécuté correspondait bien à celui audité par l’entreprise.

L’attaque est qualifiée de zero-click parce qu’elle ne nécessite pas d’action explicite de la part de l’utilisateur au moment de l’exploitation. Si l’agent ouvre un dépôt, détecte une compétence disponible et l’active automatiquement dans son flux de travail, le code hostile peut s’exécuter dans le cadre des permissions déjà accordées à l’outil.

Quatre agents placés face au même risque

La vulnérabilité touche des produits concurrents, mais construits autour d’un principe similaire : déléguer à un agent une partie du travail réalisé auparavant par un développeur.

Claude Code, l’outil d’Anthropic, peut lire des fichiers, lancer des commandes et intervenir directement dans un environnement de développement. Codex, proposé par OpenAI, poursuit une logique comparable en générant et en exécutant des actions liées au code. Gemini CLI, développé par Google, et GitHub Copilot, propriété de Microsoft, complètent cette liste.

La présence de ces quatre outils dans le périmètre de Plugin4Shell ne signifie pas nécessairement que leur implémentation est identique. Elle révèle plutôt un risque commun : les agents héritent d’une grande partie de la confiance accordée aux extensions et aux dépôts qu’ils consultent.

Air Security estime qu’une exploitation peut conduire à une remote code execution — une exécution de code à distance du point de vue de l’attaquant. Celui-ci pourrait alors accéder aux fichiers visibles par l’agent, aux clés d’API présentes dans son environnement ou à d’autres ressources accessibles avec ses droits.

L’impact dépendrait donc fortement de la configuration locale. Un agent isolé, sans secret et limité à un répertoire de test ne présente pas le même intérêt qu’un agent connecté à un dépôt privé, à un compte cloud ou à des systèmes internes. Mais dans de nombreuses entreprises, les assistants de développement disposent déjà de permissions suffisamment larges pour lire du code propriétaire, interroger des services et exécuter des commandes.

Le scénario d’attaque ne requiert pas un clic, mais il requiert un contexte

Le terme zero-click ne signifie pas qu’un attaquant peut compromettre n’importe quel poste à partir d’Internet, sans condition. Il faut que l’agent rencontre le composant malveillant et dispose d’un mécanisme pour le charger ou l’utiliser.

Le scénario devient particulièrement crédible dans trois situations : un dépôt public intégré au flux de travail, une extension récupérée depuis une source externe, ou un projet dont le propriétaire peut modifier le code référencé. Dans ces cas, le développeur peut simplement demander une analyse ou une correction. L’agent accomplit ensuite les étapes prévues, avec ses privilèges habituels.

C’est cette automatisation qui rend le risque sensible. Un humain repère parfois une commande inhabituelle ou une modification suspecte. Un agent, lui, peut l’interpréter comme une étape nécessaire à l’exécution d’une compétence. Si le contrôle des extensions repose surtout sur leur nom, leur provenance ou une version déclarée, la chaîne de confiance devient fragile.

La compromission d’une clé d’API constitue alors l’un des scénarios les plus directs. Une clé cloud, un jeton de registre de paquets ou des identifiants de contrôle de version peuvent permettre de poursuivre l’attaque hors de la machine initiale. Le périmètre réel dépend des secrets effectivement exposés à l’agent et des règles de segmentation appliquées par l’entreprise.

Des réponses éditeurs très inégales

Anthropic et OpenAI ont publié des correctifs pour leurs outils concernés. Ces mises à jour doivent être déployées rapidement, mais elles ne dispensent pas les équipes de revoir les plugins déjà autorisés ni les secrets accessibles aux agents.

La situation est plus préoccupante pour GitHub Copilot, qui resterait sans correctif au moment des informations disponibles. Les entreprises utilisant ses fonctions d’agent doivent considérer les extensions et dépôts externes comme une surface à risque jusqu’à la publication d’une mesure technique claire.

Du côté de Google, la stratégie annoncée serait différente : Gemini CLI doit être progressivement retiré, sans correctif prévu pour la vulnérabilité. Un retrait réduit l’exposition future, mais ne protège pas les installations existantes ni les environnements dans lesquels l’outil reste utilisé pendant la phase de transition. Il faudra également vérifier la révocation des jetons et des clés auxquels l’agent a pu accéder.

Cette réponse asymétrique souligne une difficulté plus large : les outils d’IA évoluent plus vite que les pratiques de gestion des dépendances. Une extension exécutée par un agent ne devrait pas être traitée comme un simple module facultatif. Elle peut disposer d’un accès comparable à celui d’un collaborateur technique — parfois sans les mêmes contrôles, ni la même traçabilité.

La priorité : réduire les permissions avant le prochain incident

Les entreprises peuvent limiter l’exposition en désactivant les plugins non indispensables, en imposant des miroirs internes et en vérifiant les sommes de contrôle ou les identifiants immuables des composants. Une version « épinglée » doit être associée à un contenu cryptographiquement vérifiable, pas uniquement à une étiquette lisible.

Les agents devraient aussi fonctionner avec des comptes dédiés, des jetons à durée courte et des permissions minimales. Les clés de production, les identifiants cloud à privilèges élevés et les secrets globaux ne devraient pas être disponibles dans leur environnement d’exécution. La journalisation des commandes, des téléchargements et des accès aux fichiers permettrait enfin de rechercher une activité suspecte.

Le prochain jalon attendu est la publication de correctifs et de détails techniques complets pour chaque produit, notamment chez Microsoft et Google. À court terme, la mesure la plus concrète reste de considérer tout plugin non vérifié comme du code tiers exécutable — et de mesurer précisément quels fichiers, clés et systèmes l’agent peut atteindre.