Un .git piégé fait courir vos agents

Ce qui se passe

Manifold Security publie sous le nom GitSpawn huit failles réparties sur sept agents de code en ligne de commande. Le principe est le même partout : la configuration d'un dépôt désigne une commande, et l'agent l'exécute sur la machine du développeur — sous son identité, hors du bac à sable de l'agent et sans invite d'approbation.

La clé en cause est core.fsmonitor. C'est un réglage de performance de Git dont la valeur est une commande, lancée pour déterminer les fichiers modifiés. Git la lit dans le .git/config du dépôt lui-même, et toute opération qui rafraîchit l'index — git status, git diff — la déclenche. Or c'est exactement ce qu'un agent fait à l'ouverture d'un dossier, pour savoir sur quelle branche il se trouve.

Manifold résume le point : « La vulnérabilité n'est pas dans le modèle, ni dans quoi que ce soit de nouveau. Elle est dans la plomberie ordinaire en dessous. »

Le moment d'exécution varie selon l'agent, et il est chaque fois trop tôt :

Agent	La charge part…
Claude Code, Hermes Agent	avant l'acceptation du dialogue de confiance
Qwen Code	avant même l'authentification
Grok Build	à la première frappe
goose	pendant `goose review`, avant tout appel au modèle

Le vecteur : des fichiers, pas un clone

Le détail qui décide de votre exposition : l'attaque exige que le dépôt arrive sous forme de fichiers avec son répertoire .git intact. Une archive partagée, un lecteur réseau, un dossier synchronisé, une clé USB conservent le .git/config. Un git clone ordinaire, non — la configuration locale ne se transmet pas.

Versions et correctifs

goose — toutes versions < 1.44.0, corrigé en 1.44.0. CVE-2026-72718, CVSS 4.0 de 7.0, avis GHSA-r5pp-p5r8-466r, crédit Francisco Rosales.
Codex CLI — 0.102.0 à 0.130.0, corrigé en 0.131.0 (CVE-2026-19592). La version courante est 0.152.1 : une installation épinglée sous 0.131.0 reste exposée.
Codex Desktop — macOS corrigé en 26.519.22136, Windows en 26.519.21041, paquet Microsoft Store en 26.519.2081.0.
Claude Code — chemin core.fsmonitor confirmé sur 2.1.193, corrigé par 2.1.196 ; un second chemin, atteint via claude ultrareview, était encore actif sur 2.1.252 le 1er septembre (CVE-2026-55607 pour l'exécution fsmonitor pendant les opérations de worktree).
Non corrigés au 1er septembre — Hermes Agent 0.18.2 et 0.21.0, Qwen Code 0.19.6 et 0.22.3, Grok Build 0.2.93 et 1.0.13.

Aucune exploitation n'est rapportée : le 2 septembre, aucun de ces CVE ne figure au catalogue KEV de la CISA (version 2026.09.01, 1 687 entrées).

Ce n'est pas la première fois

Sonar avait signalé le même point d'entrée en avril, et identifié le même contournement du dialogue de confiance dans Visual Studio Code avant 1.63.1 (CVE-2021-43891) et dans les IDE JetBrains avant 2021.3.1 (CVE-2022-24346). Claude Code 2.0.34, publié le 5 novembre 2025, avait déjà déplacé sa séquence de démarrage pour fermer ce chemin — que Manifold retrouve dans 2.1.193, publiée le 25 juin 2026.

À retenir

git config --global core.fsmonitor false — le réglage est désactivé par défaut, l'attaque a besoin qu'il soit lu depuis le dépôt.
Avant d'ouvrir un dossier reçu : inspecter .git/config et y chercher core.fsmonitor, core.hooksPath et attr.tree, puis git config --get core.fsmonitor dans le dépôt.
Auditer le global avec git config --global --list | grep fsmonitor.
Côté éditeurs d'agents, l'appel de fond correct est git -c core.fsmonitor=false status.

Source : The Hacker News