GitSpawn : sécuriser un dépôt avant de l’ouvrir avec un agent IA

Ce qui s’est réellement passé

Le 1er septembre 2026, Manifold Security a publié une série de vulnérabilités regroupées sous le nom GitSpawn. Le point commun est simple : plusieurs agents de code lancent automatiquement des commandes Git pour comprendre le dépôt ouvert — branche active, fichiers modifiés ou différence avec le dernier commit — parfois avant la première demande de l’utilisateur ou avant l’acceptation d’un écran de confiance.

Git peut lui-même appeler un programme défini dans la configuration locale du dépôt. Le réglage core.fsmonitor, conçu pour accélérer la détection des fichiers modifiés, est l’un des mécanismes documentés. Si un dossier reçu contient déjà un répertoire .git avec une configuration hostile, une commande ordinaire comme la collecte d’état peut entraîner l’exécution du programme désigné avec les droits de la personne qui a lancé l’agent.

Fait vérifié : Manifold a documenté huit constats sur sept agents et indique que quatre restaient non corrigés au moment de sa publication. Analyse Cresora : la bonne frontière de confiance doit être placée avant l’ouverture du dossier, pas seulement avant l’exécution d’une commande proposée par le modèle.

Ce n’est ni une injection de prompt ni un paquet malveillant

Dans ce scénario, le modèle n’a pas besoin de lire une instruction cachée et aucune dépendance ne doit être installée. L’agent demande seulement à Git de décrire le projet. Git lit alors sa configuration locale et peut activer un programme auxiliaire. Comme cette exécution se produit sous la commande Git lancée par l’application, elle peut précéder ou contourner les confirmations prévues pour les commandes suggérées par l’IA.

Cette distinction change la défense. Relire README.md, package.json ou les instructions destinées à l’agent reste utile, mais ne suffit pas. La surface à examiner comprend aussi les métadonnées et fichiers de configuration que les outils utilisent avant même de présenter le projet. Un dossier de développement est donc un ensemble actif, pas seulement une collection de fichiers source à lire.

Quels transferts présentent le risque documenté

Manifold précise qu’un clone Git classique ne transporte pas la configuration locale .git/config du dépôt source. Le scénario publié exige que le dossier .git arrive déjà avec les fichiers, par exemple dans une archive complète, un répertoire synchronisé, un disque partagé, une sauvegarde, une machine virtuelle ou une clé USB. C’est fréquent lorsqu’un client remet un projet entier à un prestataire ou qu’un collègue partage son dossier de travail pour reproduire un problème.

Cela ne signifie pas qu’un clone depuis Internet est sans risque : le code, les scripts, les hooks installés plus tard et les dépendances peuvent rester dangereux. Cela signifie seulement que le chemin GitSpawn décrit ici repose sur une configuration locale préexistante. Il faut éviter d’étendre l’alerte à tous les dépôts ou d’affirmer qu’un simple téléchargement de code déclenche automatiquement l’attaque.

État des correctifs : une photographie, pas une garantie permanente

Au 1er septembre, Manifold indiquait que Codex, Cursor, Goose et un premier chemin lié à Claude Code avaient été corrigés. Le billet signalait encore des chemins non corrigés dans Hermes Agent, Qwen Code, Grok Build et la fonction ultrareview de Claude Code. La Cloud Security Alliance a repris cette matrice le 3 septembre tout en rappelant qu’elle décrit l’état observé à cette date.

Ne transformez pas cette liste en verdict permanent. Un agent peut recevoir une mise à jour après la publication, et une version corrigée pour core.fsmonitor peut conserver un autre réglage exécutable non traité. Avant d’ouvrir un dossier reçu, vérifiez la version dans le canal officiel de l’outil et les avis de sécurité du fournisseur. Une mise à jour réduit le risque connu ; elle ne remplace pas l’isolation du contenu non fiable.

La procédure de quarantaine en sept étapes

Commencez hors de votre environnement de développement quotidien. N’ouvrez pas l’archive dans votre agent, votre IDE ou un terminal configuré pour analyser automatiquement les dépôts. Copiez-la dans un espace de quarantaine dont l’accès au réseau, aux clés SSH, aux variables cloud, aux gestionnaires de mots de passe et aux autres projets est supprimé ou strictement limité.

Inspectez le contenu comme des données. Utilisez un visualiseur ou un éditeur de texte qui ne lance ni Git, ni tâche de projet, ni extension automatique. Vérifiez si un dossier .git est présent et lisez son fichier config. Un réglage qui désigne un programme, un chemin inattendu ou une commande doit suspendre l’analyse. Ne cherchez pas à “voir ce qui se passe” sur votre poste principal.

1. Identifier l’origine du dossier et le canal de transfert
2. Le placer dans un environnement isolé sans identifiants professionnels
3. Désactiver l’ouverture automatique par l’IDE et les agents
4. Vérifier la présence du dossier .git avec un outil passif
5. Lire .git/config sans lancer de commande Git dans le dépôt
6. Comparer l’origine à un dépôt distant connu ou demander une nouvelle livraison propre
7. Ouvrir avec l’agent seulement après validation et mise à jour de l’outil

Pourquoi safe.directory ne règle pas tout

Git propose safe.directory pour déclarer quels dépôts appartenant à un autre utilisateur peuvent être considérés comme sûrs. Cette protection vise principalement les problèmes de propriété du répertoire. Elle ne constitue pas une validation générale de tous les réglages présents dans la configuration locale d’un dépôt que vous possédez vous-même.

