Cloner un dépôt inconnu, ouvrir le dossier, et voilà qu’un programme se lance sans qu’on ait rien demandé. C’est le scénario décrit dans une divulgation rendue publique le 14 juillet 2026 par Mindgard et relayée par plusieurs médias spécialisés. L’éditeur de code doté d’IA Cursor peut, sur Windows, exécuter un git.exe déposé à la racine d’un projet cloné, avec les droits de l’utilisateur en session.
L’alerte tombe après des mois de signalements privés restés lettre morte. Aucun correctif public, aucun avis de sécurité visible. D’après les éléments publiés, la faille se déclenche dès l’ouverture d’un dépôt malveillant dans Cursor, sans clic supplémentaire ni avertissement. Mindgard affirme avoir prévenu l’éditeur en décembre 2025, retrouvé le problème dans une version testée en avril 2026, puis choisi la publication en juillet.
Points clés
- Cursor sur Windows peut exécuter un git.exe malveillant placé à la racine d’un dépôt cloné, dès l’ouverture du projet
- Mindgard dit avoir prévenu l’éditeur en décembre 2025 ; aucun correctif public ni advisory au 15 juillet 2026
- Contournements conseillés : environnement isolé (VM, Windows Sandbox), blocage des .exe via AppLocker ou WDAC
Un git.exe dans le dépôt, et Cursor le lance
Le mécanisme tient en une phrase. Quand un projet s’ouvre sous Windows, Cursor cherche un exécutable Git, et sa logique de résolution inclurait aussi le répertoire de travail. Placez un fichier nommé git.exe à la racine du dépôt cloné : l’application le prend pour un binaire système légitime et l’exécute.
Dans la démonstration des chercheurs, le faux git.exe n’était autre que la Calculatrice de Windows renommée. L’ouverture du dépôt suffisait à la lancer. Et tant que le dossier restait ouvert, l’exécutable pouvait être rappelé plusieurs fois.
« Si un attaquant place un git.exe à la racine du dépôt, Cursor le traite comme un binaire système légitime et l’exécute », résume un compte rendu de l’affaire publié le 15 juillet 2026.
Pour un éditeur de code, le risque n’a rien d’abstrait. Cloner un projet inconnu, inspecter un dépôt open source ou ouvrir un test technique relèvent du quotidien. Sur une machine Windows, l’exécution se ferait avec les privilèges de l’utilisateur connecté. Autant dire un tapis rouge.
Sept mois d’attente, puis la publication
Mindgard dit avoir notifié l’éditeur dès décembre 2025, puis relancé. Au 15 juillet 2026, aucun correctif public, aucun numéro de version corrigée et aucun advisory ne figuraient dans les sources consultées. Un porte-parole de Cursor a toutefois indiqué à Dark Reading que l’entreprise travaillait sur le sujet et avait commencé à traiter le problème le 13 juillet 2026, soit la veille de la divulgation. Le calendrier a du sens de l’humour.
La frontière entre les versions testées et une éventuelle réponse produit reste floue. Un article de suivi mentionnait encore le défaut dans Cursor 3.2.16 le 30 avril 2026. La fenêtre d’exposition court donc sur plusieurs mois et des dizaines de versions intermédiaires. Les recherches disponibles évoquent plus de 70 sorties logicielles publiées durant cette période sans correction visible.
Mesures de contournement pour Windows
En attendant une réponse formelle, les recommandations convergent vers le confinement. Ouvrir les dépôts non fiables dans une machine virtuelle, Windows Sandbox ou un environnement isolé limite la casse. En entreprise, AppLocker ou Windows Defender Application Control peuvent bloquer l’exécution de binaires depuis les répertoires de travail.
- ouvrir les dépôts inconnus dans un environnement isolé ;
- bloquer l’exécution de fichiers
.exedans les espaces de travail ; - ne jamais considérer comme sûr un binaire trouvé dans un dépôt cloné ;
- surveiller les annonces officielles de Cursor pour un correctif ou un advisory.
