Cursor lance git.exe depuis la racine du dépôt

Mindgard révèle une faille critique et insidieuse dans Cursor sous Windows : si un fichier nommé git.exe se trouve à la racine d’un projet, l’IDE l’exécute automatiquement à l’ouverture du dépôt, sans avertissement ni demande de confirmation, avec les droits du développeur.

Articles associés :
La faille TrapDoor dans la chaîne d’approvisionnement npm/PyPI  /  
Fuites de code source et contournement des correctifs

Le bug dans un paragraphe

Qu’est-ce que le bug Cursor-git.exe ? Lors du chargement d’un projet, Cursor recherche les binaires Git à plusieurs emplacements, y compris dans l’espace de travail (workspace). Un fichier git.exe placé à la racine du dépôt est exécuté dans le cadre de la résolution du chemin d’accès. Les traces du moniteur de processus (Process Monitor) montrent que Cursor.exe lance git rev-parse –show-toplevel avec le binaire de l’espace de travail. Le PoC de Mindgard exploite des machines Windows où calc.exe est renommé en git.exe. La calculatrice démarre et se relance en arrière-plan.

Aucune injection de prompt ni contournement de modèle (model jailbreak). Il s’agit d’un Binary Planting dans l’espace de travail. Pour les attaquants, un dépôt corrompu suffit : cloner, ouvrir avec Cursor, et le code s’exécute dans le contexte utilisateur du développeur. Souvent avec accès aux tokens, clés SSH et packages internes.

Chronologie et silence des éditeurs

Mindgard a signalé la vulnérabilité le 15 décembre 2025 à security-reports@cursor.com. Une confirmation et une reproduction ont été obtenues via HackerOne et le canal dédié au RSSI (CISO), suivies d’un long silence de la part des équipes de recherche. Le 14 juillet 2026, une divulgation complète a été publiée en l’absence de remédiation coordonnée. À ce jour, aucune publication de correctif ni d’avis de sécurité public n’a été émis par l’éditeur.

Pour les RSSI, il s’agit d’une deuxième faille à prendre en compte, aux côtés du bug initial : les SLA des éditeurs et la rigueur dans la gestion des divulgations doivent désormais figurer parmi les critères d’évaluation des outils d’IA dédiés au développement logiciel. La productivité ne saurait, à elle seule, constituer un gage de confiance. Cursor est souvent utilisé en tant que solution non autorisée (Shadow-IT) au sein de nombreuses organisations d’ingénierie. Aucune échéance n’a été communiquée pour la résolution de cette vulnérabilité.

Mesures à mettre en place par les entreprises en attendant le correctif

En attendant qu’un correctif soit déployé par l’éditeur, les mesures suivantes restent d’actualité : inventaire des utilisateurs de Cursor sous Windows, mise en place d’une politique pour les dépôts non approuvés (untrusted repos) et contrôle des terminaux pour bloquer les exécutables issus de l’espace de travail. La liste de vérification ci-dessous constitue le standard minimal pour les RSSI et les responsables techniques.

AppLocker ou WDAC (Windows Defender Application Control) doivent agir sur les chemins d’accès plutôt que sur les hachages. Les attaquants modifient facilement les hachages. Il est préférable d’interdire génériquement les exécutables issus des racines des espaces de travail, plutôt que de bloquer uniquement git.exe. Le « Binary Planting » est une technique connue qui touche plusieurs IDE basés sur l’IA. Exiger uniquement « aucun CVE dans le scanner » revient à ignorer le risque réel. Source principale : blog de Mindgard du 14 juillet 2026 ; vérifications croisées avec Dark Reading et The Hacker News.

Foire aux questions

Chaque question est verrouillée. Un clic déverrouille la réponse.

Cela concerne-t-il macOS et Linux ?

L’exploitation décrite cible Windows et git.exe à la racine du dépôt. Il convient d’évaluer séparément les autres plateformes. Les développeurs sous Windows constituent clairement le point chaud.

Est-il suffisant de bloquer git.exe ?

C’est le déclencheur actuel. La résolution des chemins peut vérifier d’autres noms d’outils. Mieux vaut : ne pas autoriser d’exécutables depuis les racines des espaces de travail de manière générique.

Est-ce la même chose que la CVE-2026-26268 (Git Hooks) ?

Non. Selon les rapports, la vulnérabilité CVE-2026-26268 concerne des hooks Git cachés. L’incident Mindgard, quant à lui, impliquait un *Binary Planting* de git.exe dans le répertoire racine. Deux mécanismes distincts, mais un même résultat : l’exécution de code arbitraire.

Que exigeons-nous du fournisseur ?

Correctif, avis de sécurité, politique de recherche de chemins claire sans exécution dans l’espace de travail, ainsi que des SLA (Service Level Agreements) transparents pour les vulnérabilités critiques dans le cadre des programmes de prime aux bugs.

Source principale ?

Blog Mindgard : « Cursor 0day : quand la divulgation totale devient la seule protection restante » (14.07.2026).

Les choix de la rédaction

À lireContournement JWT SharePoint : sites locaux exposésÀ lireContournement de BitLocker en cas d’accès physiqueÀ lireNihon Kotsu : une cyberattaque paralyse la dispatching

Plus du réseau MBF Media

cloudmagazinAWS Sovereign Cloud : ce qui est vraiment séparé