Votre agent de code lance git avant que vous tapiez — et le dépôt choisit la commande

De quoi s’agit-il ?

Le 1er septembre 2026, Manifold Security a publié GitSpawn : huit découvertes réparties sur sept agents de code en ligne de commande, où un dépôt que l’on vous a transmis peut désigner une commande que l’agent exécute sur votre machine. Quatre n’étaient toujours pas corrigées à la publication, reconfirmées sur les versions courantes. The Hacker News a repris l’affaire le lendemain et relève qu’OpenAI a publié le même jour trois avis pour la même classe de faille dans Codex, crédités à trois équipes de recherche indépendantes.

Les produits concernés ne sont pas confidentiels. Claude Code, OpenAI Codex, Cursor CLI, goose, Qwen Code, Grok Build et Hermes Agent — près d’un demi-million d’étoiles GitHub cumulées pour les projets open source, et plus de 77 millions de téléchargements npm mensuels pour Claude Code seul, selon le chiffre de l’API npm cité par Manifold.

Le point remarquable : rien ici ne concerne le modèle. Pas de prompt, pas d’injection, pas de jailbreak. C’est le sous-processus que l’agent lance avant d’avoir dit quoi que ce soit.

Comment ça fonctionne

Tout agent de code CLI collecte du contexte lorsqu’il ouvre un dossier : quelle branche, quels fichiers modifiés, quels chemins suivis. Tous s’appuient sur git pour cela — sur certains agents dès le démarrage, avant l’invite de confiance de l’espace de travail, sur l’un d’eux avant même que l’utilisateur se soit authentifié.

Le problème tient à ce dont héritent ces appels.

L'agent démarre dans ./projet-recu
   │
   ├─ lance :   git status --porcelain=2 --branch
   │            (ou git diff --name-only HEAD — le choix importe peu)
   │
   ├─ git rafraîchit l'index avant de répondre
   │
   ├─ ce rafraîchissement consulte core.fsmonitor
   │            …que git lit dans ./projet-recu/.git/config
   │
   └─ cette valeur est un PROGRAMME. Git l'exécute.
              → s'exécute sous l'identité de l'utilisateur
              → hors du sandbox de l'agent
              → aucune demande d'approbation, rien à l'écran

core.fsmonitor est un réglage de performance légitime pour les gros dépôts : plutôt que d’interroger chaque fichier, git demande à un programme auxiliaire ce qui a changé. Comportement documenté, voulu, et lu depuis le fichier de configuration propre au dépôt. Comme l’écrivait Cobalt dans un billet red team en décembre dernier, il s’agit d’un détournement de fonctionnalité, pas d’un bug — la souplesse de git rencontrant l’automatisation d’un IDE moderne. Manifold a également confirmé un second chemin dans Claude Code, atteint via une commande de revue, qui repose sur une autre clé de configuration du même type ; les chercheurs ont délibérément tu cette clé tant que la faille reste ouverte.

Le mode de livraison est la contrainte qui rend la chose gérable. Cloner une URL hostile ne fait rien. git clone, fetch et pull ne transportent pas la configuration locale d’un dépôt. Le dépôt doit arriver sous forme de fichiers, son répertoire .git déjà présent — une archive .zip partagée, un dossier synchronisé, un lecteur réseau, une clé USB. C’est-à-dire exactement la façon dont les collègues se passent des projets et dont les consultants remettent leur travail à un client.

Exemple de prompt

Un prompt défensif à donner à votre agent avant de le laisser ouvrir un dossier arrivé sous forme de fichiers. Il inspecte la config au lieu de lui faire confiance, et la valeur hostile est caviardée — ce qui compte, c’est la forme du réglage, pas une charge fonctionnelle.

# Defensive check — before opening a repo you RECEIVED as files
Read ./received-project/.git/config. Do not open the folder with an agent yet.
List every key whose value is a program:
  core.fsmonitor, core.hooksPath, filter.*.clean, filter.*.process, attr.tree
For each, report the key, its value, and whether that path is executable.
Never run a value you find. A hostile entry looks like:
  [core]
      fsmonitor = [REDACTED payload path]
Then re-check with a config-stripped call:
  git -c core.fsmonitor=false status --porcelain

Notez ce qu’il ne fait pas : il n’exécute jamais la valeur trouvée, et l’appel final neutralise la config du dépôt au lieu de la lire. C’est exactement l’invariant qu’on demande aux éditeurs d’adopter dans le harness lui-même.

Pourquoi c’est important

Le périmètre d’impact est le compte du développeur, pas la session de l’agent. Le code de l’attaquant s’exécute avec les privilèges de l’utilisateur : clés SSH, identifiants cloud présents dans l’environnement, jetons dans la configuration du shell, tous les dépôts sur le disque. Le modèle de permissions de l’agent ne voit jamais l’appel, puisque c’est le code de l’agent lui-même qui l’a émis.

Trois points structurels méritent d’être retenus.

