7 failles de sandbox frappent Cursor, Codex, Gemini CLI et Antigravity

Le 20 juillet 2026, le cabinet de recherche Pillar Security a publié « The Week of Sandbox Escapes », une série de rapports qui documente sept failles d'évasion de sandbox reproduites chez quatre éditeurs d'agents de code IA : Cursor, Codex d'OpenAI, Gemini CLI de Google et Antigravity de Google. Dans la quasi-totalité des cas, l'agent n'a même pas eu besoin de casser le sandbox de front. Il lui a suffi d'écrire un fichier qu'un composant de confiance, situé hors du sandbox, allait ensuite exécuter, charger ou scanner.

Un agent de code IA tourne en général dans un environnement restreint censé l'empêcher de toucher au reste de votre machine pendant qu'il lit vos README, vos issues, vos dépendances ou du contenu web pour agir à votre place. Le postulat implicite est simple : ce que l'agent écrit dans le dossier de travail reste dans le dossier de travail. Les travaux de Pillar Security montrent que ce postulat ne tient pas.

Trois couches, et une frontière qui fuit

Les chercheurs découpent la frontière d'un sandbox en trois couches. La première, c'est ce que le processus de l'agent peut exécuter directement. La deuxième, ce qu'il peut écrire dans l'espace de travail. La troisième, ce que des composants non sandboxés font ensuite de ces fichiers : découverte d'interpréteurs Python, scan de dépôt Git, moteur de tâches de l'IDE, moteur de hooks, ou encore un socket Docker local exposé.

C'est cette troisième couche qui casse tout. Un agent peut respecter chaque règle qu'on lui donne et quand même façonner les entrées d'un composant de confiance qui, lui, n'est pas sandboxé. Croire que « l'agent ne peut écrire que dans le projet » revient à croire que « l'agent ne peut donc pas affecter la machine ». Sur un poste de développeur, les fichiers de configuration d'un projet sont, la plupart du temps, de l'infrastructure exécutable.

Quatre modes de défaillance qui se répètent

Pillar Security regroupe ses sept cas en quatre familles de problèmes :

• Les sandbox en liste noire ne suivent pas la complexité de l'OS. Un profil qui part du principe « tout est autorisé sauf ce qui est explicitement bloqué » doit se souvenir de chaque service local, chaque type de montage, chaque chemin de lancement dangereux qu'expose le système. Un agent, contrairement à un attaquant humain pressé, peut tester, écrire, retenter et combiner des fonctionnalités que la politique statique n'avait pas anticipées.
• La configuration de workspace est souvent du code. Un agent qui écrit un fichier qu'il a le droit d'écrire ne casse aucune règle. Le problème apparaît quand un composant non sandboxé traite ensuite ce fichier comme une configuration de confiance : interpréteur virtualenv, configuration Git, helper fsmonitor, tâche VSCode, hook.
• Les allowlists de commandes « sûres » se fient au nom, pas à l'invocation. Une commande peut sembler inoffensive par son nom (une lecture Git, par exemple) sans que l'allowlist modélise les arguments dangereux ni les effets de bord réels de la commande.
• Les démons locaux privilégiés vivent hors du sandbox. Un socket Docker local accessible depuis un agent restreint devient, de fait, un environnement d'exécution non sandboxé.

Les sept cas documentés

Concrètement, voici ce que Pillar Security a trouvé et fait corriger ou reclasser :

