Votre agent de code a épinglé le commit. Il n'a jamais vérifié où il avait atterri

Un épinglage qui demandait sans vérifierHover to explore

Il existe un type de découverte de sécurité qui vaut plus que son score de sévérité, parce que le mécanisme vous apprend quelque chose d'applicable ailleurs. En voici une.

Les détails proviennent de la couverture de la divulgation d'AIR par The Register, Help Net Security et Cyber Security News. L'état des correctifs et les positions des éditeurs sont ceux rapportés au moment de la divulgation et ont pu évoluer ; la section 7 dit ce que je ne prétends pas. La lecture du mécanisme, et tout ce qui suit la section 4, est la mienne.

1. Ce qui a été divulgué

Le 17 septembre 2026, les chercheurs d'AIR ont publié Plugin4Shell : une faille d'exécution de code à distance sans le moindre clic dans les systèmes de plugins de quatre grands agents de code IA. Ils l'ont trouvée en mai 2026, ont construit des exploits de démonstration fonctionnels contre les quatre, et l'ont signalée aux éditeurs en juin.

État tel que rapporté à la publication :

C'est cette dernière partie qui parle. Quand quatre concurrents livrent le même bug, ce ne sont pas quatre inattentions. C'est une hypothèse partagée que personne n'a jamais écrite.

2. Le mécanisme : un épinglage qui demande sans vérifier

Les marketplaces de plugins épinglent un plugin à un hash de commit précis après relecture. C'est le contrôle auquel tout le monde se fie : épinglez un SHA et vous obtenez exactement les octets que quelqu'un a regardés. C'est le même réflexe que derrière un lockfile.

Voici ce que faisaient réellement les agents concernés :

1. Le marketplace épingle le plugin à un hash de commit relu de 40 caractères.

   Jusqu'ici tout va bien. Cette partie fonctionne.

2. L'agent demande à Git de faire un checkout de ce hash.

   Correct également, pris isolément.

3. Un attaquant qui contrôle le dépôt du plugin pousse une branche dont le nom est cette même chaîne de 40 caractères.

   Rien ne vous empêche d'appeler une branche a94a8fe5ccb19ba61c4c0873d391e987982fbbd3. Ce n'est qu'une chaîne de caractères.

4. Git résout le nom de la référence avant de traiter la chaîne comme un identifiant d'objet, donc le checkout atterrit sur la branche de l'attaquant — et l'agent considère le SHA épinglé comme satisfait.

   Parce qu'il n'a jamais regardé. Comme le formulent les chercheurs : l'agent fait un checkout du commit exact épinglé par le marketplace, mais ne vérifie jamais qu'il y a atterri.

La variante Gemini CLI est un autre chemin vers le même endroit — une branche nommée FETCH_HEAD qui détourne le checkout du commit récupéré — et c'est ce détail qui fait de tout cela une classe de bugs plutôt que le faux pas d'un éditeur.

3. La mise à jour automatique est ce qui l'a rendue sans clic

Une faille de chaîne d'approvisionnement demande normalement une action de l'utilisateur : installer, mettre à jour, approuver une invite. Plugin4Shell n'avait besoin de rien de tout cela, et la raison en est une fonctionnalité que tout le monde apprécie.

Claude Code et Codex exécutent par défaut des mises à jour automatiques en arrière-plan. Quand un marketplace change un SHA épinglé, l'agent relance le checkout selon son propre calendrier. Si l'attaquant a déjà préparé la branche malveillante, la substitution se produit en silence, sans invite, sans installation et sans personne devant l'écran.

Ce qui inverse le conseil habituel :

Pour des dépendances ordinaires, « activez les mises à jour automatiques » est un bon conseil de sécurité, car l'essentiel de ce qu'elles apportent sont des correctifs. Pour une surface d'exécution où le chemin de mise à jour est lui-même le composant vulnérable, la mise à jour automatique est le mécanisme de distribution. Les deux cas se ressemblent sur une page de politique et se comportent en sens inverse.

