Une faille laisse un dépôt piégé exécuter du code chez Claude Code, Codex et Cursor : n'ouvre plus n'importe quel dossier

Ce qui s’est passé

Le 1er septembre, la société de sécurité Manifold Security a publié les détails d’une faille qu’elle a baptisée GitSpawn. Elle touche la plupart des agents de code assistés par IA : Claude Code, Codex d’OpenAI, Cursor, Grok Build, Qwen Code et quelques autres.

Le mécanisme est simple, et c’est ce qui le rend dangereux. Quand tu ouvres un dossier de code, ton agent lance automatiquement quelques commandes git — git status, git diff — pour comprendre où il met les pieds. Or un dépôt git contient un fichier de configuration qui peut désigner un programme d’aide à exécuter pendant ces opérations. Git fait ce qu’on lui dit : il lance le programme. Sur ta machine, avec tes droits, avant que l’agent ne te demande quoi que ce soit.

Résultat : un attaquant obtient l’exécution de code arbitraire, hors du bac à sable, sans aucune validation. Concrètement, il accède à tes clés SSH, à tes identifiants cloud, à tes jetons de session et à l’ensemble des dépôts présents sur ton disque.

Point important : le dépôt piégé n’a pas besoin d’être cloné depuis GitHub. Le scénario le plus réaliste, c’est un fichier zip qu’on te transmet — un « regarde mon projet », un template récupéré quelque part, un test technique envoyé par un client.

Ce que ça veut dire

Au 1er septembre, Claude Code (2.1.196), Codex, Cursor et Goose sont corrigés sur la variante principale. Mais Manifold indique que d’autres restent vulnérables au moment de la publication : Grok Build, Qwen Code, Hermes Agent, et une seconde variante de Claude Code.

La leçon dépasse cette faille précise. On a pris l’habitude de traiter un agent de code comme un assistant inoffensif qui « lit » un projet. Ce n’est pas ce qu’il fait. Il exécute des commandes, dans ton environnement, avec tes droits, dès la première seconde. Ouvrir un dossier n’est plus un geste neutre.

C’est le même angle mort que pour n’importe quelle délégation à une IA : on regarde ce que l’outil produit, rarement ce qu’il a le droit de faire pendant qu’il travaille — c’est le premier point de la checklist avant de confier une tâche à un agent.

Ce que tu fais lundi matin

Mets tes agents à jour. C’est le geste qui règle 80 % du problème. Profites-en pour faire le tour de ta stack IA : les outils que tu n’ouvres plus sont aussi des surfaces d’attaque que tu ne surveilles plus. Vérifie ta version de Claude Code (2.1.196 minimum), de Cursor et de Codex.

Change ton réflexe d’ouverture. Un dossier de code qui ne vient pas de toi ou d’un dépôt que tu connais ne s’ouvre pas dans ton environnement de travail. Ni un zip reçu par mail, ni un template téléchargé sur un site inconnu, ni le rendu d’un test technique.

Si tu dois vraiment inspecter du code inconnu, fais-le dans un environnement jetable — une machine virtuelle, un conteneur, un espace de dev en ligne. Le principe est le même que pour une pièce jointe douteuse : on ne l’ouvre pas sur la machine où vivent ses clés.

Fais l’inventaire de ce qui traîne sur ton disque. Si tes clés SSH et tes identifiants cloud sont accessibles en clair depuis n’importe quel dossier, la faille suivante te coûtera la même chose — et les capacités offensives des modèles progressent vite.

Le piège à éviter

Le piège serait de conclure « les agents de code sont dangereux, je n’en utilise plus ». Ce n’est ni réaliste ni proportionné : la faille est corrigée sur les outils les plus utilisés, et le vecteur suppose que tu ouvres un dossier qu’on t’a envoyé.

Le vrai piège est inverse, et plus insidieux : considérer qu’un outil qui te demande confirmation avant d’agir est un outil qui ne fait rien sans confirmation. GitSpawn démontre le contraire — l’exécution avait lieu avant le prompt de validation. La demande d’autorisation n’est pas une barrière technique, c’est une couche de confort. Ce qui protège, c’est de savoir ce que l’outil lance au démarrage, et de ne pas lui donner à manger n’importe quoi.