Zero-day Cursor : pourquoi la divulgation complète est devenue le seul moyen de protection restant

• Sur Windows, Cursor exécute automatiquement le git.exe situé à la racine de l’espace de travail lors de l’ouverture d’un projet, si bien que du code arbitraire peut être exécuté sans interaction de l’utilisateur dès qu’on ouvre un dépôt contenant un binaire malveillant
• Le périmètre de recherche du chemin Git inclut l’intérieur du dépôt, et l’application exécute le fichier sans avertissement ni approbation ; de plus, tant que le projet reste ouvert, elle le relance périodiquement
• Mindgard a signalé le problème le 15 décembre 2025 et est allé jusqu’à la reproduction et la transmission via HackerOne, mais plus de 6 mois et plus de 197 nouvelles versions plus tard, le problème subsistait encore dans la dernière version de test
• Dans les environnements Windows administrés, il faut appliquer des règles de refus basées sur le chemin avec AppLocker ou Windows App Control ; les particuliers, eux, doivent ouvrir les dépôts non fiables dans une VM ou Windows Sandbox jusqu’au correctif
• Estimant qu’une divulgation coordonnée ne permettait pas de réduire le risque pour les utilisateurs, Mindgard a publié tous les détails et souligne que, dans le choix d’un outil de développement IA, la capacité du fournisseur à réagir sur la sécurité et à communiquer doit aussi faire partie des critères de confiance

---

git.exe s’exécute au simple fait d’ouvrir un dépôt

• Lors du chargement d’un projet, Cursor cherche le binaire Git à plusieurs emplacements, et la zone de recherche inclut aussi l’espace de travail courant
• Si un attaquant place un git.exe malveillant à la racine du dépôt, Cursor l’exécute automatiquement sans avertissement, boîte de dialogue de confirmation ni clic supplémentaire
• L’attaque démarre au simple fait qu’un développeur ouvre ce projet, sans nécessiter d’injection de prompt, de manipulation du modèle, de jailbreak, de corruption mémoire ou de chaîne d’exploitation complexe
• Le code exécuté s’exécute avec les droits de l’utilisateur courant de Cursor

Reproduction et traces de relance répétée

• Pour une preuve de concept sans danger, Mindgard a renommé la Calculatrice Windows en git.exe puis l’a placée à la racine du dépôt
• En ouvrant le dépôt dans Cursor, la Calculatrice s’est lancée ; en laissant ensuite le projet ouvert, plusieurs fenêtres supplémentaires sont apparues
  • Le chercheur n’a pas ouvert manuellement ces différentes fenêtres
  • Il ne s’agissait pas d’un comportement de démarrage ponctuel : pendant l’usage normal, l’exécutable de l’espace de travail était relancé périodiquement
• Dans une attaque réelle, l’attaquant pourrait placer à la place de la Calculatrice un code sous son contrôle
• Les journaux de Sysinternals Process Monitor montrent que Cursor.exe a exécuté le git.exe situé dans le dépôt en lui transmettant la commande suivante

git rev-parse --show-toplevel

• La dernière vérification a été effectuée le 30 avril 2026 sur Cursor 3.2.16 pour Windows

Une faille restée présente sur une base d’utilisateurs massive

• Cursor est un environnement de développement assisté par IA utilisé à l’échelle suivante
  • plus de 7 millions d’utilisateurs actifs
  • plus de 1 million d’utilisateurs quotidiens
  • plus de 1 million d’utilisateurs payants
  • plus de 50 000 entreprises clientes
• Sa valorisation rapportée atteint 60 milliards de dollars
• Mindgard a découvert la vulnérabilité le 15 décembre 2025 et l’a signalée le jour même
• Au moment de l’introduction, plus de 6 mois et plus de 197 nouvelles versions plus tard, la vulnérabilité restait présente dans la dernière version de test
• Le corps du récit sur la réponse indique que plus de 70 versions ont été publiées pendant que de nouvelles fonctionnalités et annonces se succédaient, sans que le problème soit résolu
• Cette vulnérabilité simple et facile à reproduire permettant l’exécution de code arbitraire n’a pas été corrigée pendant des mois, affectant à la fois les particuliers et les organisations ayant déployé Cursor