Le sandbox n’a jamais été sur le chemin. Un travail d’ingénierie considérable a porté sur les invites d’approbation et les sandbox d’outils pour ce que le modèle décide de faire. Ici, tout se joue avant même que le modèle soit contacté. Un contrôle qui ne couvre que les actions initiées par le modèle laisse les sous-processus du harnais sans protection.

Les invites de confiance arrivent trop tard. Sur Claude Code et Hermes Agent, la charge s’exécute avant l’acceptation de l’invite de confiance ; sur Qwen Code, avant l’authentification ; sur Grok Build, dès la première frappe. Une boîte de dialogue de confiance qui s’affiche après la collecte de contexte est décorative.

C’est une classe connue, redécouverte. Sonar avait signalé le même point d’entrée en avril 2026, et identifié le même contournement de dialogue de confiance dans Visual Studio Code et les IDE JetBrains des années plus tôt. Anthropic avait déplacé la séquence de démarrage en 2.0.34 (novembre 2025) pour fermer la brèche ; Manifold constate le même comportement de démarrage à nouveau présent en 2.1.193 (juin 2026). La régression est le résultat attendu lorsque le correctif consiste en un changement d’ordonnancement plutôt qu’en un invariant.

Cinq des huit signalements de Manifold sont revenus marqués comme doublons de découvertes déposées indépendamment par d’autres chercheurs, dont une le même jour. Plusieurs équipes convergent simultanément sur cette surface.

Défenses

Si vous recevez un dépôt sous forme de fichiers — tout ce qui n’est pas arrivé par git clone :

• Inspectez .git/config avant d’ouvrir le répertoire avec un agent. Cherchez core.fsmonitor, core.hooksPath et attr.tree accompagné d’un filtre clean ou process — tout réglage dont la valeur est un programme.
• Vérifiez directement un dépôt suspect : git config --get core.fsmonitor.
• Auditez votre configuration globale : git config --global --list | grep fsmonitor.
• Désactivez le réglage par défaut : git config --global core.fsmonitor false. Vous perdez une optimisation de performance dont la plupart des dépôts n’ont jamais eu besoin.
• Préférez le clone au décompressage. Si on vous envoie une archive, poussez-la vers un dépôt distant puis clonez-la, ou supprimez .git et réinitialisez.

Si vous éditez un agent — le correctif que recommandent à la fois Manifold et OpenAI :

• Neutralisez la configuration du dépôt sur chaque appel en arrière-plan : git -c core.fsmonitor=false status. Établissez une liste blanche des clés de configuration transmises plutôt qu’une liste noire de celles que vous connaissez, car core.fsmonitor n’est pas le seul point d’exécution.
• Déplacez la collecte de contexte après l’invite de confiance de l’espace de travail, et traitez cet ordonnancement comme un invariant testé, pas comme un correctif ponctuel — cette séquence exacte a déjà régressé une fois.
• Exécutez les sous-processus d’arrière-plan dans le même sandbox que les appels d’outils initiés par le modèle. La séparation actuelle, où les appels propres au harnais échappent à la frontière, est la cause racine.

Sur le plan organisationnel : épinglez et suivez les versions de vos agents (une installation restée sous la version corrigée demeure exposée, quoi qu’ait livré l’éditeur), et traitez « ouvrir un dossier reçu avec un agent » comme un événement d’exécution dans votre modèle de menace, pas comme une lecture.

Statut

Agent	Signalé	État au retest Manifold du 1er sept.	Référence
goose	13 juil. 2026	Corrigé en 1.44.0	CVE-2026-72718, score de base CVSS 4.0 : 7.0
Claude Code (core.fsmonitor)	26 juin 2026	Corrigé en 2.1.196	Aucun avis publié par l’éditeur
Claude Code (chemin de revue)	15 juil. 2026	Non corrigé — confirmé sur 2.1.252	Clé de config tue par les chercheurs
OpenAI Codex	20 juil. 2026	Corrigé — CLI 0.131.0, Desktop 26.519.x	CVE-2026-19592 et deux autres
Cursor CLI	8 juil. 2026	Corrigé	Doublon d’un signalement antérieur
Qwen Code	7 juil. 2026	Non corrigé — confirmé sur 0.22.3	Accepté par l’Alibaba SRC
Grok Build	14 juil. 2026	Non corrigé — confirmé sur 1.0.13	Signalement antérieur classé « informatif »
Hermes Agent	20 juil. 2026	Non corrigé — confirmé sur 0.21.0	CVE-2026-71963, attribué par VulnCheck
Exploitation	—	Aucune source ne rapporte d’exploitation active ; aucun de ces identifiants au catalogue CISA KEV au 2 sept. 2026	—

Les versions, dates et suites données aux signalements ci-dessus sont celles rapportées par Manifold Security et The Hacker News dans les publications liées. Manifold indique avoir trouvé le même schéma dans des agents qu’elle ne nomme pas, et a retenu à la fois un dépôt prêt à l’emploi et la seconde clé de configuration de Claude Code. Vérifiez la version que vous avez réellement installée plutôt que de supposer qu’un correctif éditeur vous est parvenu.