Menu

GitSpawn : le .git/config du dépôt exécute du code dans votre agent, avant le prompt de confiance

Catégories

Tags

🔍 Licence d'Utilisation 🔍

Sauf mention contraire, le contenu de ce blog est sous licence CC BY-NC-ND 4.0.

© 2025 à 2042 Sébastien Gioria. Tous droits réservés.

⏱️
Temps de lecture estimé
2 min de lecture

Une clé de configuration Git qui traîne dans le produit depuis 2016, core.fsmonitor, suffit à faire exécuter du code arbitraire par sept agents de codage IA. Pas de prompt, pas de sandbox, et dans plusieurs cas avant même que l’agent vous demande si vous faites confiance au dossier que vous venez d’ouvrir.

Le prompt de confiance arrive après l’exécution

Un an à construire des garde-fous côté agent : sandbox de commandes, approbation d’outils, dialogue « faites-vous confiance à ce dossier ». Tout ça repose sur une hypothèse jamais vérifiée, à savoir que l’agent ne fait rien de dangereux entre le moment où il ouvre le dossier et le moment où il vous pose la question.

Manifold Security a mesuré cette fenêtre. Elle n’est pas vide.

Git propose depuis longtemps un réglage de performance nommé core.fsmonitor. Il permet à un dépôt de désigner un programme externe que git lance automatiquement à chaque rafraîchissement de l’index, donc à chaque git status ou git diff, donc à chaque collecte de contexte de votre agent de codage. Et la valeur de ce réglage peut vivre dans le .git/config du dépôt lui-même.

La frontière de confiance de votre agent commence au premier git status, pas au dialogue d’approbation.

Bonne nouvelle au passage, et elle est importante : un git clone ne vous expose pas. Le protocole Git ne réplique jamais la configuration locale d’un dépôt distant ; fetch et pull non plus. Pour que l’attaque fonctionne, le projet doit arriver sous forme de fichiers avec son répertoire .git déjà à l’intérieur. Une archive ZIP, un dossier partagé, une clé USB, le rendu d’un test technique de recrutement. Rien de glamour, et exactement la façon dont circulent les projets dans la vraie vie.

Sept agents concernés, huit constats déposés entre juin et juillet 2026, quatre encore sans correctif au retest du 1er septembre. Techniquement, il n’y a rien à admirer là-dedans : trois lignes de configuration, aucune obfuscation. Ce qui mérite qu’on s’y arrête, c’est que sept équipes qui ne se parlent pas aient reproduit la même erreur d’architecture, à savoir lancer des commandes Git sur un répertoire non encore validé en laissant le dépôt dicter les paramètres de ces commandes.

📬 Analyse complète réservée aux abonnés payants
L'analyse détaillée part d'abord aux abonnés payants de ma newsletter Substack, avant d'être publiée intégralement ici.

Au Menu de la version abonnés, vous retrouvez la suite :
  • les quatre vecteurs d'attaque détaillés, les autres clés Git qui nomment un programme, la fenêtre pré-trust
  • l'angle mort de l'EDR ;
  • la table STRIDE complète de la frontière pré-trust et le tableau d'impact (confidentialité, intégrité, disponibilité, réputation) ;
  • le scénario complet du test technique de recrutement, en sept étapes, où la victime ne commet aucune erreur ;
  • l'état agent par agent : ce qui est corrigé et ce qui ne l'est pas ;
  • les mitigations concrètes côté éditeur et côté poste de développeur, avec les commandes à mettre en alias ;
LinkedIn Reddit Substack