Mesures temporaires applicables avant le correctif

• Sur les systèmes Windows administrés, des politiques AppLocker ou Windows App Control peuvent bloquer ce nom d’exécutable dans les répertoires d’espaces de travail de développement
• Comme le hachage peut varier d’un binaire à l’autre, des règles de refus basées sur le chemin et limitées à la racine des dépôts ou des espaces de travail sont plus adaptées qu’une liste de blocage fondée sur le hachage

%USERPROFILE%\\source\\repos\\*\\filename.exe

• Windows ne propose pas de règle intégrée générale permettant de bloquer un exécutable enfant arbitraire uniquement lorsqu’il est lancé par un processus parent donné
  • Les contrôles tenant compte du processus parent nécessitent un EDR ou un produit de sécurité endpoint personnalisé
• Les utilisateurs classiques ne devraient ouvrir les dépôts non fiables que dans une VM isolée, Windows Sandbox ou un environnement jetable jusqu’à ce que l’IDE soit corrigé
• Comme le hachage change à chaque modification du binaire, il ne faut pas compter sur des listes de blocage par empreinte de fichier pour cette vulnérabilité

Une procédure coordonnée qui s’est figée après le signalement

• Le signalement initial a été envoyé à l’adresse e-mail de sécurité indiquée dans le security.txt de Cursor, mais aucun accusé de réception n’a été reçu
• Mindgard a cherché le bon interlocuteur sécurité via des e-mails de relance et une demande de contact publique
• Le CISO de Cursor a répondu qu’un échec d’automatisation interne avait empêché le démarrage de la procédure HackerOne prévue, puis a invité manuellement Mindgard au programme privé de bug bounty
• Le rapport resoumis sur HackerOne a d’abord été clôturé comme Informative et hors périmètre
  • Mindgard a contesté cette décision
  • Après reproduction du problème par HackerOne, le rapport a été rouvert et la transmission des détails à Cursor a été confirmée
• Par la suite, malgré les demandes de mise à jour, les escalades via HackerOne et les prises de contact directes avec le CISO et la direction de Cursor, aucune réponse utile n’a été obtenue
• Mindgard indique n’avoir reçu aucune preuve qu’un correctif avait été lancé, qu’une équipe d’ingénierie enquêtait ou que le risque avait été communiqué aux utilisateurs affectés

Chronologie entre le signalement et la divulgation complète

• 15 décembre 2025

  • Mindgard découvre la vulnérabilité
  • Signalement à [e-mail]

• 18 décembre 2025

  • Envoi d’une relance demandant un accusé de réception

• 13 janvier 2026

  • Publication d’un message LinkedIn pour trouver un contact chez Cursor
  • Dans les commentaires, un utilisateur identifie le CISO de Cursor

• 15 janvier 2026

  • Le CISO de Cursor indique qu’une défaillance de l’automatisation a empêché l’invitation privée au bug bounty sur HackerOne et invite Mindgard manuellement
  • Mindgard soumet la vulnérabilité via HackerOne

• 16 janvier 2026

  • Le rapport est clôturé comme Informative et hors périmètre
  • Mindgard conteste la décision
  • Après reproduction réussie, le rapport est rouvert

• 20 janvier 2026

  • HackerOne confirme avoir transmis le rapport à Cursor

• 16 février et 3 mars 2026

  • Mindgard demande des mises à jour, sans réponse

• 17 mars 2026

  • Demande directe de mise à jour au CISO de Cursor

• 18 mars 2026

  • HackerOne indique avoir contacté Cursor

• 1er avril 2026

  • Mindgard redemande une mise à jour, sans réponse
  • HackerOne confirme ne pas avoir non plus reçu de mise à jour de Cursor

• 1er juin 2026

  • Mindgard informe HackerOne de son intention de divulguer publiquement

• 3 juin 2026

  • HackerOne fournit les consignes de divulgation

• 14 juillet 2026

  • Publication d’un billet détaillant la vulnérabilité

Pourquoi la divulgation coordonnée n’a pas protégé les utilisateurs

