Ouvrir le projet suffit : huit agents de codage par IA ont exécuté la commande d'un attaquant sans rien demander

Nous avons l'habitude de lire l'IA et la cybersécurité sous un seul angle : un attaquant qui manie des agents pour aller plus vite. Le second angle compte davantage pour votre organisation et reçoit beaucoup moins d'attention. L'agent que vous faites tourner sur la machine de votre propre développeur est lui-même une nouvelle surface d'attaque. En deux mois, trois groupes de recherche indépendants ont publié des résultats qui pointent tous dans la même direction.

Ce que ces cas ont en commun n'est pas un défaut du modèle ni une mauvaise réponse. L'agent n'est jamais sorti de son bac à sable et n'a jamais violé une règle. Ce qui s'est produit, c'est que l'agent a lu ou écrit un fichier à l'intérieur du projet, puis qu'un outil de confiance tournant en dehors du bac à sable a exécuté le contenu de ce fichier. Le bac à sable a tenu. La compromission l'a contourné.

Le mécanisme : un réglage de performance de Git vieux de plusieurs années

L'exemple le plus clair a été publié par Manifold Security le 2 septembre 2026 sous le nom de GitSpawn. Il repose sur un réglage Git propre à chaque projet, appelé core.fsmonitor, une option de performance légitime et documentée dont la valeur est une commande que Git exécute pour identifier rapidement les fichiers modifiés au lieu de parcourir tout le répertoire.

Assemblez maintenant les deux moitiés :

• Un agent de codage par IA, quand il commence à travailler sur un projet, exécute automatiquement des commandes Git comme git status et git diff pour comprendre l'état du dépôt. C'est un comportement normal et nécessaire.
• Si le dépôt porte une valeur core.fsmonitor malveillante, le simple fait d'exécuter ces commandes exécute la commande de l'attaquant.

Le résultat, c'est qu'ouvrir un dépôt de code cesse d'être un événement de lecture pour devenir un événement d'exécution. Aucun clic, aucune approbation, aucune invite affichée au développeur. Selon le rapport, huit agents en ligne de commande étaient exposés, et des correctifs ont suivi pour plusieurs d'entre eux : goose en 1.44.0, Claude Code en 2.1.196 pour le chemin core.fsmonitor, Codex CLI en 0.131.0, ainsi que Cursor. Le rapport signalait quatre chemins encore non corrigés à la publication. Cette classe a été suivie sous plusieurs identifiants, dont CVE-2026-72718, CVE-2026-19592 et CVE-2026-55607.

Non pas un incident mais toute une classe

Six semaines avant GitSpawn, les chercheurs de Pillar Security ont publié le 20 juillet 2026 une série qu'ils ont appelée une semaine d'évasions de bac à sable, documentant sept vulnérabilités réparties sur quatre agents de codage de trois éditeurs : Cursor, Codex, Gemini CLI et Antigravity. Leur description du mécanisme mérite une seconde lecture. L'agent reste dans la boîte et respecte chaque règle. Il écrit simplement un fichier qu'un outil de confiance, hors de la boîte, exécute, charge ou analyse ensuite.

• Dans Cursor, un fichier de configuration de hooks contrôlé par l'espace de travail permettait une exécution en dehors du bac à sable, suivi sous CVE-2026-48124 et corrigé dans la version 3.0.0.
• Dans Codex CLI, la liste d'autorisation des commandes faisait confiance à git show sur son seul nom, alors que les paramètres qui lui sont passés peuvent en faire plus qu'un simple outil de lecture. Corrigé dans la version 0.95.0.
• Un problème de socket Docker touchait en même temps Codex, Cursor et Gemini CLI.
• Dans Antigravity, un contournement de la liste de refus Seatbelt sur macOS et un problème de configuration des tâches de l'éditeur, que Google a tous deux classés comme difficiles à exploiter.

Puis, le 10 septembre 2026, Upstarts Media a rapporté une troisième divulgation, venue d'une startup nommée Accomplish, portant sur des bacs à sable poreux dans Claude Code, Codex et Cursor. Le chiffre intéressant ici n'est pas la vulnérabilité mais le délai de correction : le problème de Cursor a été résolu en une semaine environ, deux problèmes d'OpenAI en août, tandis que celui d'Anthropic a pris une cinquantaine de jours, sur des dizaines de versions. Trois groupes de recherche, trois rapports, deux mois, un seul schéma.

Pourquoi cela vous concerne même si vous n'écrivez jamais de code

Parce que le risque ne retombe pas sur l'agent. Il retombe sur la machine qui le fait tourner et sur le réseau où se trouve cette machine. Un poste de développement est l'un des appareils les plus privilégiés d'une entreprise : il détient des clés d'accès aux serveurs, des jetons de déploiement, et souvent une connexion ouverte à une base de données de production. Exécuter une seule commande dessus n'est pas un petit événement.

Le scénario n'est pas théorique sur le marché saoudien. Confrontez ces cas à votre propre entreprise :

• Un prestataire externe ou une agence de développement vous livre du code que votre équipe ouvre ensuite avec un agent IA, sur une machine située dans votre réseau.
• Un projet open source qu'un développeur télécharge pour essayer une bibliothèque ou appliquer une correction rapide.
• Un fichier envoyé par e-mail ou par WhatsApp par un fournisseur, décompressé et ouvert directement dans l'éditeur.
• Un candidat à un poste qui remet un projet d'exemple qu'un relecteur technique ouvre.
• Une vieille branche ou un dépôt transféré remis lors d'une acquisition ou d'une passation de projet.

