La version bruyante dit: “un 0-day dans un éditeur IA exécute du code tout seul”. La version utile est plus sobre. Mindgard affirme que Cursor sur Windows peut lancer un git.exe placé à la racine d’un dépôt ouvert pendant la recherche de Git. Cursor répond que le risque est étroit et relève de la responsabilité partagée pour les entrées non fiables du workspace. La leçon pratique: ouvrir un dépôt inconnu dans un outil de développement assisté par IA n’est plus une action totalement passive.

Poste de développement avec exécutable suspect isolé des secrets protégés

Dans la preuve de concept de Mindgard, Windows Calculator a été renommé git.exe, placé à la racine du dépôt, puis lancé lors de l’ouverture du projet dans Cursor. Ce n’est pas une prompt injection, ni une preuve que tous les utilisateurs sont compromis, ni une confirmation pour macOS ou Linux. Les préconditions comptent: Windows, Cursor, un exécutable nommé exactement git.exe et un chargement de projet qui déclenche la découverte de Git.

Ce qui est allégué

Mindgard dit que Cursor teste plusieurs emplacements pour trouver Git et peut exécuter le binaire du workspace. Cyber Security News a cité des logs Process Monitor montrant Cursor.exe lançant le binaire avec git rev-parse --show-toplevel. The Hacker News ajoute une limite: le document public ne prouve pas si Cursor cherche explicitement ce chemin ou transmet un git sans chemin complet à Windows, qui applique alors son ordre de recherche.

Pour la défense, le problème reste le même: un fichier du projet passe de “lu” à “exécuté” avant une décision de confiance explicite. C’est une vieille classe — untrusted search path / current-directory executable resolution — dans un contexte moderne: les IDE avec agents IA lisent, lancent et modifient davantage de choses.

Limite importante: The Hacker News indique que la dernière confirmation datée de Mindgard portait sur Cursor 3.2.16 le 30 avril, alors que la version courante mentionnée était 3.11 du 10 juillet. Aucun advisory Cursor ni CVE spécifique à ce git.exe racine n’a été trouvé lors de cette vérification. Les équipes doivent donc vérifier leur version et suivre changelog et advisories.

La réponse de Cursor

Cursor a classé le rapport hors périmètre bug bounty, sous un modèle de responsabilité partagée: les clients choisissent les dépôts, prompts, serveurs MCP, règles et outils introduits; Cursor fournit des contrôles pour cette frontière. La société parle d’un risque Windows uniquement, limité à un dossier contenant un git.exe malveillant à la racine, et renvoie vers Workspace Trust / restricted mode. Elle reconnaît aussi un défaut de processus dans la communication avec le chercheur.

Cette position n’est pas absurde, mais la responsabilité partagée ne supprime pas la responsabilité produit. “J’ouvre un dossier pour lire du code” n’est pas “j’autorise l’exécution d’un binaire de ce dossier”. Plus l’IDE automatise, plus la frontière lecture/exécution doit être visible.

Pourquoi cela compte

Le débat Hacker News était prévisible. Certains rappellent que les exécutables malveillants dans un dépôt sont déjà dangereux sous Windows. D’autres répondent que cloner et ouvrir des dépôts est une activité normale pour mainteneurs, reviewers et équipes sécurité. La différence entre exécuter soi-même une commande et voir l’éditeur lancer quelque chose à l’ouverture est précisément la frontière de confiance.

Aucune exploitation active n’a été confirmée dans les sources consultées. Cela réduit l’urgence, pas l’intérêt des contrôles.

Ne pas confondre avec DuneSlide

DuneSlide, CVE-2026-50548 et CVE-2026-50549, est une autre histoire: prompt injection, sandbox escape, corrigé dans Cursor 3.0 selon The Hacker News. Le cas Mindgard git.exe concerne la résolution locale d’un exécutable pendant le chargement du projet.

Que faire

Mettez Cursor à jour et suivez les notes officielles. Activez Workspace Trust ou restricted mode pour les dossiers inconnus. Ouvrez les dépôts non fiables dans Windows Sandbox, une VM, un devcontainer ou un environnement cloud jetable. Inspectez la racine avant une IDE puissante: exécutables, scripts .cmd/.ps1, hooks, tasks et wrappers inattendus.

Côté équipes, imposez une règle praticable: dépôts inconnus isolés, secrets de production hors sessions de développement générales, agents sans privilèges cloud larges. Sur Windows, AppLocker ou Windows Defender Application Control par chemins de workspace peuvent aider, après pilote. Une EDR peut alerter quand Cursor.exe lance un binaire depuis un dépôt.

La leçon

Ce n’est pas une raison de paniquer sur Cursor. C’est une raison de considérer le poste développeur comme surface d’attaque. Les dépôts inconnus sont du contenu exécutable jusqu’à preuve du contraire. Les outils IA doivent rendre les frontières de confiance plus explicites.