• Antigravity, profil macOS Seatbelt. Une liste noire laissait des fonctionnalités système accessibles, permettant une exécution hors du sandbox. Google a reclassé le rapport en vulnérabilité de sévérité réduite, jugeant l'exploitation difficile hors ingénierie sociale ou dépôt malveillant.
• Codex, Cursor et Gemini CLI, socket Docker. Un socket Docker local privilégié était atteignable depuis des agents restreints et devenait un environnement d'exécution non sandboxé. Corrigé, publication de sécurité référencée GHSA-v4xv-rqh3-w9mc.
• Cursor, interpréteur virtualenv. L'agent pouvait modifier l'interpréteur d'un environnement virtuel Python que l'extension Python non sandboxée de l'éditeur exécutait ensuite lors de sa phase de découverte. Corrigé, référencé GHSA-p9g2-cr55-cw9c.
• Cursor, répertoire Git détourné. Un répertoire de métadonnées Git au nom modifié passait au travers des règles de sandbox basées sur les chemins, et l'extension Git déclenchait une exécution via le helper fsmonitor. Corrigé en version 3.0.0.
• Codex CLI, allowlist de commandes. Une allowlist de commandes sûres faisait confiance au nom d'une commande Git sans modéliser ses effets de bord dangereux, ouvrant la voie à une exécution de code à distance. Corrigé en version 0.95.0, avec une prime de bug bounty en sévérité haute.
• Cursor, hook de workspace. Une configuration de hook présente dans l'espace de travail se transformait en exécution de commande non sandboxée. Corrigé en version 3.0.0, référencé CVE-2026-48124 et GHSA-pc9j-3qc2-95wv.
• Antigravity, tâche VSCode. L'agent pouvait écrire une configuration de tâche VSCode que l'hôte exécutait ensuite de lui-même, contournant le mode sécurisé de l'outil. Là aussi, Google a reclassé le rapport en vulnérabilité de sévérité réduite.

Ce que ça change pour vous, concrètement

Si vous ou votre équipe utilisez un agent de code IA au quotidien, quatre réflexes limitent l'exposition réelle :

• Mettez à jour sans attendre. Cursor 3.0.0 et Codex CLI 0.95.0 corrigent plusieurs des cas ci-dessus. Une vérification de version prend trente secondes et ferme des chemins d'attaque déjà documentés publiquement.
• Ne traitez pas le sandbox comme un mur absolu. Avant de laisser un agent travailler sans supervision sur un dépôt que vous n'avez pas écrit vous-même, demandez-vous quels composants non sandboxés de votre IDE ou de votre CLI vont lire les fichiers qu'il produit : extension Python, intégration Git, moteur de tâches, moteur de hooks.
• Relisez les fichiers de configuration de projet avant de faire confiance à un dépôt cloné. Un fichier .vscode/tasks.json, une configuration de hook, un fichier de config Git modifié sont désormais des vecteurs d'exécution potentiels, au même titre qu'un script shell.
• Limitez l'exposition des démons locaux privilégiés, en particulier le socket Docker, aux processus qui en ont réellement besoin. Un agent restreint qui atteint ce socket retrouve, de fait, des droits d'exécution complets sur la machine.

Notre lecture chez CZSyn

Ce que montre ce travail de Pillar Security, c'est que la sécurité des agents de code IA ne se résume pas à la robustesse du bac à sable du processus. Le vrai périmètre de risque, c'est tout ce que l'agent peut écrire et que l'hôte, lui, exécute ensuite sans y regarder à deux fois. C'est un changement de modèle de menace pour le poste de développeur, pas un simple bug ponctuel à corriger.

Pour une PME ou une équipe dev qui adopte ces outils, le vrai enjeu de gouvernance n'est pas de choisir entre sécurité et productivité. Les gains de productivité des agents sont réels et déjà largement adoptés. Le problème, c'est que ces outils sont devenus une brique d'infrastructure avant que la plupart des organisations ne les gouvernent comme telle : accès aux clés SSH, aux jetons cloud, aux sessions de navigateur, aux droits de publication de paquets, souvent regroupés sur le même poste. Nous recommandons à nos clients de traiter chaque agent de code IA comme un acteur endpoint à part entière : inventaire des outils utilisés, suivi des correctifs de sécurité publiés par chaque éditeur, et prudence particulière sur les dépôts externes ou peu maîtrisés avant d'y lâcher un agent en mode autonome.

Rien ici ne remet en cause l'intérêt de ces outils. Cela dit qu'ils méritent la même discipline qu'un serveur exposé sur internet : mise à jour, surveillance, et un peu de scepticisme sur ce qu'on leur laisse faire sans supervision.

Sources primaires

• Pillar Security, « The Week of Sandbox Escapes », 20 juillet 2026.
• GitHub Security Advisory, GHSA-v4xv-rqh3-w9mc, faille du socket Docker.
• GitHub Security Advisory, GHSA-pc9j-3qc2-95wv, référencée CVE-2026-48124, faille du hook de workspace Cursor.