Dans chacun de ces cas, l'hypothèse tacite est qu'ouvrir des fichiers pour les lire est un acte sans danger. C'est cette hypothèse qui a cassé.

Ce qu'il faut faire cette semaine

Cinq étapes, et la première n'exige aucun budget :

1. Mettez à jour l'outillage des agents dans toute l'équipe aujourd'hui. Des correctifs existent pour la plupart de ces outils, et la valeur vient de ce que tout le monde soit sur une version corrigée, et non une seule personne. Commencez par savoir qui utilise quoi et dans quelle version, car cet inventaire lui-même manque généralement.
2. Traitez le code entrant comme un contenu non fiable. Le code d'un prestataire ou d'une source open source n'est pas un document que vous lisez, c'est quelque chose qui s'exécute. Ouvrez-le la première fois sur une machine ou un conteneur séparé du réseau de travail.
3. Séparez la machine de développement des clés de production. Ne conservez pas de jetons de serveurs en production sur la machine où l'on ouvre des projets d'origine externe. La perte reste alors circonscrite à cet appareil.
4. Faites passer le déploiement par un pipeline central, pas par un portable personnel. Quand le déploiement passe par un seul pipeline de build aux permissions restreintes, compromettre une machine cesse d'être un chemin vers la production.
5. Ajoutez une clause aux contrats de développement externalisé. Vous êtes en droit de préciser comment le code est livré et depuis quel dépôt, et d'exiger du prestataire qu'il maintienne son outillage à jour. C'est une clause contractuelle, pas un débat technique.

Localement, rien de tout cela ne relève de la bonne pratique optionnelle. Les Contrôles essentiels de cybersécurité publiés par l'Autorité nationale de cybersécurité (NCA) comportent des domaines explicites pour la sécurité des postes de travail, la sécurité de la gestion des changements et du développement, et la sécurité des tiers, tandis que la responsabilité de la protection des données personnelles reste celle de l'organisation au titre de la loi sur la protection des données personnelles (PDPL). Si la porte s'est ouverte par la machine d'un développeur qui a ouvert le projet d'un prestataire, cela ne réduit pas la responsabilité.

Le regard d'Origami

Nous lisons ces trois rapports comme une correction apportée à une idée qui s'est répandue vite : qu'un bac à sable suffit tant que l'agent y est enfermé. Ces vulnérabilités n'ont pas brisé l'isolation. Elles ont emprunté un pont légitime qui transporte vers un outil tournant à l'extérieur quelque chose écrit à l'intérieur de la boîte. Ce qui veut dire que la bonne question n'est pas de savoir si l'agent est en bac à sable, mais quels outils lisent ce que l'agent produit, et avec quels privilèges ces outils tournent.

Une observation pratique tirée de ce que nous voyons chez nos clients : l'adoption de l'outillage d'IA au sein des équipes de développement a des mois d'avance sur la moindre politique qui l'encadre. Un développeur essaie un outil, l'apprécie, et l'outil devient partie du flux de travail quotidien sans décision, sans revue et sans inventaire. Le problème n'est pas l'outil. Le problème, c'est qu'il est entré par une porte que personne ne surveille. Lorsque nous auditons les environnements de nos clients, nous commençons exactement ici : quels outils tournent réellement sur les machines de l'équipe, avec quels privilèges, et que se passe-t-il si une commande s'exécute sur l'une d'elles ce soir. Si vous voulez un audit sous cet angle, vous nous trouverez sur la page de contact.

L'essentiel

Trois divulgations indépendantes en deux mois disent la même chose : un agent de codage par IA transforme l'ouverture d'un projet d'une lecture en une exécution, et il suffit qu'un tiers place une seule ligne dans un fichier de configuration. Des correctifs sont sortis pour la plupart des outils et certains chemins sont restés ouverts, mais la leçon survit à toutes les versions. Tout outil que vous faites tourner sur une machine fortement privilégiée fait partie de votre surface d'attaque, que vos politiques le mentionnent ou non. Commencez par une question : qui, dans votre équipe, fait tourner un agent IA en ce moment, sur quelle machine, et dans quelle version ?

Sources

• The Hacker News — Des configurations .git malveillantes peuvent faire exécuter le code d'un attaquant par Claude, Codex, Cursor et d'autres agents IA, 2 septembre 2026 : la divulgation GitSpawn de Manifold Security, le mécanisme core.fsmonitor, la liste des huit agents, les versions correctives et les identifiants CVE-2026-72718, CVE-2026-19592 et CVE-2026-55607.
• BleepingComputer — Cursor, Codex, Gemini CLI et Antigravity touchés par des évasions de bac à sable : la série de Pillar Security publiée le 20 juillet 2026, sept vulnérabilités sur quatre agents, CVE-2026-48124 et les correctifs 3.0.0 et 0.95.0.
• Upstarts Media — Claude Code, Codex et Cursor ont des problèmes de bacs à sable poreux, 10 septembre 2026 : la divulgation d'Accomplish et les délais de correction chez les trois éditeurs.
• Autorité nationale de cybersécurité — Contrôles essentiels de cybersécurité, et Autorité saoudienne des données et de l'intelligence artificielle — loi sur la protection des données personnelles.