4. Le rayon d'impact, c'est votre développeur, pas un bac à sable

Il est tentant de lire « vulnérabilité de plugin » comme un problème confiné. Il ne l'est pas, et c'est cette partie qui devrait décider du sérieux avec lequel une petite équipe le prend.

Le code exécuté via le système de plugins d'un agent de code obtient, selon la formulation des chercheurs, la même portée sur les systèmes et les données de l'entreprise que le salarié qui exécute l'agent. Sur un poste de développement ordinaire, cela veut dire :

Un poste de développement est la machine la moins segmentée de la plupart des entreprises et celle qui a le plus de portée. C'est acceptable quand le code qui y tourne est un code choisi par un humain. C'est tout autre chose quand un chemin de mise à jour peut changer ce qui s'exécute sans que personne ait décidé de le changer.

5. L'arbre de dépendances que personne n'inventorie

Voici le point structurel, et la raison pour laquelle je pense que cela compte au-delà d'un cycle de correctifs.

Les dépendances de votre application sont gouvernées. Il y a un lockfile, un scanner, une étape de relecture quand quelqu'un ajoute un paquet, et un SBOM si vous vendez à quelqu'un qui le demande. Cette machinerie a pris vingt ans au secteur et fonctionne globalement.

Les plugins, skills, extensions et installations de marketplace de votre agent n'ont rien de tout cela.

Les dépendances applicatives tournent généralement dans un service doté d'une identité restreinte. Les plugins d'agent tournent sur un poste de travail avec toute l'autorité d'une personne. La couche la moins relue est celle qui a le plus de portée, ce qui est exactement à l'envers, et c'est arrivé par accident : les plugins sont apparus comme une fonctionnalité de productivité, pas comme une chaîne d'approvisionnement logicielle, donc personne ne leur a attaché la machinerie correspondante.

La plupart des équipes avec lesquelles je parle ne peuvent pas répondre à « quels plugins d'agents sont installés dans l'équipe, en quelles versions, de quels éditeurs » sans faire le tour des bureaux. Ce n'est pas de la négligence. Personne ne leur a jamais dit que c'était une question.

6. Quoi faire cette semaine

Quatre choses, une après-midi environ, et aucune n'exige une équipe de sécurité.

1. Mettez à jour les agents, puis vérifiez que les versions sont bien en place.

   Claude Code 2.1.179 et Codex 0.146.0 ou ultérieures. Pour tout ce qui est signalé non corrigé ou déprécié, la décision est de savoir s'il conserve une surface de plugins : un chemin de mise à jour non corrigé, cela ne se surveille pas, cela se coupe.

2. Faites l'inventaire.

   Chaque plugin, skill et extension d'agent installé dans l'équipe, avec éditeur et version. C'est en général une liste courte et l'exercice est plié en une heure. Si elle s'avère longue, c'est cela le constat.

3. Décidez la politique de mise à jour automatique délibérément, surface par surface.

   Mettez à jour automatiquement le binaire de l'agent : c'est ainsi que vous recevez des correctifs comme ceux-ci. Envisagez de faire passer les mises à jour de plugins par un humain, au moins pour ceux qui peuvent exécuter du code. Ce sont deux décisions distinctes et la plupart des équipes n'en prennent aujourd'hui qu'une seule, par défaut, pour les deux.

4. Réduisez ce qui reste authentifié sur le poste de travail.

   Identifiants cloud à durée de vie courte, aucun jeton de production durable dans les profils de shell, aucun tunnel de base de données ouvert toute la journée. C'est le contrôle qui tient quel que soit l'agent qui livrera le prochain bug, et c'est ce qui le rend prioritaire.

Et une chose à ajouter à votre propre code, quoi que vous construisiez :

Trouvez chaque endroit où vous récupérez par identifiant — un commit, un digest, une version de modèle, un identifiant de document — et vérifiez si quelque chose redérive cet identifiant à partir de ce qui est réellement arrivé. Si la réponse est « on l'a demandé, donc c'est forcément ça », vous avez la forme de Plugin4Shell dans votre propre système. Cela coûte quelques lignes à fermer et reste invisible jusqu'au jour où ça ne l'est plus.