• Dans un schéma classique de divulgation coordonnée, on suit l’ordre suivant : signalement, dialogue, discussion de la gravité, enquête d’ingénierie, développement du correctif, protection des utilisateurs, puis publication
• Ce processus ne fonctionne que si toutes les parties partagent l’objectif de réduire le risque
• Dans ce cas, l’absence de participation significative du fournisseur pendant 7 mois a empêché d’atteindre la phase de réduction du risque
• Sur une plateforme à grande échelle et en évolution rapide, un correctif peut prendre du temps, mais après des mois sans communication, sans mise à jour et sans progrès visible, il devient difficile de continuer à attendre
• Il ne restait au chercheur que deux options
  • garder le silence et laisser les utilisateurs continuer à travailler sur la base erronée qu’ils étaient en sécurité
  • divulguer l’information pour permettre aux organisations d’évaluer le risque et de décider de leur réponse
• Mindgard a choisi la divulgation complète, utilisée lorsque toutes les autres voies ont échoué

Les questions soulevées sur le bug bounty et la réponse sécurité dans l’IA

• À propos des causes du retard, le texte pose plusieurs hypothèses
  • les programmes de bug bounty modernes sont-ils saturés ?
  • des modèles plus capables comme Mythos rendent-ils le volume de signalements ingérable ?
  • Cursor a-t-il relégué la sécurité des utilisateurs au second plan en se concentrant sur un rachat par SpaceX ?
  • quand des milliards sont en jeu, la sécurité des utilisateurs est-elle réellement une priorité ?
• Avec la diffusion des produits IA, le volume de découvertes en sécurité augmente fortement, et une part importante ne rentre pas proprement dans les catégories classiques de vulnérabilités
• Les procédures de classification et de traitement utilisées depuis près de 20 ans échouent rapidement dans l’environnement IA, car leurs hypothèses de base vacillent
• Si les pipelines de divulgation sont saturés, l’industrie devrait l’indiquer clairement afin que chercheurs, clients et utilisateurs puissent juger la situation en connaissance de cause
• Les entreprises en hypercroissance doivent corriger leurs échecs de sécurité tout en traitant les utilisateurs comme des clients de valeur, et non comme des sujets d’expérimentation commerciale

Les conditions pour faire confiance aux outils de développement IA

• Les entreprises de l’IA demandent un niveau d’accès sans précédent au code, aux dépôts, au terminal, aux secrets et aux flux de travail, tandis que la frontière entre suggestion et exécution devient de plus en plus floue
• Les utilisateurs confient à un logiciel de production leur code source, leurs identifiants, leur propriété intellectuelle et des fonctions de plus en plus autonomes
• On ne devrait pas faire confiance à un système au seul motif qu’il améliore la productivité ; la confiance doit être gagnée par la gestion des signalements de sécurité, la communication avec les utilisateurs touchés et la priorité donnée aux correctifs
• La confiance exige la responsabilité, et la responsabilité exige la communication ; or quand utilisateurs, chercheurs et plateformes de divulgation ne reçoivent même pas de mise à jour élémentaire pendant des mois, il devient difficile de vérifier cette responsabilité
• Mindgard a publié l’intégralité des détails afin de donner aux organisations l’occasion d’évaluer leur exposition, d’appliquer des contrôles compensatoires et de juger l’état de sécurité
• Quand continuer à taire l’information ne protège plus les utilisateurs mais seulement le silence, il faut faire passer la sécurité des utilisateurs en premier, même si cela est inconfortable

[GN⁺]

Avis sur Hacker News

