GitSpawn : des fichiers .git/config malveillants exécutent du code dans les agents IA avant toute action

Daniel Reyes Ingénieur Principal (IA/ML), YuSMP Group · Sécurité IA/ML, agents LLM et systèmes IA en production pour les équipes américaines et européennes

En bref

Comment GitSpawn fonctionne réellement

La clé de configuration core.fsmonitor de Git a été introduite comme optimisation de performance : au lieu de scanner l'arborescence entière à chaque git status, Git peut déléguer la vérification à un observateur de système de fichiers externe. La valeur de la clé est une commande shell que Git exécute directement, en lui passant l'heure de la dernière vérification et en attendant en retour une liste de chemins modifiés. De façon critique, Git ne dispose d'aucun mécanisme pour valider ou isoler cette commande — il exécute la chaîne de caractères présente dans la configuration avec les privilèges du processus appelant.

Les assistants IA de codage appellent régulièrement git status, git diff et des commandes connexes en arrière-plan pour comprendre l'état actuel d'un dépôt avant de générer des suggestions ou d'effectuer des actions agentiques. Quand un tel outil ouvre un dossier de projet contenant un .git/config malveillant, le tout premier appel Git en arrière-plan déclenche le hook fsmonitor, exécutant la charge utile de l'attaquant. Le dialogue workspace-trust de l'agent — conçu pour empêcher les paramètres d'espace de travail malveillants d'exécuter du code — se déclenche après la collecte initiale du contexte Git, pas avant. La charge utile s'est déjà exécutée.

Dans la démonstration de faisabilité de Manifold Security, l'entrée malveillante ressemblait à n'importe quelle autre ligne d'optimisation des performances pour un relecteur de code inattentif. Le chercheur a confirmé que la charge utile s'était exécutée avant que l'utilisateur n'ait validé tout dialogue de confiance dans chaque agent testé. L'attaque est silencieuse : l'agent ne signale pas d'erreur ni d'avertissement ; il continue à charger l'espace de travail comme si de rien n'était.

Comment la configuration malveillante vous parvient

C'est le détail le plus important pour une évaluation précise des menaces, et un point que certaines couvertures secondaires ont brouillé : un git clone normal ne reproduit pas la vulnérabilité. Lorsque vous clonez un dépôt distant, Git récupère la base de données d'objets et recrée l'arborescence de travail, mais il ne copie pas le .git/config distant dans le vôtre. Le .git/config sur votre machine est généré de zéro par Git lui-même et ne contient que vos paramètres locaux. L'entrée malveillante n'arrive jamais.

GitSpawn nécessite que le répertoire .git/ soit livré intact, avec le .git/config contrôlé par l'attaquant déjà à l'intérieur. Les vecteurs de livraison réalistes sont :

• Archives ZIP et tarballs. Quand un projet est partagé sous forme de dossier compressé, le répertoire .git/ est inclus par défaut. Un collègue envoyant par e-mail un ZIP « starter repo », un fournisseur proposant un modèle d'intégration, ou un wiki interne liant vers un scaffold packagé sont tous des canaux de livraison viables.
• Lecteurs réseau partagés et stockage cloud. La copie d'un dossier de projet depuis un lecteur partagé préserve .git/ intact. Courant dans les équipes qui utilisent un NAS partagé ou une synchronisation de fichiers cloud au lieu d'un vrai contrôle de version pour les outils internes.
• USB ou média externe. Moins courant dans le développement moderne, mais encore présent dans les environnements air-gapped ou réglementés.

L'implication pratique pour les équipes est de traiter tout dossier de projet reçu sous forme d'archive avec la même prudence que vous appliqueriez à un exécutable : vérifiez la source, recherchez les entrées .git/config inattendues, et envisagez d'ouvrir les dossiers non fiables dans un environnement de conteneur isolé avant de les charger dans un IDE assisté par IA.

Quels outils sont affectés et lesquels sont corrigés

Manifold Security a testé sept agents IA de codage et a constaté que tous ont déclenché la charge utile fsmonitor. Le calendrier de divulgation, les CVE et l'état des correctifs au 3 septembre 2026 :

Manifold Security a suivi une divulgation responsable, notifiant chaque fournisseur avant la publication. Anthropic, Block, OpenAI et Cursor ont répondu et publié des correctifs avant le writeup public. xAI, Alibaba et le mainteneur d'Hermes Agent n'ont pas fourni de correctif dans le délai de divulgation. Manifold a confirmé qu'un second chemin d'exécution dans Claude Code pourrait rester ouvert dans les versions jusqu'à 2.1.252 — Anthropic l'a reconnu et le suit séparément.

Ce que cela signifie pour les équipes de développement

Le message immédiat est simple : mettez à jour vos outils IA de codage. Mais l'implication plus large est structurelle, et elle concerne toute équipe qui a commencé à faire tourner des agents IA avec accès en écriture au code ou aux systèmes de fichiers.

