8 failles, 7 agents CLI, 4 encore ouvertes le 1er septembre — pourquoi j’ai arrêté d’ouvrir les dépôts qu’on m’envoie
Panos Petropoulos
Expert développement web · 3 septembre 2026 · 14 min de lecture
TL;DR — l’essentiel en 30 secondes
- • Manifold Security divulgue 8 failles sur 7 agents CLI : Claude Code, Codex, Cursor, goose, Hermes Agent, Qwen Code, Grok Build.
- • Ce n’est pas de l’injection de prompt. La configuration Git du dépôt désigne une commande que l’agent exécute sous votre identité, hors bac à sable, sans confirmation.
- • Condition : le dépôt doit arriver en fichiers avec son dossier
.gitintact — archive, lecteur partagé, dossier synchronisé, clé USB. Ungit clonenormal ne le fait pas. - • Le moment est le pire : avant le prompt de confiance (Claude Code, Hermes), avant l’authentification (Qwen Code), à la première frappe (Grok Build).
- • Au retest du 1er septembre : corrigés pour goose, Cursor et Claude Code ; toujours ouverts pour Hermes Agent, Qwen Code, Grok Build et un second chemin Claude Code.
- • La parade durable : supprimer
.gitde tout dépôt non cloné soi-même, et exécuter les agents dans un conteneur jetable.
Ce n’est pas une injection de prompt. Le modèle n’est même pas impliqué. Une configuration Git piégée, transportée par une archive ou un dossier partagé, suffit à faire exécuter du code attaquant sur votre poste — sous votre identité, hors du bac à sable, avant même le prompt de confiance. Au 1er septembre, quatre failles sur huit restaient ouvertes.
Ce qui a été publié, et pourquoi ce n’est pas « encore une histoire de prompt injection »
La société de sécurité Manifold Security a divulgué huit failles réparties sur sept agents de codage en ligne de commande. La liste est longue et connue de tous : Claude Code, Codex, Cursor, goose, Hermes Agent, Qwen Code et Grok Build. Le titre retenu par la presse spécialisée résume bien le mécanisme : « Malicious .git Configs Can Make Claude, Codex, Cursor, and Other AI Agents Run Attacker Code ».
Il faut insister sur un point, parce que la confusion est immédiate : ce n’est pas de l’injection de prompt. Il n’y a pas de texte piégé qui convainc un modèle de faire quelque chose. Le modèle n’est même pas impliqué dans la partie dangereuse.
Le mécanisme est bien plus bête, et c’est ce qui le rend intéressant. La configuration Git du dépôt lui-même désigne une commande. L’agent, en s’initialisant dans le répertoire, lit cette configuration et exécute la commande sur votre machine, sous votre identité — en dehors de son bac à sable et sans aucune demande de confirmation.
Autrement dit : le bac à sable dans lequel vous avez placé votre confiance ne couvre pas le chemin par lequel l’attaque passe. C’est une faille d’architecture, pas de modèle.
Notre avis d’expert (1 sur 3)
Ce qui nous a fait relire deux fois, c’est la nature du vecteur. Nous avons passé dix-huit mois à parler d’injection de prompt, à écrire des filtres, à débattre de la robustesse des instructions système — et la faille qui fonctionne réellement contourne complètement le modèle. Elle exploite une fonctionnalité Git légitime, documentée, vieille de vingt ans, que les agents lisent parce qu’ils sont des outils Git. Il y a une leçon inconfortable : quand on ajoute une couche d’intelligence au-dessus d’un outil existant, on hérite de toute sa surface d’attaque, y compris des parties qu’on n’a pas lues. Le modèle n’est pas le périmètre de sécurité. Le processus qui l’héberge l’est.
La condition d’exploitation, et pourquoi elle est plus fréquente qu’il n’y paraît
L’attaque a un prérequis précis : le dépôt doit arriver sous forme de fichiers, avec son dossier .git intact. Un git clone ordinaire ne reproduit pas la configuration piégée — c’est la bonne nouvelle, et c’est ce qui a permis à beaucoup d’équipes de conclure trop vite qu’elles n’étaient pas concernées.
Sauf que la liste des situations où un dépôt arrive en copie de fichiers est longue et parfaitement banale : une archive transmise par un client ou un candidat, un lecteur partagé, un dossier synchronisé type Drive ou Dropbox, une clé USB, une restauration de sauvegarde, un transfert entre deux machines.
Dans l’open source, il y a un cas encore plus courant : les archives de release et les copies de dépôts récupérées hors du protocole Git pour contourner un pare-feu d’entreprise. Et pour toute équipe qui fait passer des tests techniques, recevoir une archive de code d’un candidat est une opération hebdomadaire.
Le scénario réaliste n’est donc pas exotique. Un candidat envoie un projet, un développeur l’extrait, ouvre son agent dans le dossier, et le code s’exécute — avec ses clés SSH, ses jetons et son accès au réseau interne.
Le détail qui rend les correctifs urgents : le moment où le code part
Manifold a publié quelque chose de plus dérangeant que la faille elle-même : l’instant précis de l’exécution.
Sur Claude Code et Hermes Agent, la charge s’exécute avant que le prompt de confiance de l’espace de travail ne soit accepté. Sur Qwen Code, avant même que l’utilisateur ne se soit authentifié. Sur Grok Build, dès la première frappe clavier.
Aucun de ces moments ne laisse à l’utilisateur l’occasion de refuser. Le garde-fou existe, il est simplement placé après la porte. C’est exactement le type de défaut qu’un audit de code ne trouve pas, parce que chaque composant se comporte comme prévu — c’est leur ordonnancement qui est faux.
Vos agents tournent-ils sur des dépôts que vous n’avez pas clonés vous-même ?
Nous auditons les chaînes d’outillage IA de vos équipes : ce qui s’exécute, sous quelle identité, et à quel moment. Un jour d’intervention, un rapport actionnable.
Discutons-enCe qui est corrigé au 1er septembre, et ce qui ne l’est pas
Au moment où Manifold a refait ses tests, le 1er septembre 2026, la situation était partagée. Des correctifs ont été livrés pour goose, Claude Code et Cursor.
En revanche, Hermes Agent, Qwen Code, Grok Build — et un second chemin dans Claude Code — exécutaient toujours les commandes fournies par le dépôt. Quatre des huit failles restaient donc ouvertes.
Ce « second chemin dans Claude Code » mérite qu’on s’y arrête, parce qu’il illustre un schéma classique : le correctif a fermé la voie décrite dans le rapport initial, pas la classe de problème. C’est la différence entre corriger un bug et corriger une catégorie, et c’est généralement ce qui explique les rounds successifs de divulgation sur un même produit.
Notre avis d’expert (2 sur 3)
Un correctif publié n’est pas un correctif installé, et c’est le point aveugle de la plupart des équipes. Les agents CLI sont installés par les développeurs eux-mêmes, souvent via un gestionnaire de paquets personnel, hors de tout inventaire logiciel. Aucun service informatique que nous connaissons n’a de vision fiable sur les versions réellement présentes sur les postes. Nous recommandons de traiter ces outils comme n’importe quel logiciel de production : inventaire, version minimale imposée, et vérification. La question à poser n’est pas « avons-nous mis à jour ? » mais « quelle version tourne sur les vingt postes de l’équipe, ce matin ? ». Presque personne ne sait y répondre.
Ce que nous recommandons de faire cette semaine
1. Inventoriez les agents CLI réellement installés. Pas ceux que la politique autorise — ceux qui sont là. Une simple commande de recensement sur les postes suffit à révéler l’écart.
2. Imposez une version minimale pour goose, Cursor et Claude Code, et vérifiez-la plutôt que de la demander.
3. Traitez Hermes Agent, Qwen Code et Grok Build comme non corrigés jusqu’à confirmation par leurs éditeurs. Si un projet en dépend, isolez-le.
4. Interdisez d’ouvrir un agent dans un dépôt reçu en fichiers. La règle pratique : si vous ne l’avez pas cloné vous-même depuis une origine que vous connaissez, vous supprimez le dossier .git avant d’ouvrir l’agent. C’est une commande, elle coûte deux secondes, et elle neutralise le vecteur.
5. Faites tourner les agents dans un conteneur jetable pour tout code externe. C’est la seule mesure qui reste valable quand la prochaine faille de ce type sortira — et il y en aura une.
Notre avis d’expert (3 sur 3)
La leçon durable de cette divulgation n’est pas « mettez à jour ». C’est que le modèle de confiance des agents de codage est encore immature. Ces outils lisent des fichiers de configuration, exécutent des commandes, héritent de nos identités et de nos secrets, et nous les avons adoptés en masse en un an sans leur appliquer le dixième des exigences que nous imposons à une dépendance npm. Notre position, en tant que praticiens open source, est simple : un agent de codage doit être traité comme du code non fiable qui tourne avec vos droits. Tant que ce n’est pas le cas dans les process, chaque nouvelle faille de ce type coûtera la même panique.
Ce que cela dit à l’écosystème open source
Il y a un angle spécifiquement open source dans cette affaire. Les projets libres sont ceux qui distribuent le plus volontiers du code sous forme d’archives, ceux dont les contributeurs échangent des dépôts par des canaux variés, et ceux où la culture de l’essai rapide encourage à ouvrir n’importe quel dossier avec son outillage habituel.
Trois des sept agents concernés sont eux-mêmes open source, ce qui est une force : la divulgation a été vérifiable, le correctif public et auditable. C’est très exactement l’argument que nous défendons pour les outils métier construits sur des briques ouvertes. Mais l’ouverture ne remplace pas un modèle de menace, et c’est là que le bât blesse.
Pour les mainteneurs, une action concrète : documentez explicitement que vos archives de release ne contiennent pas de dossier .git, et vérifiez-le dans votre chaîne de publication. Cela paraît trivial, c’est ce qui distingue un projet dont on peut recommander l’usage d’un projet dont on doit se méfier. Les enjeux de gestion des secrets et de compromission de poste qui en découlent rejoignent directement les pratiques décrites par nos confrères en audit de sécurité, et la question du coût d’exploitation de ces agents est traitée côté intégration IA en entreprise.
Questions fréquentes
Est-ce une attaque par injection de prompt ?
Non, et la distinction est importante parce qu’elle change complètement les contre-mesures. Il n’y a aucun texte piégé destiné à convaincre le modèle de faire quelque chose ; le modèle n’intervient même pas dans la partie dangereuse. Le mécanisme repose sur la configuration Git du dépôt lui-même, qui désigne une commande. L’agent, en s’initialisant dans le répertoire, lit cette configuration et exécute la commande sur la machine du développeur, sous son identité, en dehors du bac à sable et sans demande de confirmation. C’est une faille d’architecture qui exploite une fonctionnalité Git légitime et documentée depuis vingt ans, et non une faiblesse du modèle de langage. Les filtres d’injection de prompt n’offrent donc aucune protection contre ce vecteur.
Suis-je vulnérable si je clone toujours mes dépôts normalement ?
Un git clone ordinaire ne reproduit pas la configuration piégée, donc ce chemin précis est sûr. Mais la condition d’exploitation est plus fréquente qu’elle n’en a l’air : il suffit que le dépôt arrive sous forme de fichiers avec son dossier .git intact. Cela couvre les archives transmises par un client ou un candidat, les lecteurs partagés, les dossiers synchronisés type Drive ou Dropbox, les clés USB, les restaurations de sauvegarde et les transferts entre machines. Dans l’open source s’ajoutent les archives de release et les copies récupérées hors protocole Git pour contourner un pare-feu d’entreprise. Toute équipe qui reçoit des tests techniques de candidats effectue cette opération chaque semaine.
Quels agents sont corrigés au 1er septembre 2026 ?
Lors du retest effectué par Manifold Security le 1er septembre 2026, des correctifs avaient été livrés pour goose, Claude Code et Cursor. En revanche, Hermes Agent, Qwen Code et Grok Build, ainsi qu’un second chemin d’exécution dans Claude Code, exécutaient toujours les commandes fournies par le dépôt : quatre des huit failles restaient ouvertes. Ce second chemin dans Claude Code illustre un schéma classique, où le correctif ferme la voie décrite dans le rapport initial sans traiter la classe de problème sous-jacente. Attention également au décalage entre correctif publié et correctif installé : ces agents sont souvent installés par les développeurs eux-mêmes, hors de tout inventaire logiciel.
Quelle mesure protège durablement, au-delà des mises à jour ?
Deux mesures résistent à la prochaine faille du même type, et il y en aura une. La première est une règle d’usage simple : si vous n’avez pas cloné le dépôt vous-même depuis une origine que vous connaissez, supprimez le dossier .git avant d’ouvrir votre agent dedans. C’est une seule commande, elle prend deux secondes et elle neutralise entièrement le vecteur. La seconde est structurelle : faire tourner les agents dans un conteneur jetable pour tout code externe, sans accès aux clés SSH ni aux jetons du poste. Le principe directeur est de traiter un agent de codage comme du code non fiable qui s’exécute avec vos droits, ce qui est exactement ce qu’il est.
Votre chaîne d’outillage IA est-elle sous contrôle ?
Nous inventorions les agents réellement installés, leurs versions, ce qu’ils exécutent et sous quelle identité — puis nous vous remettons les règles à appliquer.
Discutons-en — audit outillage