N’ajoutez donc pas un dossier inconnu à une liste de confiance uniquement pour supprimer un avertissement. La confiance doit résulter de l’origine, de l’examen de la configuration et d’une comparaison avec une source attendue. De même, désactiver seulement core.fsmonitor traite le mécanisme le plus expliqué publiquement, mais Manifold indique qu’un autre chemin reposait sur un réglage différent non divulgué tant qu’il restait ouvert.

Cas pratique : un freelance reçoit le projet complet d’un client

Un développeur indépendant reçoit par lien de partage une archive censée reproduire un défaut. Le dossier contient le code, les dépendances déjà installées et l’historique Git. Il pourrait gagner quelques minutes en l’ouvrant immédiatement avec son agent de code, mais son poste contient aussi une clé SSH, des jetons de déploiement et trois autres dépôts clients.

Il crée plutôt une machine virtuelle jetable sans dossier personnel partagé, sans agent connecté à ses comptes et sans secrets. Il ouvre l’archive avec un gestionnaire de fichiers passif, constate la présence de .git, puis lit le fichier config comme du texte. Il demande ensuite au client l’adresse du dépôt officiel et effectue, dans un second environnement propre, un clone authentifié depuis cette source plutôt que de réutiliser les métadonnées reçues.

Le défaut applicatif est reproduit avec des données fictives. Les dépendances sont réinstallées depuis les registres attendus après contrôle du fichier de verrouillage. Ce parcours prend plus de temps au départ, mais il réduit fortement l’impact possible : aucune clé de production, aucun autre client et aucun compte personnel ne se trouve dans le périmètre de l’essai.

Si le dossier a déjà été ouvert

Une ouverture ne prouve pas qu’un code malveillant a été exécuté. Elle justifie toutefois un traitement prudent si le dossier venait d’une source inconnue, contenait un .git complet ou présentait une configuration anormale. Cessez d’utiliser l’environnement pour des opérations sensibles, coupez les accès non indispensables et conservez les éléments utiles à l’analyse au lieu de nettoyer immédiatement les traces.

Inventoriez les secrets accessibles à la session : clés SSH, jetons Git, identifiants cloud, variables d’environnement, cookies et accès aux autres dossiers. Révoquez ou renouvelez en priorité les identifiants réellement exposés depuis un appareil sain, puis examinez les processus, connexions, fichiers créés et journaux avec votre équipe informatique ou un spécialiste. Pour un client, un salarié ou des données personnelles, appliquez aussi la procédure d’incident prévue par l’organisation.

Ne lancez pas un exemple d’exploitation pour confirmer le risque. Traitez l’environnement comme potentiellement exposé, renouvelez les secrets depuis un poste sain et demandez une analyse professionnelle si l’impact peut être important.

Ce que les petites équipes doivent changer durablement

Ajoutez une règle simple à l’accueil des projets : aucun dossier reçu avec ses métadonnées de développement ne s’ouvre directement dans un agent. Désignez une zone de quarantaine, une personne responsable et un mode de livraison préféré. Pour les collaborations régulières, privilégiez un clone authentifié depuis un dépôt connu, avec des droits minimaux et des branches protégées.

Réduisez aussi le rayon d’action de l’agent. Utilisez un compte de travail séparé, un environnement isolé, des clés à courte durée de vie et des secrets injectés seulement quand une tâche en a besoin. Évitez de monter tout le dossier personnel dans un conteneur. Journalisez les actions utiles et gardez l’approbation humaine avant écriture, réseau ou déploiement, même si GitSpawn montre que cette approbation ne couvre pas tous les chemins implicites.

Checklist avant la première analyse

La décision d’ouvrir un projet doit pouvoir être expliquée en une minute : provenance, mode de transfert, présence de métadonnées Git, version de l’agent, environnement utilisé et secrets accessibles. Si l’un de ces points reste inconnu, l’analyse peut attendre ou se faire dans un environnement jetable.

Après validation, commencez en lecture seule et limitez le réseau. Examinez les instructions de projet, scripts de démarrage, tâches d’éditeur, dépendances, sous-modules et configurations d’agents avant d’autoriser une commande. La sécurité ne repose pas sur une case “faire confiance”, mais sur plusieurs barrières indépendantes.

1. Source et propriétaire du dépôt confirmés
2. Agent et extensions mis à jour depuis leurs canaux officiels
3. Aucun secret durable ni autre projet monté dans l’environnement
4. Métadonnées Git inspectées comme du texte
5. Scripts, tâches, dépendances et instructions automatiques repérés
6. Réseau et permissions réduits au strict nécessaire
7. Plan d’arrêt et de renouvellement des secrets disponible

Le bon réflexe à retenir

GitSpawn rappelle qu’un agent de code agit avant et autour du modèle : il lit des configurations, interroge Git, lance des outils et hérite parfois des droits de la session. Les protections visibles dans l’interface ne couvrent pas forcément cette préparation automatique. Il faut donc évaluer le programme complet, pas seulement les réponses générées.

Pour un indépendant ou une TPE, la règle opérationnelle est claire : un projet reçu est non fiable jusqu’à preuve du contraire. Isolez-le, inspectez sa configuration sans l’exécuter, repartez d’une source connue quand c’est possible et n’accordez à l’agent que les accès nécessaires à la tâche. Quelques minutes de quarantaine coûtent moins cher qu’une rotation urgente de toutes les clés.