Les assistants IA de codage ont été conçus principalement sous un angle productivité — à quelle vitesse peuvent-ils collecter du contexte, combien d'opérations peuvent-ils automatiser, dans quelle mesure peuvent-ils s'intégrer au flux de travail existant du développeur. GitSpawn expose le coût sécuritaire de cette priorité de conception. Les agents qui ont déclenché la charge utile fsmonitor l'ont fait parce qu'ils faisaient exactement ce qu'ils sont censés faire : collecter automatiquement et immédiatement le contexte git, sans déranger le développeur. La frontière de confiance — workspace-trust — était architecturée pour gérer les paramètres d'espace de travail malveillants, pas un hook Git militarisé qui se déclenche avant que l'espace de travail soit entièrement chargé.

Pour les équipes dans des secteurs réglementés, il y a un angle supplémentaire. Une machine développeur faisant tourner un assistant IA de codage avec accès au code source, aux variables d'environnement et aux identifiants cloud est une cible de haute valeur. Un attaquant qui peut exécuter du code sur cette machine via un ZIP de projet partagé peut exfiltrer silencieusement des clés API, des jetons de session et des dépôts d'identifiants locaux. Pour les organisations soumises à SOC 2, ISO 27001, ou à la directive NIS2 de l'UE, ce n'est pas un risque hypothétique — c'est une lacune dans l'inventaire de contrôles autour de la sécurité des endpoints développeurs que la plupart des équipes n'ont pas encore auditée.

La troisième implication concerne les équipes qui construisent des systèmes d'agents IA, pas seulement celles qui les utilisent. Si votre produit inclut un agent qui opère sur des fichiers ou des dépôts fournis par les utilisateurs, la même surface d'attaque s'applique à vos utilisateurs. Un audit de la façon dont votre agent gère les opérations Git, quels hooks il respecte et quel modèle de confiance régit l'accès aux fichiers tiers est une précaution sensée maintenant, avant que la prochaine variante de cette classe n'émerge. Ce type d'examen est exactement ce que couvre un test de pénétration axé sur les surfaces d'attaque des agents IA.

Perspective marché France : L'ANSSI (Agence nationale de la sécurité des systèmes d'information) a publié plusieurs recommandations sur la sécurisation des chaînes d'approvisionnement logicielles, et GitSpawn illustre exactement le type de menace ciblée dans le guide « Prestataires de services numériques ». Pour les entreprises françaises soumises à la directive NIS2 — transposée en droit français par la loi relative à la résilience des activités d'importance vitale — cette vulnérabilité relève des mesures de gestion des risques liés aux fournisseurs (article 21 NIS2). Les ESN (Entreprises de Services du Numérique) qui déploient des agents IA dans leurs environnements de développement pour leurs clients doivent considérer cette classe de failles comme un point d'audit obligatoire dans leurs engagements PSSI et leurs contrats de sous-traitance. La pratique courante en France de partager des archives projet par e-mail ou via des espaces SharePoint/Teams internes rend ce vecteur d'attaque particulièrement pertinent.

Ce qu'il faut faire maintenant

1. Mettez à jour Claude Code vers la version 2.1.196 ou ultérieure. Exécutez npm update -g @anthropic-ai/claude-code ou l'équivalent pour votre méthode d'installation. Surveillez un correctif de suivi concernant le chemin secondaire.
2. Mettez à jour Goose vers la version 1.44.0 ou ultérieure. Vérifiez votre gestionnaire de paquets ou la page des versions GitHub de Goose pour la dernière version.
3. Mettez à jour OpenAI Codex vers la version 0.131.0 ou ultérieure. Exécutez npm update -g @openai/codex ou mettez à jour via la CLI.
4. Mettez à jour Cursor. Installez toute mise à jour d'août 2026 ou ultérieure depuis le site web de Cursor ou le programme de mise à jour intégré.
5. Cessez d'utiliser Grok Build, Qwen Code ou Hermes Agent avec des dossiers de projet non fiables jusqu'à la disponibilité de correctifs. Si ces outils sont utilisés dans votre équipe, émettez un avis de politique dès aujourd'hui.
6. Auditez la façon dont les dossiers de projet sont partagés. Si votre équipe distribue des dépôts de démarrage, des templates de scaffolding ou des archives de projet client sous forme de fichiers ZIP, ajoutez une étape pour supprimer les répertoires .git/ avant l'empaquetage, ou documentez que les destinataires doivent vérifier .git/config avant de les ouvrir dans un IDE assisté par IA.
7. Ajoutez une vérification des hooks Git à votre processus d'intégration des développeurs. Une simple étape de lint qui signale core.fsmonitor, core.hooksPath ou autres points d'extension inattendus dans .git/config à l'ouverture du projet prend quelques minutes à écrire et ferme définitivement cette classe d'attaque pour votre équipe.

Questions fréquemment posées

Sources

The Hacker News — Malicious Git Configs Can Make Claude Code, Cursor, and Codex Execute Arbitrary Commands
Manifold Security — AI Coding Agents Git Hijack: GitSpawn Research (Francisco Rosales)