Les assistants de codage IA tels que Claude Code, Cursor et Grok Build peuvent exécuter des commandes arbitraires dès l'instant où un développeur ouvre un dépôt non fiable, sans aucun clic ou invite de confirmation. La faille provient de la manière dont ces outils invoquent la fonctionnalité core.fsmonitor de Git pour scanner les fichiers d'un projet.

Pourquoi ce problème est important aujourd'hui

Les développeurs s'appuient de plus en plus sur des agents IA pour suggérer du code, refactoriser des fonctions ou même écrire des modules entiers. Ces agents ont besoin d'un aperçu rapide de l'espace de travail, ils exécutent donc git status en arrière-plan. Lorsque Git lit le fichier .git/config d'un dépôt, toute valeur assignée à core.fsmonitor est traitée comme une commande shell que Git exécutera. Un acteur malveillant peut placer une commande spécialement conçue dans cette entrée de configuration, et l'appel Git en arrière-plan de l'IA la déclenchera avant même que l'utilisateur ne tape une seule ligne de code.

Le code s'exécute avec les propres privilèges du développeur, contournant le bac à sable (sandbox) dans lequel l'agent IA opère normalement. En pratique, un dépôt compromis peut installer un malware, exfiltrer des identifiants ou modifier des fichiers sources, tout cela pendant que le développeur pense que l'assistant ne fait que proposer des suggestions.

Comment l'attaque se déroule

  1. Préparation – Un attaquant crée un dépôt dont le fichier .git/config contient une ligne telle que core.fsmonitor = /path/to/malicious/script.
  2. Livraison – Le dépôt est transmis sous forme de fichier zip, copié depuis une clé USB, synchronisé via un lecteur partagé ou placé d'une autre manière sur la machine de la victime avec le dossier .git déjà présent.
  3. Déclenchement – Le développeur ouvre le dossier dans un IDE compatible avec l'IA. L'assistant exécute git status pour recueillir le contexte. Git lit la configuration locale, exécute la commande core.fsmonitor, et le script malveillant s'exécute immédiatement.

Un simple git clone n'expose pas ce risque car le clonage crée un nouveau répertoire .git qui ne contient pas la configuration falsifiée. L'attaque ne fonctionne que lorsque l'attaquant peut fournir un dossier .git préexistant.

Ce qui est en jeu

  • Les développeurs individuels peuvent voir leur machine compromise sans s'en rendre compte, perdant toutes les données auxquelles l'agent IA peut accéder.
  • Les équipes qui partagent du code via des lecteurs internes ou des fichiers zip de prestataires peuvent propager la charge utile sur de nombreux postes de travail.
  • Les fournisseurs d'outils risquent des dommages réputationnels si les utilisateurs attribuent la faille à l'assistant IA plutôt qu'à l'interaction Git sous-jacente.

Comme la commande malveillante hérite des droits de l'utilisateur, elle peut modifier n'importe quel fichier que le développeur peut modifier, y compris les clés SSH, les scripts de build ou les identifiants de déploiement.

Mesures d'atténuation que les développeurs peuvent prendre dès aujourd'hui

  • Ne faites pas confiance aux paramètres Git locaux. La configuration d'un dépôt remplace les valeurs globales chaque fois qu'un assistant IA interroge le projet.

  • Inspectez l'entrée core.fsmonitor avant d'ouvrir un dossier avec un assistant : 

    git config --get core.fsmonitor

    Si une valeur apparaît, considérez-la comme suspecte.

  • Supprimez l'entrée avec : 

    git config --local --unset core.fsmonitor

  • Vérifiez d'autres clés risquées que Git peut exécuter : hooksPath, sshCommand, pager, editor, filter. Utilisez le même modèle git config --get pour vérifier qu'elles sont vides.

  • Privilégiez les clones propres pour tout code que vous avez l'intention de soumettre à un outil d'IA. Si vous devez travailler avec un fichier zip ou un dossier transféré, supprimez son répertoire .git et réinitialisez le dépôt, ou effectuez les vérifications ci-dessus au préalable.

Où se situe la responsabilité

La vulnérabilité n'est pas un défaut des modèles de langage qui alimentent Claude Code, Cursor ou Grok Build ; c'est une conséquence de la manière dont ces outils collectent les informations sur les fichiers. Certains fournisseurs ont commencé à isoler plus strictement les appels Git, mais le comportement par défaut fait toujours confiance aux paramètres du dépôt local. Jusqu'à ce que l'industrie adopte une norme qui supprime ou ignore les entrées de configuration potentiellement dangereuses lorsqu'un agent IA analyse un espace de travail, les développeurs doivent rester la dernière ligne de défense.

À surveiller prochainement

  • Les mises à jour d'outils qui assainissent explicitement la configuration Git avant d'invoquer git status.
  • Les directives communautaires pour un développement assisté par IA en toute sécurité, qui incluront probablement des vérifications préliminaires recommandées.
  • La recherche en sécurité qui pourrait découvrir d'autres clés de configuration Git capables d'exécution de code, étendant la liste de contrôle au-delà des cinq clés mises en évidence ci-dessus.

En résumé : un assistant IA peut être un binôme de programmation pratique, mais il exécutera volontiers n'importe quelle commande cachée dans la configuration Git d'un dépôt. Vérifiez l'espace de travail avant de laisser l'assistant y toucher.