Un fichier .git/config piégé exécute du code à l’ouverture d’un dépôt dans Claude Code, Codex ou Cursor
Manifold Security a divulgué le 2 septembre 2026 huit failles dans sept agents de codage en ligne de commande : un dépôt reçu en archive peut faire exécuter une commande locale dès son ouverture, hors sandbox et sans validation, via le paramètre core.fsmonitor de Git. Désactivez core.fsmonitor par défaut et inspectez .git/config avant d’ouvrir un dossier reçu avec un agent.
2 septembre 2026. Manifold Security publie GitSpawn, huit vulnérabilités réparties sur sept agents de codage en ligne de commande. Le mécanisme tient en une ligne : le fichier .git/config d’un dépôt nomme une commande que l’agent exécute sur la machine du développeur. Pourquoi c’est important : cette commande part hors du sandbox, sans invite de validation, et le simple fait d’ouvrir un dépôt reçu en archive suffit à la déclencher.
Un paramètre de performance Git transformé en exécution de code
La faille ne touche ni le modèle, ni un protocole exotique. Elle exploite core.fsmonitor, un réglage de performance de Git dont la valeur est une commande que Git exécute pour repérer les fichiers modifiés. Git lit cette valeur dans le .git/config du dépôt lui-même. Dès qu’une opération rafraîchit l’index — un git status, un git diff — la commande part.
Les agents de codage exécutent précisément ces opérations en arrière-plan, au démarrage de la session, pour savoir sur quelle branche ils sont et quels fichiers ont changé. Ils le font sans toucher à la configuration du dépôt — donc sans neutraliser la commande hostile. Chez Manifold, la formule est sans appel : « la vulnérabilité n’est pas dans le modèle, ni dans quoi que ce soit de nouveau. Elle est dans la plomberie ordinaire, le sous-processus que l’agent lance au démarrage pour savoir où il est. »
Le déclencheur varie selon l’agent, ce qui rend le scénario d’autant plus insidieux. Sur Claude Code et Hermes Agent, la charge part avant l’acceptation de l’invite de confiance de l’espace de travail ; sur Qwen Code, avant l’authentification de l’utilisateur ; sur Grok Build, à la première frappe.
Une condition atténue le risque — mais c’est elle qui définit le vrai scénario d’attaque. L’exploitation exige que le dépôt arrive sous forme de fichiers avec son répertoire .git intact. Un clone git normal ne le préserve pas. En revanche, une archive partagée, un lecteur partagé, un dossier de synchronisation ou une clé USB le conservent. Autrement dit, le vecteur réaliste n’est pas le clone d’un dépôt public, mais le dépôt reçu d’un tiers — le ZIP d’un recruteur, le partage d’un collègue, le livrable d’un prestataire.
Qui est corrigé, qui ne l’est pas
Le tableau est contrasté. goose (corrigé en 1.44.0), Claude Code sur le chemin core.fsmonitor (corrigé en 2.1.196) et Cursor ont livré des correctifs. OpenAI a publié le même jour trois CVE couvrant la classe identique dans Codex, créditées à trois équipes de recherche distinctes — dont CVE-2026-19592, qui décrit un helper exécuté « hors du sandbox de commandes de Codex et sans invite d’approbation utilisateur, laissant un code contrôlé par l’attaquant s’exécuter avec les privilèges de l’utilisateur ».
Restent non corrigés au moment du retest du 1er septembre par Manifold : Hermes Agent (confirmé sur 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), ainsi qu’un second chemin dans Claude Code, atteint via claude ultrareview et confirmé vivant sur la version 2.1.252.
Les identifiants racontent une partie de l’histoire. GitHub a attribué CVE-2026-72718 (score CVSS 4.0 de 7.0) à goose — c’est la seule notation publiée sur l’ensemble. VulnCheck a assigné CVE-2026-71963 pour Hermes Agent, mais l’identifiant n’apparaissait pas encore dans la liste MITRE au 2 septembre. La plupart des signalements ont été fermés comme doublons d’autres recherches indépendantes.
La vraie surface d’attaque : toute la config locale est suspecte
core.fsmonitor n’est que l’entrée la plus documentée d’un problème plus large. Le .git/config d’un dépôt contrôle trois autres leviers qui déclenchent eux aussi l’exécution de commandes locales : core.hooksPath, qui redirige les hooks vers un répertoire arbitraire ; attr.tree, qui charge un arbre d’attributs détourné ; et les filtres clean/smudge, exécutés à l’aller et au retour des fichiers. Tout outil qui fait confiance à la configuration d’un dépôt reçu hérite de ces leviers — la recommandation de Manifold d’inspecter ces trois clés n’est donc pas un luxe, c’est la liste minimale.
C’est précisément le sens du mot « confiance » qui est en jeu. L’invite de confiance de l’espace de travail des agents — le dialogue « faites-vous confiance à ce dossier ? » — est censée être la frontière de sécurité. Or, sur Claude Code et Hermes Agent, la charge part avant que ce dialogue soit accepté. La frontière est donc décorative sur les versions vulnérables : elle donne à l’utilisateur l’impression d’un contrôle qu’il n’a pas encore.
Le précédent est ancien, ce qui aggrave le constat. Sonar rappelle que le même contournement de dialogue de confiance existait dans Visual Studio Code avant la version 1.63.1 (CVE-2021-43891) et dans les IDE JetBrains avant 2021.3.1 (CVE-2022-24346). Cinq ans plus tard, la classe de bug se rejoue dans les agents de codage, avec un actif supplémentaire : l’agent exécute des commandes de lui-même, sans que l’utilisateur n’ait rien à taper.
Un problème connu, corrigé, puis régressé
Ce qui frappe, c’est que la faille n’est pas une découverte isolée. Sonar avait signalé le même puits dès avril, en notant qu’Anthropic avait déjà déplacé une fois la séquence de démarrage pour le fermer. La version 2.0.34 de Claude Code, livrée le 5 novembre 2025, ne lançait plus git status avant l’approbation du dialogue de confiance — puis le comportement est réapparu dans la 2.1.193, livrée le 25 juin 2026. Anthropic avait par ailleurs publié en juin un avis (CVE-2026-55607) sur l’exécution de git fsmonitor lors d’opérations sur l’arbre de travail.
C’est la leçon de fond : corriger une fois ne suffit pas. La classe de bug repose sur une fonctionnalité légitime de Git, réutilisée par des dizaines de couches d’outillage, et chaque nouvel agent qui s’appuie sur les commandes Git de fond réintroduit potentiellement le puits.
Le timing n’est pas anodin non plus. La classe resurgit au moment où les faux recruteurs distribuent déjà des tests de codage piégés — la campagne Nimbus Manticore, documentée quelques jours plus tôt, installe des RAT multiplateformes via de faux entretiens d’embauche. Un agent de codage qui exécute silencieusement la configuration d’un dépôt reçu transforme ce vecteur en exécution de code sans clic, là où le recruteur espérait au moins convaincre la victime d’ouvrir un PDF.
# Avant d'ouvrir un dépôt reçu avec un agent, trois vérifications :
git config --get core.fsmonitor # la commande piégée, si présente
git config --get core.hooksPath # redirection possible des hooks
git config --get attr.tree # un arbre d'attributs détourné
# Durcissement global : désactiver core.fsmonitor par défaut
git config --global core.fsmonitor false
git config --global --list | grep fsmonitorVerdict
Si vous développez avec un agent de codage en CLI, appliquez dès maintenant git config --global core.fsmonitor false et mettez à jour votre agent — goose ≥ 1.44.0, Codex ≥ 0.131.0, Cursor à jour, Claude Code au-delà de 2.1.196. Les installations Codex épinglées sous 0.131.0 restent exposées alors que la version courante est 0.152.1.
Si vous recevez des dépôts de tiers — archives de recruteurs, partages de prestataires, livrables de clients — traitez-les comme du code non fiable : inspectez .git/config (à la recherche de core.fsmonitor, core.hooksPath, attr.tree) avant de les ouvrir dans un agent, pas après.
Si vous intégrez des agents dans votre chaîne CI/CD, exigez que l’outil neutralise la configuration sur ses appels de fond (le motif git -c core.fsmonitor=false status) et auditez les versions déployées. Aucune exploitation n’est documentée à ce jour et aucune de ces CVE n’est au catalogue KEV de la CISA — mais la fenêtre entre « preuve de concept » et « campagne » est précisément le moment d’appliquer le correctif, pas de l’attendre.