Les assistants de code IA peuvent être détournés par une entrée .git/config malveillante qui exploite la fonctionnalité core.fsmonitor de Git, permettant à un dépôt non fiable d'exécuter des commandes sur la machine d'un développeur dès l'instant où l'assistant analyse les fichiers.

La faille est apparue dans plusieurs agents populaires — Claude Code, Cursor, OpenAI Codex, Goose, Qwen Code, Grok Build et Hermes. Dans les agents corrigés, l'exploit ne fonctionne plus ; les autres restent vulnérables. Aucune interaction ou invite supplémentaire n'est nécessaire, et le code malveillant s'exécute avec les propres privilèges de l'utilisateur, en dehors de tout bac à sable (sandbox) que l'agent IA pourrait fournir.

Comment l'attaque atteint un développeur

  • Un prestataire compresse un projet dans un fichier zip et l'envoie par e-mail.
  • Un collègue partage un dossier sur un lecteur réseau.
  • Une clé USB est remise avec une base de code.

Dans chaque cas, le dépôt arrive sous la forme d'un répertoire contenant déjà un dossier .git. Lorsqu'un assistant IA ouvre le dossier, il exécute généralement git status en arrière-plan pour construire une vue du code. Git accélère cette opération grâce au paramètre core.fsmonitor, qui indique à Git d'appeler un programme externe pour surveiller les changements dans le système de fichiers. Si le fichier .git/config du dépôt définit une commande malveillante pour core.fsmonitor, Git l'exécute automatiquement, sans consulter l'utilisateur.

Comme la commande est lancée par Git lui-même, elle hérite des droits de l'utilisateur et contourne tout bac à sable que l'outil d'IA aurait pu mettre en place. L'exploit ne se déclenche pas lors d'un git clone, git fetch ou git pull classique ; il ne s'active que lorsque le dépôt est décompressé avec ses métadonnées .git déjà présentes.

Pourquoi ce problème est important

Les développeurs s'appuient de plus en plus sur les assistants IA pour suggérer des complétions, refactoriser du code ou générer des modules entiers. Ces outils ont besoin d'un instantané rapide de l'arborescence des fichiers du projet, ils invoquent donc les commandes Git silencieusement. Si un dépôt malveillant peut exécuter du code à ce moment-là, un attaquant gagne un point d'ancrage sur la station de travail du développeur sans aucun avertissement visible. La charge utile (payload) potentielle va du vol d'identifiants à l'installation de portes dérobées (backdoors) persistantes, le tout pendant que l'utilisateur pense simplement « vérifier » le code avec un assistant IA.

Détecter un dépôt empoisonné

Avant de confier un dépôt à un assistant, exécutez :

git config --get core.fsmonitor

Un résultat non vide signifie qu'un programme est configuré pour s'exécuter automatiquement. Pour un examen plus large, listez tous les paramètres Git suspects :

git config --local --list | grep -Ei 'fsmonitor|hooksPath|sshCommand|pager|editor|filter\.'

Si vous repérez des entrées que vous n'avez pas ajoutées, effacez-les avec :

git config --local --unset core.fsmonitor

Notez que le réglage git config --global core.fsmonitor false ne vous protège pas. Les paramètres locaux d'un dépôt l'emportent toujours sur les paramètres globaux, un dépôt malveillant peut donc simplement ignorer une règle globale.

État actuel des correctifs

  • Claude Code – corrigé (fsmonitor)
  • Cursor – corrigé
  • OpenAI Codex – corrigé
  • Goose – corrigé
  • Qwen Code – non corrigé
  • Grok Build – non corrigé
  • Hermes – non corrigé

Les développeurs utilisant les agents non corrigés devraient considérer tout dépôt entrant comme potentiellement dangereux jusqu'à ce qu'ils changent d'outil ou imposent des politiques Git locales plus strictes.

Contre-argument de la communauté Git

Le core.fsmonitor de Git est une fonctionnalité de performance légitime, pas un bug. Les mainteneurs soutiennent qu'il incombe aux appelants de valider le contenu des dépôts avant d'invoquer des commandes Git. Désactiver la fonctionnalité globalement est une mesure d'atténuation simple, mais comme indiqué, les contournements locaux peuvent saboter cette protection. Le débat plus large porte désormais sur la question de savoir si les assistants IA devraient isoler (sandboxing) toutes les invocations Git externes ou refuser de traiter les dépôts contenant des hooks fsmonitor personnalisés.

À surveiller ensuite

  • Les mises à jour des agents IA non corrigés — en particulier toute déclaration concernant l'isolation (sandboxing) des appels Git.
  • Les changements potentiels dans la gestion par défaut de core.fsmonitor par Git pour les répertoires non fiables.
  • Les outils tiers capables de nettoyer le fichier .git/config d'un dépôt avant qu'il n'atteigne un assistant.

À retenir

Une seule ligne dans un fichier de configuration caché peut transformer une commodité alimentée par l'IA en un vecteur d'exécution de code à distance. Jusqu'à ce que les agents vulnérables soient corrigés, la pratique la plus sûre consiste à auditer chaque dépôt arrivant en dehors d'un flux de travail de clonage standard et à supprimer tout hook core.fsmonitor ou similaire avant de laisser un assistant IA toucher au code.