• Du point de vue de ceux qui reçoivent des rapports de sécurité, les rapports de faible qualité générés par des LLM arrivent en quantité ingérable et, le plus souvent, ils ne comprennent ni la conception du produit ni le périmètre de sécurité. Il y a parfois d’excellents rapports, donc il faut tout vérifier manuellement, mais envoyer encore plus de « justifications » verbeuses produites par un LLM n’est pas une solution, et cet article semble lui aussi avoir été rédigé en grande partie par un LLM.
  Dans ce cas également, si l’on place un binaire malveillant dans un environnement où le logiciel peut exécuter du code ou des binaires arbitraires, cela semble plutôt relever de la responsabilité de ceux qui doivent isoler et protéger l’espace de travail, sauf si Cursor affirme prendre en charge la sécurité de l’environnement utilisateur.
  Lorsqu’on utilise un LLM pour rédiger un rapport CVE, il vaut mieux l’employer pour établir une procédure de reproduction déterministe, puis rédiger soi-même un texte concis en retirant les adjectifs inutiles et les exagérations typiques des LLM.

  • Un binaire ne devrait pas s’exécuter automatiquement simplement parce qu’on a ouvert avec Cursor un dépôt fraîchement cloné.
  • La variable PATH existe précisément pour contrôler ce genre de problème. Si j’ai bien compris, Cursor ajoute immédiatement le dépôt au PATH sans approbation de l’utilisateur.
  • Il n’y a pas de solution facile ; si la sécurité est importante, il faut affecter davantage de personnel de revue pour s’adapter à l’environnement qui a changé. Ajouter une couche supplémentaire de vérification par LLM ne réglera pas le problème.

• La racine du problème est que Cursor ne considère pas le clonage d’un dépôt et l’exécution de code comme deux frontières de sécurité distinctes. Par défaut, Cursor désactive Workspace Trust[0], et il suffit d’ouvrir un dépôt contenant "runOn": "folderOpen" dans .vscode/tasks.json pour que du code arbitraire s’exécute déjà[1].
  [0] https://cursor.com/docs/agent/security#workspace-trust
  [1] https://www.oasis.security/blog/cursor-security-flaw

• Mindgard dit avoir découvert la vulnérabilité pour la première fois le 15 décembre 2025, l’avoir signalée le jour même puis à plusieurs reprises par la suite, mais qu’elle est toujours présente dans la dernière version de Cursor après 6 mois et plus de 197 nouvelles versions.
  Au départ, le rapport a été clôturé comme informatif ou hors périmètre ; après contestation, HackerOne l’a rouvert, l’a reproduit puis l’a transmis à Cursor. Ensuite, les demandes de mise à jour, les questions supplémentaires, l’escalade via HackerOne et même les messages envoyés à la direction de Cursor seraient tous restés sans réponse. Il est difficile de comprendre pourquoi Cursor réagit ainsi.

  • Le processus de traitement des CVE lui-même est cassé. Avec les progrès de l’IA agentique, les programmes de divulgation de vulnérabilités des entreprises et HackerOne voient exploser à la fois les rapports de faible qualité et les rapports réellement excellents ; comme les mêmes IA rédigent les deux, il est presque impossible de les distinguer en se fiant seulement à leur apparence.
    Résultat, les entreprises ne répondent plus comme avant, et lors d’une conférence de cybersécurité en juin, l’ambiance dominante était que la divulgation responsable était morte ou en train de mourir, et qu’il valait mieux rendre les choses publiques. Microsoft et l’affaire Nightmare Eclipse ont souvent été cités.
  • La possibilité d’une backdoor intentionnelle vient aussi à l’esprit. Si la NSA ou le FBI plaçait git.exe dans un dépôt ciblé et faisait en sorte que la cible le clone, la charge utile pourrait s’exécuter.
    Cursor étant basé sur VS Code, je me demande si la même chose se produit aussi dans VS Code.

