Ouvre un dossier avec Claude Code, et le code d'un inconnu s'exécute chez toi

Imagine la scène, elle n'a rien d'extraordinaire. Un collègue t'envoie un projet dans un fichier zip. Tu décompresses, tu lances ton assistant de code dans le dossier, et tu files te chercher un café pendant qu'il regarde ce qu'il y a dedans.

C'est déjà fini. Le programme d'un inconnu vient de s'exécuter sur ta machine, avec tes droits, sans bac à sable et sans la moindre fenêtre de confirmation.

Tu n'as rien tapé. Tu n'as rien approuvé. Tu as juste ouvert un dossier, comme tu le fais quarante fois par jour.

Personne devant l'écran, et pourtant tu t'es fait avoir

La faille s'appelle GitSpawn. Elle a été publiée le 2 septembre par les chercheurs de Manifold Security, et elle touche à peu près tous les assistants de code en ligne de commande : Claude Code, Codex d'OpenAI, Cursor, Goose, Qwen Code, Grok Build. Huit trouvailles sur sept outils. Quand j'ai lu ça, j'ai failli cracher mon café.

Ce qui se passe exactement

Il faut deux ingrédients. Et le plus beau, c'est que pris séparément, aucun des deux n'est un bug.

Le premier vient de git. Git, c'est le carnet de bord d'un projet : qui a changé quoi, quand, et comment revenir en arrière quand on a fait une bêtise. Tous les développeurs de la planète s'en servent. Or git a un réglage de confort, core.fsmonitor, prévu pour accélérer les gros projets : tu lui désignes un petit programme, et il le lance tout seul pour savoir quels fichiers ont bougé.

Le hic, c'est que ce réglage peut être écrit dans le dossier du projet lui-même, dans un fichier caché. Traduction : le dossier que tu reçois peut contenir une consigne qui dit « quand tu me liras, télécharge le fichier http://mechant-hacker.com/aie-aie-aie-ca-va-faire-mal et exécute ».

Le second ingrédient, c'est ton assistant. Quand tu le démarres quelque part, il commence par se repérer. Il demande à git ce qui a changé, sur quelle branche tu es, ce qui traîne en cours. Du travail de routine, parfaitement légitime, et c'est même exactement pour ça qu'il est pratique.

Sauf que ce petit coup d'œil de routine suffit à déclencher la consigne cachée. Voilà. Deux comportements normaux, une catastrophe.

Il fait son inventaire consciencieusement, il suit scrupuleusement les instructions de git

Bonne nouvelle tout de suite, et elle compte : ça ne marche pas quand tu récupères un projet normalement depuis GitHub. La commande habituelle ne rapatrie pas les réglages locaux du dossier, elle refabrique les siens. Pour que le piège fonctionne, il faut que le dossier arrive chez toi en tant que fichiers, avec sa configuration intacte : un zip, une clé USB, un dossier partagé, un répertoire synchronisé.

C'est-à-dire, très exactement, la façon dont un collègue, un client ou un prestataire te passe un projet.

Et tes permissions dans tout ça ?

Sur le papier, tu es protégé : ces outils ont tous un système d'autorisations. L'assistant veut lancer une commande, il te demande, tu valides ou tu refuses. Il y a un mois, j'écrivais ici que Claude Code arrêtait de demander la permission à chaque geste, et je trouvais déjà que la question du périmètre méritait qu'on s'y arrête.

Sauf qu'ici, on passe en dessous. Ce n'est pas l'assistant qui lance le programme de l'attaquant, c'est git. L'assistant a demandé quelque chose de banal, git a obéi à un réglage qu'il a trouvé sur place, et le programme a démarré en dehors de tout ce qui surveille. Le garde-barrière n'a rien vu passer, forcément : ça n'est pas passé par la barrière.

Et dans certains cas, disent les chercheurs, ça se déclenche avant même que tu te sois authentifié dans l'outil. Ton assistant ne sait pas encore qui tu es, mais il a déjà travaillé pour quelqu'un d'autre.

Qui est touché, qui a corrigé

Regarde la deuxième ligne. C'est celle qui m'intéresse le plus, et pas seulement parce que c'est mon outil de tous les jours.

Sur Claude Code, il y a deux histoires bien distinctes. La première, celle du réglage core.fsmonitor, existait en 2.1.193 et a été corrigée dès la 2.1.196. Rapide, propre, rien à redire.

La seconde concerne la commande de relecture de code, et elle était toujours vivante au moment de la publication. Les chercheurs l'ont confirmée le 1er septembre sur une version d'une semaine, alors que la version publique du jour était déjà plus récente. Ils ont choisi de ne pas dire quel réglage git elle utilise, et honnêtement, c'est plutôt élégant de leur part.