7. Ce que je ne prétendrai pas

Aucune exploitation réelle confirmée n'a été rapportée. Il s'agit d'une divulgation avec des exploits de démonstration fonctionnels, pas d'un rapport d'incident. Les chiffres qui circulent sur le nombre d'agents qu'un plugin malveillant pourrait atteindre relèvent de la modélisation de scénarios, pas d'un décompte d'installations compromises, et je les ai délibérément laissés de côté.

L'état des correctifs bougeait pendant la divulgation et les sources divergent. Claude Code et Codex sont rapportés de façon constante comme corrigés aux versions ci-dessus. La couverture de l'exposition de Copilot n'est pas cohérente : certains récits le décrivent comme non corrigé, d'autres comme atténué par des contrôles de plateforme. Consultez l'avis de votre propre éditeur plutôt que ce tableau.

Ce n'est pas une vulnérabilité de Git. Que Git résolve une référence ambiguë dans un ordre documenté, c'est Git conforme à sa spécification. Le bug est dans les agents qui ont supposé que le résultat correspondait à la demande. Blâmer l'outil serait la mauvaise leçon et ne vous ferait rien corriger.

Je n'ai rien reproduit de tout cela. Toute la section 2 est ma lecture de descriptions publiées du mécanisme, pas une vérification indépendante.

Le résumé honnête

Ce qui est intéressant ici, ce n'est pas que quatre agents de code aient eu un bug. C'est quelle hypothèse ils partageaient tous : que nommer une chose avec précision équivaut à vérifier qu'on l'a reçue.

Cette hypothèse est partout. Elle est dans chaque intégration qui fait confiance à un webhook parce qu'il porte le bon identifiant, dans chaque cache qui répond par clé sans valider le contenu, dans chaque pipeline qui récupère latest et se dit reproductible. Épingler un hash paraissait sûr parce qu'un hash est précis — mais la précision n'est pas la vérification, et l'écart entre les deux est exactement là où vit cette classe de bugs.

Pendant ce temps, l'exposition pratique est peu spectaculaire et immédiate : un chemin de code capable de changer ce qui s'exécute sur la machine d'un développeur sans que personne approuve le changement, sur la machine la moins segmentée du bâtiment.

Mettez les agents à jour aujourd'hui. Puis passez une heure à découvrir quels plugins votre équipe a installés, car c'est en ce moment une question à laquelle la plupart des équipes ne savent pas répondre — et c'est exactement la question que posera la première revue de sécurité sérieuse d'un client.

Sources : The Register, « AI coding agents' 0-click RCE flaw could hand attackers keys to the kingdom », 17 septembre 2026 — la chronologie de la divulgation, les deux voies d'attaque et les positions des éditeurs. Help Net Security, « Zero-click RCE vulnerability hit four major AI coding agents », 18 septembre 2026 — la découverte en mai 2026, le signalement en juin, les versions corrigées 2.1.179 et 0.146.0, et la formulation des privilèges hérités par le code exécuté. Cyber Security News — le mécanisme de la branche de 40 caractères et la variante FETCH_HEAD affectant Gemini CLI. La recherche est celle d'AIR. La généralisation de la section 2, l'argument sur la mise à jour automatique de la section 3, l'argument d'inventaire de la section 5 et toutes les recommandations sont les miens. Pour l'incident de chaîne d'approvisionnement précédent sur ce sujet, voir l'inondation de paquets RubyGems, et pour le modèle de permissions qui limite la portée d'un plugin compromis, voir les systèmes de permissions d'agents.

Related Posts

Un registre délivrait des clés de publication avant de vérifier l'e-mail. Puis 2 000 paquets sont arrivés14 septembre 2026

Your AI Agent Has a Security Problem: A Founder's Security Guide for 2026July 17, 2026

AI Agents Need Permission Systems, Not Better Prompts — A Founder’s GuideJuly 14, 2026