Ouvrir un repo suffit : Claude Code, Codex et Cursor percés
Une ligne dans .git/config exécute du code hors sandbox, avant la moindre demande d'autorisation.
Un dossier posé sur votre disque peut exécuter des commandes chez vous avant même que l'agent affiche sa demande d'autorisation. Pas d'injection de prompt, pas de modèle qui déraille : une ligne de configuration Git vieille de dix ans. En dix jours, trois publications ont décrit la même plomberie percée chez Claude Code, Codex, Cursor et quatre autres agents. Si vous ou vos prestataires ouvrez des projets clients dans un agent codeur, c'est votre poste qui est concerné, pas un labo lointain.
Ce qu'un fichier .git/config piégé déclenche vraiment
Git connaît un réglage nommé core.fsmonitor. Sa valeur n'est pas un booléen anodin : c'est un chemin de programme que Git lance pour savoir quels fichiers ont changé. Ce réglage se lit dans le .git/config du dépôt lui-même.
Or, tout agent codeur commence sa vie par la même chose : reconstituer le contexte du projet. Branche courante, fichiers modifiés, diff. Donc git status, git diff, rafraîchissement de l'index. Git exécute alors le helper indiqué par le dépôt, sous votre compte utilisateur, hors de la sandbox de l'agent, sans prompt, sans ligne à l'écran. C'est tout le mécanisme baptisé GitSpawn par Manifold Security, publié le 1er septembre : huit trouvailles d'exécution de code réparties sur sept agents. La formule des chercheurs mérite d'être encadrée : la faille n'est ni dans le modèle, ni dans quoi que ce soit de neuf, elle est dans la tuyauterie ordinaire en dessous. VS Code avait corrigé une variante du même problème en 2021.
Point crucial pour évaluer votre exposition : un git clone classique ne transporte pas le .git/config du serveur. Le dépôt piégé doit arriver sous forme de fichiers, répertoire .git intact — archive ZIP, clé USB, dossier synchronisé Dropbox ou Drive, restauration de sauvegarde, transfert de projet par un client. Autrement dit : exactement la façon dont un freelance ou une agence récupère un vieux projet à reprendre.
Beltdown : Claude Code sortait de sa sandbox macOS jusqu'au 26 août
L'épisode le plus documenté est tombé hier. La startup israélienne Accomplish (Tel-Aviv, fondée par Amit Avner, Or Hiltch et Guy Zipori) a publié le détail technique de Beltdown, une évasion de sandbox visant Claude Code sur macOS. Le principe : le harnais de l'agent lance ses commandes Git en dehors de la sandbox, alors que l'outil Bash, lui, tourne dedans. Un .git/config empoisonné placé dans un sous-dossier imbriqué, un rafraîchissement d'index déclenché par le chargement automatique d'une skill, et la commande de l'attaquant s'exécute côté hôte. Formulation d'Accomplish : « un dépôt non fiable ouvert dans Claude Code peut s'échapper de la sandbox macOS et lancer des commandes sur votre ordinateur avec votre compte privilégié. Vous ne voyez jamais le prompt d'autorisation. »
La chronologie compte autant que la faille. Signalement le 13 juillet, tri le jour même. Correctif partiel le 6 août en 2.1.223 — incomplet. Correctif complet le 26 août en 2.1.247. Six semaines pendant lesquelles Claude Code a continué de cumuler ses 77 millions de téléchargements npm mensuels. Ce n'est pas une faille de laboratoire : c'est l'outil que des milliers de PME ont posé sur les Mac de leurs développeurs sans se demander ce que « sandbox » veut dire chez l'éditeur. On avait déjà chiffré ce décalage entre adoption et posture de sécurité dans notre enquête sur les 65 % d'entreprises dont un agent IA a déjà été compromis.
Une semaine chez OpenAI, cinquante jours chez Anthropic
Accomplish a livré ses chiffres à Upstarts Media le 10 septembre : une faille remontée à Cursor en juillet, corrigée en une semaine environ ; deux failles remontées à OpenAI, corrigées en une semaine environ ; une faille remontée à Anthropic, corrigée au bout d'une cinquantaine de jours et d'une trentaine de mises à jour logicielles. OpenAI a confirmé les correctifs d'août et parle de sandboxes « continuellement renforcées ». Anthropic et Cursor n'ont pas commenté officiellement.
La phrase d'Or Hiltch, CTO d'Accomplish, résume le malaise du secteur : « On parle beaucoup de sécurité en ce moment. Ça ne se reflète pas vraiment dans la façon dont ils construisent les produits. » Il pose ensuite la question que tout le monde évitait : si ces modèles de frontière sont si bons, pourquoi ne trouvent-ils pas ces vulnérabilités critiques dans leurs propres produits ?
Côté GitSpawn, le tableau est pire : sur huit signalements, quatre étaient encore ouverts au moment de la publication. Nous Research n'a jamais trié le rapport concernant Hermes Agent malgré cinq canaux de contact, la CVE-2026-71963 lui étant tout de même attribuée. Qwen Code et Grok Build restaient exposés, tout comme un second chemin de configuration dans Claude Code. Rien à voir, cette fois, avec les évasions de sandbox observées côté modèles eux-mêmes : ici, ce sont les outils, pas les IA, qui laissent la porte ouverte.
Claude Code, Codex, Cursor : quelles versions sont corrigées
- Claude Code : mettez-vous en 2.1.247 minimum (Beltdown). Le volet fsmonitor de GitSpawn avait été traité en 2.1.196 ; une variante d'exécution via une autre clé de configuration restait ouverte en 2.1.252. Rappel : la RCE par lien symbolique CVE-2026-39861 était, elle, corrigée en 2.1.64.
- Codex CLI : versions 0.102.0 à 0.130.0 vulnérables, correctif en 0.131.0 (CVE-2026-19592). Le lot précédent, découvert par Pillar Security, était couvert par la 0.95.0.
- Cursor : correctif en 3.0.0, qui embarque aussi CVE-2026-48124 (exécution via un fichier de hooks Claude en dehors de la sandbox).
- Goose : versions antérieures à 1.44.0 vulnérables, CVE-2026-72718, score CVSS 4.0 de 7.0.
- Hermes Agent, Qwen Code, Grok Build : non corrigés à la publication du 1er septembre. À traiter comme des outils à n'ouvrir que sur du code que vous avez écrit.
Cherchez core.fsmonitor, mais aussi core.hooksPath, core.pager, core.sshCommand et les alias.* : tous acceptent une commande. Si l'un de ces champs est renseigné dans un dépôt que vous n'avez pas créé, supprimez-le avant d'ouvrir quoi que ce soit.
Le one-liner qui circule ne suffit pas
Plusieurs reprises de l'affaire recommandent git config --global core.fsmonitor false. C'est une fausse sécurité contre ce scénario précis : dans l'ordre de précédence de Git, la configuration locale du dépôt l'emporte sur la globale. Un .git/config piégé écrase donc votre réglage global sans effort. Ce qui neutralise réellement l'exécution, c'est de passer la valeur en ligne de commande — git -c core.fsmonitor=false status — puisqu'elle prime sur tout le reste. C'est exactement ce que Manifold demande aux éditeurs d'appliquer à leurs appels Git d'arrière-plan.
Deuxième illusion, la mienne : je pensais mon poste couvert parce que mes agents tournent en devcontainer. Sauf que j'y montais la socket Docker pour laisser l'agent construire ses images — précisément l'un des vecteurs relevés par Pillar Security (GHSA-v4xv-rqh3-w9mc), où un accès à /var/run/docker.sock revient à donner l'hôte. J'ai retiré le montage et déporté les builds sur un runner séparé, comme décrit dans notre tutoriel pour faire tourner Claude Code sur votre propre infrastructure. Le conteneur est redevenu une frontière, pas une décoration.
Ce que ça change pour une PME qui sous-traite son code
Un chiffre pour cadrer le risque métier : le scénario d'attaque le plus réaliste n'est pas un dépôt GitHub public malveillant, c'est une reprise de legacy. Un client vous envoie un ZIP de son ancien site, une agence récupère le projet d'un prestataire sortant, un dev restaure une sauvegarde de 2023. Dans les trois cas, le .git est intact et l'agent va l'ouvrir sans poser de question. À l'échelle d'une structure de dix personnes, il suffit qu'un poste exécute la charge pour que les tokens Git, les clés API et les accès cloud de cette machine soient à portée.
La bonne réponse organisationnelle n'est pas d'interdire les agents codeurs — nous avons comparé les principaux dans notre passage en revue de six IDE IA sur 14 critères et aucun n'est remplaçable par un éditeur nu aujourd'hui. C'est de cesser de traiter la mention « sandbox » comme un périmètre de sécurité. Une sandbox d'agent, en 2026, c'est un ralentisseur : elle limite ce que le modèle fait volontairement, pas ce que la tuyauterie exécute sans lui.
Le verdict
Trois choses à faire cette semaine si vous dirigez une équipe technique : passer les versions listées plus haut, écrire une règle interne sur les dépôts reçus de l'extérieur, sortir les secrets de production des postes qui font tourner des agents. Ça prend une demi-journée.
Ce dossier concerne les développeurs, les agences web et les DSI qui laissent des agents ouvrir du code tiers. Il ne concerne pas la PME qui utilise ChatGPT pour rédiger ses devis. Mais il dit quelque chose de plus large sur l'écosystème : les éditeurs livrent des fonctionnalités d'agent à un rythme hebdomadaire, et le temps de correction d'une exécution de code arbitraire varie encore de sept à cinquante jours selon la maison. Tant que ce chiffre-là ne sera pas un argument commercial, il faudra continuer de vérifier soi-même le contenu de .git/config.