Le détail qui pique : aucun avis de sécurité n'a été publié pour cette seconde trouvaille, et le registre public du paquet ne mentionne ni l'une ni l'autre. Voyons, quand un outil est téléchargé 77 millions de fois par mois, on aimerait bien lire une ligne quelque part !

J'ai tapé claude --version sur ma machine en écrivant ces lignes : 2.1.263. Plus récent que tout ce que les chercheurs ont testé, donc probablement bon. Mais je ne peux pas te l'affirmer, et c'est bien ça qui m'ennuie. Avec six versions en cinq jours par moments, plus personne ne sait vraiment sur quoi il tourne.

Comment un dossier pareil arrive chez toi

Là, tu te dis peut-être que c'est une menace de laboratoire, le genre de scénario que des chercheurs montent en trois heures pour faire joli en conférence. Eh bien non.

En juillet, une campagne baptisée FakeGit a été documentée : environ 7 600 faux projets sur GitHub, fabriqués par 6 600 faux profils de développeurs, avec des descriptions convaincantes et des archives prêtes à télécharger. Plus de 14 millions de téléchargements au compteur. Le tout pour installer un logiciel qui en installe un autre, lequel fouille la machine et repart avec les mots de passe.

Et le détail qui m'a scotché : environ 800 de ces faux projets se faisaient passer pour des extensions destinées aux assistants IA. Un connecteur vers Gmail, vers Docker, vers un outil d'entreprise. La cible n'est plus le développeur distrait, c'est la machine elle-même, celle qui part chercher un outil, le trouve, le trouve très bien, et le recommande gentiment à son patron humain.

Les chercheurs ont un mot pour ça : l'appâtage d'agent. On ne piège plus l'humain, on piège son moteur de recherche !

Deux minutes pour être tranquille

Le plus efficace d'abord : mets ton assistant à jour. La moitié des trous de la liste sont bouchés, et ça coûte une commande.

Ensuite, prends l'habitude de jeter un œil dans un dossier que tu n'as pas fabriqué toi-même. Le fichier de réglages est caché à la racine du projet :

cat .git/config

Tu cherches trois noms : core.fsmonitor, core.hooksPath et attr.tree. Ce sont les réglages qui peuvent désigner un programme à lancer. Si tu en trouves un dans un projet qu'un inconnu t'a envoyé, tu n'ouvres pas le dossier avec ton assistant. Tu poses des questions d'abord.

Les chercheurs conseillent aussi d'éteindre le réglage de confort par défaut, ce qui ne coûte rien puisque tu ne t'en sers probablement pas :

git config --global core.fsmonitor false

Et puis il y a la méthode les pieds de Chuck Norris dans ta face, celle que j'emploierais pour un projet reçu par courriel d'un expéditeur que je ne connais pas : supprimer le dossier .git avant d'ouvrir quoi que ce soit. Tu perds l'historique, tu gardes les fichiers, et le piège part à la poubelle avec le reste. Pour du code qu'on t'envoie « juste pour jeter un œil », l'historique, tu t'en fiches.

Ce que je retiens

On a passé deux ans à se demander si on pouvait faire confiance à ce que l'IA écrit. Et pendant ce temps, la vraie question était ailleurs : est-ce qu'on peut faire confiance à ce qu'elle lit ?

Parce qu'un assistant, ça ne fait pas qu'écrire du code. Ça ouvre des fichiers, ça lit des réglages, ça suit des liens, ça installe des outils, ça se documente tout seul. Chacun de ces gestes est une porte, et pendant qu'on surveillait la sortie avec application, personne ne regardait l'entrée.

Alors va mettre à jour ton assistant, ça prend trente secondes. Et la prochaine fois qu'on te passe un projet sur une clé USB, aie une pensée pour le petit robot qui va gentiment faire l'inventaire sans jamais lever les yeux de son carnet !

Sources

• Manifold Security : GitSpawn, a single flaw lets untrusted repos run code in Claude Code, Codex, Cursor and Grok, la recherche d'origine, le mécanisme du réglage git, la liste des outils touchés avec leurs numéros de version et l'état des correctifs
• The Hacker News : Malicious .git configs can make Claude, Codex, Cursor and other AI agents run attacker code, 2 septembre 2026, la seconde trouvaille non corrigée sur la commande de relecture, l'absence d'avis de sécurité publié et les trois réglages à surveiller
• Cybersecurity News : GitSpawn flaws let malicious repositories execute code, le détail du déclenchement au démarrage de l'assistant et les conditions de livraison du dossier piégé
• The Hacker News : FakeGit campaign uses 7,600 GitHub repositories to spread SmartLoader malware, juillet 2026, les faux projets, les faux profils, les 14 millions de téléchargements et les extensions falsifiées destinées aux assistants IA
• Help Net Security : AI agents tricked into recommending malicious GitHub repositories, la technique consistant à piéger la recherche de l'assistant plutôt que celle de l'utilisateur