Plugin4Shell : le piège des plugins pour les agents IA

Pourquoi les plugins d’agents IA méritent une attention particulière

Un plugin d’agent de programmation ne se limite pas nécessairement à ajouter un raccourci ou quelques instructions.

Dans Claude Code, les plugins peuvent notamment regrouper des compétences spécialisées, des sous-agents, des intégrations MCP et des hooks. Ces derniers permettent de déclencher des commandes en réaction à certains événements, par exemple après la modification d’un fichier.

Cette souplesse est utile : une équipe peut distribuer ses conventions de développement, ses outils de vérification ou ses automatisations dans un ensemble réutilisable.

Ces deux questions sont complémentaires. L’examen initial répond surtout à la première ; les mécanismes de distribution et de contrôle doivent prendre en charge la seconde.

À quoi sert l’épinglage d’un commit Git ?

Pour comprendre le problème, il faut distinguer une branche Git d’un commit précis.

Une branche désigne une ligne de développement et peut avancer vers de nouveaux commits. Un identifiant de commit permet, lui, de sélectionner une révision déterminée. La commande git checkout accepte différentes formes de références, dont des noms de branches et des identifiants de commits.

L’épinglage, ou pinning, consiste à demander une révision précise plutôt qu’à suivre une référence susceptible d’évoluer.

La documentation des marketplaces de Claude Code prévoit ainsi un champ sha contenant l’identifiant complet du commit à utiliser. Il sert à verrouiller un plugin sur une version exacte, indépendamment de la branche ou du tag éventuellement renseigné.

L’objectif est simple : après avoir examiné une version, une équipe veut que les installations suivantes utilisent cette même version.

Le défaut : demander le bon commit, mais obtenir une autre révision

Le correctif de Codex décrit un cas précis : lorsque la branche par défaut d’un dépôt porte le même nom que le SHA demandé, Git peut interpréter cette valeur comme un nom de branche.

Le client croit sélectionner le commit approuvé, alors que l’opération peut aboutir à une autre révision. Sans contrôle après le checkout, l’installation peut être considérée comme réussie malgré cette différence.

Il ne s’agit donc pas d’un cassage du mécanisme cryptographique de Git. Le défaut se situe dans la manière de sélectionner puis de vérifier le résultat attendu.

AIR décrit aussi une variante concernant Gemini CLI et impliquant FETCH_HEAD. Le rapport précise que GitHub bloque les branches nommées comme un SHA complet, ce qui limite la première variante sans régler tous les scénarios.

Cette distinction évite une généralisation trompeuse : tous les dépôts, tous les hébergeurs et toutes les configurations ne présentent pas exactement la même exposition.

Pourquoi parle-t-on d’une attaque « zero-click » ?

Selon AIR, le scénario sans nouvelle interaction vise notamment les mises à jour automatiques de plugins déjà installés dans Claude Code et Codex. Une évolution du commit approuvé dans le catalogue peut déclencher la récupération du code piégé.

Le terme zero-click doit donc être compris dans ce contexte : une relation de confiance existe déjà avec le plugin, puis une opération automatique intervient.

Il ne signifie pas que n’importe quel ordinateur peut être compromis sans condition. La présence d’un composant concerné, sa provenance et son mécanisme d’actualisation font partie de l’analyse du risque.

La question opérationnelle devient alors : quelles actions peuvent se produire après l’approbation initiale, sans qu’une personne examine à nouveau le code ?

Quels correctifs sont disponibles ?

Il faut distinguer les correctifs vérifiables publiquement des informations communiquées par les chercheurs lors de leur annonce.

Les deux dernières lignes décrivent l’état communiqué par AIR lors de la publication, et non une confirmation indépendante de leur statut au 21 septembre 2026.

Pour Codex, la vérification est directement consultable : les notes de version référencent la modification « Verify Git plugin SHA checkouts ». Il ne s’agit donc pas uniquement d’une affirmation du rapport de recherche.

Ces numéros désignent des versions correctives de référence, pas nécessairement les versions les plus récentes à déployer.

Comment le contrôle doit-il fonctionner ?

Le correctif public de Codex ajoute une vérification après l’extraction : résoudre le commit désigné par HEAD, puis refuser la source si cet identifiant ne correspond pas exactement au SHA demandé. Un test de non-régression couvre également la confusion avec une branche portant le nom d’un commit.