• J’ai du mal à être totalement d’accord avec l’idée qu’il s’agit d’une vulnérabilité critique. Pour l’exploiter réellement, l’attaquant doit d’abord placer dans le dossier de code de l’utilisateur un exécutable malveillant nommé git.exe, ce qui revient un peu à qualifier de vulnérabilité le fait de modifier .bashrc pour créer un alias faisant exécuter /tmp/mega-big-virus.sh par ls.
  C’est bien un chemin d’attaque, mais si ce fichier est déjà présent dans le système de fichiers, on peut considérer qu’il y a eu compromission préalable.

  • Il suffit de cloner un dépôt GitHub et de l’ouvrir avec Cursor, l’éditeur par défaut, pour être infecté. C’est comme insérer un CD qui lance autorun.exe et infecte Windows.
    On pourrait dire que l’utilisateur doit inspecter lui-même, dans un environnement isolé, tous les fichiers du dépôt et les binaires suspects comme git.exe, mais en pratique ce n’est pas l’utilisateur qui contrôle cela : ce sont les politiques de sécurité qui empêchent l’exécution automatique, et Cursor devrait également la désactiver.
  • Contrairement à .bashrc, les dossiers de code proviennent souvent de sources non fiables. Ouvrir un projet GitHub pour l’examiner ne devrait pas aller jusqu’à autoriser l’exécution de code arbitraire.
    Cela dit, dans les principaux IDE, cette frontière est déjà rompue depuis longtemps, et les fonctionnalités distantes SSH et devcontainer de VS Code autorisent elles aussi, par conception, l’exécution de code distant.
  • Dès le premier paragraphe de la page, l’article explique clairement en deux phrases qu’après ouverture d’un projet, Cursor cherche le binaire Git à plusieurs endroits, y compris dans l’espace de travail courant, et que si l’on place un git.exe malveillant à la racine du dépôt, il l’exécute sans saisie ni confirmation de l’utilisateur. Ce n’est pas un article qui cache le comportement essentiel.
  • Le simple fait de cloner un dépôt et de l’ouvrir dans l’IDE revient à accorder au propriétaire du dépôt un droit d’exécution de code à distance, ce qu’il est difficile de considérer comme un contrat implicite inclus dans l’action d’ouvrir un dossier.
  • Il y a 30 ans déjà, il existait des attaques par ordre de recherche des DLL, consistant à placer une DLL de substitution infectée dans un dossier de MP3 ou de photos afin que Winamp ou la visionneuse de photos Windows la charge ; c’est très similaire à ce cas.

• Il est étrange que Cursor exécute des exécutables arbitraires sans confirmation, et il est préoccupant que les chercheurs n’aient pas reçu de réponse correcte pendant des mois.
  Cela dit, l’exemple du lancement de la calculatrice peut être quelque peu trompeur. Si je comprends bien, l’exécutable malveillant doit déjà avoir été téléchargé sur le système, et lorsque Cursor tente de l’exécuter, l’ACL devrait intervenir et demander l’autorisation de lancer pour la première fois une nouvelle application non signée. Une exploitation réelle pourrait nécessiter que l’ACL soit complètement désactivée.

  • Si la fenêtre de confirmation affiche « Voulez-vous exécuter git.exe ? », beaucoup penseront que Cursor a besoin de Git mais qu’un réglage de permissions est mal configuré, et approuveront tel quel.
  • La même chose peut arriver si l’on utilise un PS1 affichant la branche Git courante tout en incluant le répertoire courant dans le PATH. Dans ce cas, on peut se demander s’il faudrait aussi soumettre une CVE à haut risque contre Bash.

• Cela semble moins être un bug propre à Cursor qu’un problème lié à l’ordre de recherche spécifique à Windows, qui cherche un exécutable dans le répertoire de travail courant avant de consulter le PATH. Beaucoup de programmes Windows risquent d’être exposés à des attaques similaires

  • Les logiciels soucieux de sécurité ont déjà corrigé ce problème
    Comme l’explique https://go.dev/blog/path-security, Command et LookPath recherchent les programmes dans les répertoires listés dans le PATH courant selon les conventions du système d’exploitation, mais aujourd’hui, le fait d’inclure le répertoire courant est souvent inattendu et peut entraîner des problèmes de sécurité
    https://pkg.go.dev/os/exec#hdr-Executables_in_the_current_di...
  • On peut facilement atténuer le problème en recherchant le véritable exécutable Git dans des chemins système connus, ou en laissant l’utilisateur configurer le chemin ; à ma connaissance, VS Code procède aussi de cette manière
  • C’est un piège de sécurité ancien et bien connu contre lequel il faut impérativement se protéger lorsqu’on développe des logiciels pour Windows
  • Dans ce cas, cela revient finalement à dire qu’il y a bien un bug et une vulnérabilité dans la version Windows de Cursor

