Contexte technique
Je vois rarement une faille aussi terre-à-terre et pourtant désagréable : Cursor sous Windows peut lancer tout seul un git.exe malveillant s’il se trouve à la racine d’un dépôt ouvert. Sans clic, sans injection de prompt, sans belles attaques IA. On ouvre le dossier et c’est parti.
C’est sur ce genre d’histoires que je juge habituellement la maturité de l’implémentation de l’IA dans une entreprise. Si un outil de développement casse parce qu’il cherche un binaire dans l’espace de travail, le problème n’est plus dans le modèle ni dans l’agent, mais dans l’hygiène de base du produit.
D’après Mindgard, la racine du bug se trouve dans la logique de recherche de Git : Cursor examine plusieurs chemins et attrape un exécutable directement dans le répertoire du projet. Il en résulte une exécution de code arbitraire avec les droits de l’utilisateur courant. La démo était presque moqueuse : ils ont renommé la calculatrice en git.exe et Cursor l’a lancée en silence.
Ce qui m’a frappé, ce n’est pas seulement l’exécution de code, mais le silence autour. Aucun avertissement, aucune confirmation, pas même une indication que l’IDE manipule un binaire provenant d’un dépôt non fiable.
L’histoire est encore pire à cause du timing. Mindgard indique avoir envoyé le rapport le 15 décembre 2025, puis relancé à plusieurs reprises, y compris via HackerOne, et la vulnérabilité restait reproductible au moins dans la version 3.2.16 vérifiée le 30 avril 2026. Si ces chiffres sont exacts, cela représente plus de six mois et plus de 197 versions sans correctif.
Au moment présent, le 15 juillet 2026, la nouvelle n’est plus fraîche au sens de « tout juste découverte », mais plutôt une analyse éclairante de la façon dont la divulgation complète devient la dernière défense quand l’éditeur traîne. Cursor a déclaré à Dark Reading qu’ils « traitent » le problème, mais la divulgation publique en dit déjà long sur le processus de réaction.
Ce que cela change pour l’entreprise et l’automatisation
Les perdants sont les équipes qui ouvrent des dépôts externes sur les postes Windows de production des développeurs sans isolation. Les gagnants sont ceux qui ont depuis longtemps séparé les environnements de confiance des autres et maintiennent l’automatisation IA et les outils de dev à l’intérieur de périmètres de politiques.
Ma conclusion pratique est simple : tous les IDE et agents IA doivent être inclus dans le même modèle de menace que le navigateur, la messagerie et le client RDP. Si un développeur tire du code de l’extérieur, il lui faut un bac à sable, et sous Windows au moins AppLocker ou Windows App Control.
Et oui, cela ne touche pas seulement la sécurité, mais aussi l’architecture des processus. Je reverrais où réside exactement votre intégration IA pour le développement, qui a le droit d’ouvrir des projets externes en local et quels binaires peuvent démarrer depuis l’espace de travail.
Si votre équipe est déjà liée à Cursor, Copilot, aux agents et aux outils internes, je n’attendrais pas la prochaine histoire du même genre. Chez Nahornyi AI Lab, nous aidons précisément à construire l’automatisation IA et les garde-fous pour que les développeurs ne perdent pas en vitesse et que l’entreprise ne paie pas pour un dossier malencontreusement ouvert. Si vous le souhaitez, analysons ensemble votre périmètre et mettons en place une architecture solide sans magie superflue.