La commande suivante permet de résoudre le commit courant dans un dépôt Git :

git rev-parse --verify 'HEAD^{commit}'

Elle demande à Git de vérifier que HEAD peut être résolu vers un objet commit et d’en afficher l’identifiant.

Cette commande n’est toutefois pas un audit de sécurité complet. Elle ne certifie ni l’innocuité du commit ni, à elle seule, l’absence de modifications dans les fichiers de travail. La documentation Git distingue le commit sélectionné et les modifications locales qui peuvent subsister dans le répertoire de travail.

Le risque dépend aussi des permissions de l’environnement

Une fois du code non fiable chargé, l’impact potentiel dépend de ce qu’il peut atteindre.

Dans ses recommandations pour GitHub Actions, GitHub souligne qu’un composant tiers compromis peut accéder aux secrets disponibles dans son environnement et, selon les droits accordés, utiliser les jetons associés au workflow. C’est une illustration concrète du risque posé par du code externe exécuté dans un environnement privilégié.

Appliqué à un poste de développement, ce raisonnement conduit à examiner les fichiers, identifiants et services accessibles au processus concerné. Un environnement dédié disposant de droits limités n’offre pas les mêmes possibilités qu’une session ayant accès aux outils et secrets de production.

Il serait cependant excessif d’assimiler toute exécution de code à un accès administrateur automatique.

OpenAI distingue notamment les restrictions de sandbox, les demandes d’autorisation et les accès réseau dans le fonctionnement de Codex. Ces protections doivent être évaluées séparément : la vérification d’un plugin et la limitation des actions qu’il peut effectuer ne remplissent pas le même rôle.

Les mesures à prendre dans une équipe de développement

Mettre à jour tous les environnements concernés

Une équipe doit identifier les installations réellement utilisées : postes individuels, environnements partagés et images de développement. L’objectif est d’éviter qu’un outil corrigé sur un poste reste ancien ailleurs.

Associer restriction des catalogues et vérification du contenu

Claude Code propose notamment des paramètres administrés pour restreindre les marketplaces autorisées. Sa documentation précise toutefois qu’une restriction du catalogue n’équivaut pas à une vérification de chaque entrée qu’il contient.

Choisir une source autorisée et vérifier son contenu sont deux contrôles complémentaires.

Rechercher ce qui peut s’exécuter sans nouvelle décision

Les hooks de Claude Code peuvent, par exemple, exécuter une commande après certains événements. Une revue doit donc porter sur ces automatismes, pas uniquement sur les instructions visibles destinées au modèle.

Une question simple peut guider cette vérification : qu’est-ce que ce plugin peut faire sans nouvelle décision de l’utilisateur ?

Appliquer le principe du moindre privilège

GitHub recommande notamment des droits minimaux pour les secrets et le GITHUB_TOKEN, ainsi que l’examen du code des composants tiers utilisés dans les workflows. Cette logique constitue un point de départ utile pour les automatisations de développement.

Ne pas considérer un conteneur comme une garantie absolue

OpenAI précise que les devcontainers apportent une protection sans empêcher toutes les attaques : les données et identifiants accessibles à l’intérieur peuvent toujours être exposés par un projet malveillant dans certaines configurations.

L’enjeu n’est donc pas seulement de placer l’agent « dans une boîte », mais de vérifier ce que cette boîte contient et les accès qu’elle conserve vers l’extérieur.

Conclusion : la confiance doit être vérifiée jusqu’au code exécuté

La bonne question n’est pas uniquement : « Avons-nous approuvé ce plugin ? »

Elle doit aussi être : « Comment vérifions-nous que l’installation correspond à ce que nous avons approuvé ? »

Le correctif de Codex apporte une réponse concrète à cette question en contrôlant la révision obtenue, plutôt qu’en se fiant uniquement à celle demandée.

Pour les développeurs web, la leçon est applicable à toute chaîne d’outillage : une revue initiale, une référence précise et une source connue sont utiles, mais ces garanties doivent rester cohérentes jusqu’à l’exécution.

La confiance accordée à un plugin ne devrait jamais remplacer la vérification du code effectivement installé.