• Il est malheureusement très courant que les entreprises ne donnent pas la priorité à la sécurité, et cela peut aussi se comprendre dans une certaine mesure. On peut également comprendre qu’une startup de sécurité, lassée d’attendre, rende l’affaire publique pour récupérer au moins une partie du coût engagé sous forme de retombées marketing ; il existe aussi des moments où une divulgation publique de vulnérabilité est nécessaire
  Cela dit, s’ils voulaient vraiment aider à résoudre le problème, ils auraient sans doute pu faire davantage que relancer sur HackerOne et envoyer une fois un message LinkedIn au CISO. Maintenant, on a amèrement l’impression que plus personne ne s’en soucie vraiment

  • On ne voit pas bien ce que signifierait aider sincèrement à résoudre le problème, ni ce que recouvrent exactement les coûts irrécupérables évoqués ici. Dans l’ensemble, cela paraît beaucoup trop vague

• Je me demande pourquoi Cursor exécute automatiquement un exécutable, et quel processus décisionnel a conduit à ce comportement. Vim a déjà eu des problèmes d’exécution de code inattendue au chargement de fichiers à cause de fonctionnalités explicites comme %{expr}, mais il est difficile de comprendre pourquoi Cursor cherche précisément git.exe et à qui cette fonctionnalité rend service
  Même sans avoir jamais utilisé Cursor, on se demande pourquoi un CVE redondant, qui semble simple à corriger, existe

  • Le scénario courant consiste à demander à Cursor de résumer un dépôt existant pour rédiger un README ; Cursor lit alors le dépôt et le code, puis exécute des commandes Git pour fournir aussi des métadonnées comme la branche de développement ou d’anciens tags
    Le problème, c’est que lorsqu’on lui fait évaluer un dépôt distant, après avoir cloné le dépôt puis exécuté git ... dans le répertoire de travail, Windows peut considérer le fichier git présent dans ce répertoire comme la cible à exécuter. Du code peut donc s’exécuter immédiatement lorsqu’on bascule vers un dépôt non fiable ou une branche compromise
    La solution habituelle consiste à utiliser le chemin complet du Git installé sur le système ; même si c’est fastidieux à saisir pour un humain, c’est trivial pour Cursor
  • L’agent intégré semble chercher le vrai Git de l’utilisateur afin de lire le contexte dans plusieurs branches et worktrees. Il existe des méthodes plus sûres, mais ce genre de petit raccourci se prête facilement aux erreurs dans les flux de travail assistés par IA, et c’est aussi un endroit où les alertes peuvent facilement être manquées dans le triage de bugs assisté par IA

• Comme on donne couramment aux agents de développement le droit de récupérer et pousser des dépôts Git, cela devient un énorme vecteur d’attaque sur la chaîne d’approvisionnement. Si un agent Cursor en cours d’exécution récupère les derniers fichiers et qu’un attaquant a placé un exécutable dans le projet, des centaines de milliers de personnes pourraient soudain exécuter un EXE arbitraire avec les droits de l’utilisateur par défaut

• Le rapport se lit un peu comme un texte écrit par une IA. Pour l’exploiter, il faut que la charge malveillante soit déjà présente sur le PC via un clonage, un téléchargement, etc. ; je comprends donc la gravité, mais on espère justement ne pas se retrouver dans cette situation au départ

  • Les agents de codage modernes, lorsqu’on les interroge sur une API dont la documentation est floue, peuvent cloner un dépôt et lire le code ; cette vulnérabilité est donc réellement exploitable
  • La charge malveillante peut se trouver dans un dépôt distant. Il suffit de faire un git clone du dépôt puis de l’ouvrir dans Cursor pour que la compromission soit complète
  • Si vous êtes développeur open source, vous pouvez aussi recevoir une pull request contenant git.exe
  • Télécharger un dépôt pour en consulter le source n’est généralement pas considéré comme équivalent à l’activation d’une charge malveillante, et c’est précisément ce qui est inquiétant. Même si le style IA dérange, il faut critiquer le contenu de la vulnérabilité plutôt que la manière dont le texte est rédigé
  • Il est difficile d’affirmer que la charge doit déjà se trouver sur le PC. Si une injection de prompt peut amener à lancer une commande comme download [https://github.com/hackmycursor/exploit.git](<https://github.com/hackmycursor/exploit.git>;), l’agent pourrait télécharger puis exécuter git.exe