Le fait qu'une extension porte la référence d'une version approuvée ne garantit pas que cette version soit celle qui a été installée. C'est le constat technique de l'enquête publiée le 17 septembre 2026 par Air Security sous le nom Plugin4Shell. Les chercheurs ont relevé un défaut de vérification dans les procédures d'installation d'extensions de Claude Code, Codex, GitHub Copilot et Gemini CLI. Dans certaines configurations, une personne ayant pris le contrôle du dépôt Git de l'extension peut faire installer un autre contenu sans modifier la référence affichée par le catalogue.
La portée de la faille doit être précisée. L'attaque suppose le contrôle du dépôt concerné, un hébergeur autorisant certaines références Git et un logiciel client exposé au défaut. Les documents examinés ne permettent pas d'établir qu'une campagne d'exploitation réelle aurait compromis l'ensemble de ces utilisateurs. Aipolix n'a pas reproduit l'attaque dans un laboratoire. En revanche, le mécanisme décrit, les correctifs publiés et les divergences entre les communications des acteurs permettent de formuler des contrôles précis pour les équipes d'ingénierie.
Une référence exacte peut masquer des fichiers différents
Lorsqu'un catalogue examine une extension, il peut enregistrer l'identifiant d'une révision précise de son dépôt, le hash d'un commit. L'objectif est de retrouver les mêmes fichiers au moment de l'installation, même si le projet évolue par la suite. Le programme télécharge le dépôt et demande à Git de sélectionner cet identifiant. D'après Air, les installations vulnérables considéraient que la réussite de cette commande suffisait. Elles ne comparaient pas l'identité réelle de la révision sélectionnée à celle qui avait été approuvée.
Pour Claude Code, Codex et Copilot, les chercheurs décrivent une ambiguïté entre un identifiant de commit de 40 caractères et le nom d'une branche. Si le responsable malveillant contrôle le dépôt, si l'hébergeur accepte un nom de branche ressemblant à ce hash et si cette branche devient la branche par défaut, Git peut choisir la branche au lieu du commit visé. Les fichiers obtenus ne correspondent alors plus à la version examinée. Ce scénario ne donne pas à un attaquant quelconque la capacité de modifier toutes les extensions : la maîtrise du dépôt et les conditions d'hébergement sont indispensables.
GitHub a indiqué qu'il refusait les noms de branches ou d'étiquettes pouvant être confondus avec des hashes de commits. Cette mesure empêche la variante reposant sur le nom d'une branche pour les dépôts hébergés sur GitHub. Elle ne protège pas automatiquement des extensions provenant de Bitbucket ou de serveurs Git privés dont les règles diffèrent. Un catalogue fiable peut renvoyer vers plusieurs hébergeurs ; il faut examiner l'adresse du dépôt réel plutôt que la seule plateforme qui présente l'extension.
La situation est différente avec Gemini CLI. Air explique que le programme récupère le commit attendu puis utilise la référence FETCH_HEAD pour sélectionner le contenu final. Une branche portant ce nom peut créer une autre ambiguïté. Bloquer les noms qui ressemblent à des hashes ne suffit donc pas pour toutes les variantes. Dans les deux cas, la vérification décisive consiste à lire l'identifiant de la révision effectivement installée et à l'opposer à l'identifiant enregistré par le catalogue.
Pourquoi l'installation peut se produire sans nouvelle action humaine
Les chercheurs décrivent une extension initialement saine, acceptée par le catalogue, puis une mise à jour ordinaire dont le code soumis à l'examen reste inoffensif. Après l'enregistrement de la nouvelle révision, le dépôt contrôlé par l'attaquant est modifié pour que le client sélectionne d'autres fichiers. Si les mises à jour des extensions s'exécutent automatiquement, une extension déjà présente peut être remplacée sans nouvelle validation de l'utilisateur. Air indique que cette automatisation est activée par défaut dans Claude Code et Codex, ce qui ne dispense pas de vérifier chaque configuration réelle.
Les conséquences potentielles dépassent celles d'une réponse erronée produite par un modèle. Le code d'une extension peut disposer des accès accordés au processus qui exécute l'agent : fichiers du projet, identifiants ou services internes. Air qualifie ainsi le scénario d'exécution de code à distance. Cette qualification décrit une possibilité technique en cas de réussite de l'attaque, et non la preuve qu'un nombre déterminé de machines auraient déjà été compromises.
Une équipe de sécurité doit distinguer les responsabilités. Le catalogue peut attester la version qu'il a examinée. L'hébergeur Git peut bloquer certains noms dangereux. Mais c'est au client d'installation de vérifier que les fichiers téléchargés correspondent réellement à la révision approuvée. Enfin, les droits du processus déterminent ce que le code pourrait atteindre si cette vérification échouait. Une attestation portant sur une seule de ces étapes ne vaut pas validation de l'ensemble.
Que sait-on réellement des corrections ?
Air affirme qu'Anthropic a corrigé cette faille dans Claude Code 2.1.179 et lui en a donné confirmation en juin. Les notes publiques de cette version ne mentionnent pas explicitement Plugin4Shell : l'attribution de la correction repose donc sur le compte rendu des découvreurs. Pour Codex, OpenAI fournit une preuve plus directe. Une modification intégrée au dépôt officiel impose la comparaison entre le commit réellement sélectionné, identifié par HEAD, et le hash demandé. Le programme refuse le chargement si ces valeurs divergent. Cette modification figure dans le journal de la version 0.146.0.
Le 17 septembre, Air signalait qu'aucun correctif client n'avait été livré pour Copilot. Les publications officielles de Copilot CLI consultées ici ne permettent pas de confirmer un correctif ultérieur propre à Plugin4Shell. Il serait toutefois excessif d'en déduire que toutes les mesures internes de Microsoft sont connues. GitHub a mis en avant auprès de The Register sa protection contre les noms de branches trompeurs sur sa propre plateforme ; les chercheurs ont rappelé que les extensions peuvent également dépendre de dépôts hébergés ailleurs.
Pour Gemini CLI, Air rapporte que Google lui a annoncé qu'aucune correction de cette faille n'était prévue et lui a indiqué Antigravity comme solution de remplacement, lequel ne présente pas ce même mécanisme vulnérable. Une autre source officielle invite néanmoins à nuancer toute déclaration sur l'arrêt du produit : le dépôt Gemini CLI annonce une version stable 0.60.0 datée du 15 septembre avec d'autres améliorations de sécurité. Cela ne prouve ni que tout développement s'est arrêté ni que ces modifications ont corrigé Plugin4Shell. Les utilisateurs ont besoin d'une confirmation explicite concernant précisément ce défaut.
Les vérifications à mener avant de relancer une extension
Il convient d'établir l'inventaire des versions exactes des agents, des extensions installées, de leurs dépôts et de leurs hébergeurs. Pour chaque extension pertinente, comparer l'identifiant approuvé avec le commit effectivement présent dans le répertoire installé, au moyen d'une procédure d'inspection fiable. Une simple notification de réussite ne suffit pas. Si les valeurs divergent, conserver les éléments utiles à l'enquête avant toute nouvelle exécution. Contrôler également les mises à jour automatiques, les fichiers accessibles aux agents, les identifiants disponibles et leurs autorisations réseau.
Installer les versions corrigées est nécessaire lorsqu'elles existent. À défaut de correction confirmée, limiter les sources d'extensions non fiables et les mises à jour automatiques réduit certaines possibilités d'attaque, sans réparer le client. Une mise à niveau ne prouve pas non plus qu'une extension malveillante exécutée auparavant a été supprimée ou que des secrets éventuellement accessibles sont restés intacts. Les sources consultées n'établissent pas l'existence d'un nettoyage automatique. Une exécution suspecte exige donc une analyse tenant compte des privilèges réellement accordés.
Plugin4Shell met en évidence une distinction essentielle : identifier le code approuvé, vérifier le code effectivement installé et limiter ses capacités sont trois contrôles distincts. Les confondre peut donner une assurance trompeuse, même lorsque chaque extension possède une référence de version parfaitement valide.