Présentation de la vulnérabilité
La vulnérabilité dans Cursor permet l'exécution de code arbitraire sous les privilèges de l'utilisateur actuel. Cette faille de sécurité est simple : lors du chargement d'un projet, Cursor tente de localiser les binaires Git à plusieurs emplacements, y compris le répertoire de travail actuel. Si un attaquant a planté un git.exe malveillant à la racine du répertoire, Cursor l'exécutera automatiquement sans avertissement ni approbation.
Fonctionnement de la vulnérabilité
La vulnérabilité est exploitée lorsque Cursor charge un projet contenant un git.exe malveillant dans le répertoire à la racine. L'exécution se fait sans interaction utilisateur, sans clics, sans prompts, sans dialogue d'approbation ou d'avertissement. Le résultat est l'exécution de code arbitraire.
Pour démontrer la vulnérabilité de manière sécurisée, Mindgard a utilisé une preuve de concept inoffensive : l'application Calculatrice Windows, renommée en git.exe, placée à la racine du répertoire. Le lancement de Cursor contre ce répertoire a suffi pour exécuter l'application.
4:25:12.6209706 PM Cursor.exe 54880 Process Create c:\\Users\\aport\\Documents\\Audits\\cursor\\test_repos\\git_exec0001\\git.exe SUCCESS PID: 48972, Command line: git rev-parse --show-toplevel "C:\\Users\\aport\\AppData\\Local\\Programs\\cursor\\Cursor.exe" C:\\Users\\aport\\AppData\\Local\\Programs\\cursor\\Cursor.exe
Implications et limites
La vulnérabilité n'est pas théorique et ne dépend pas d'une chaîne complexe d'exploitation. L'exploitation nécessite simplement qu'un développeur ouvre un projet contenant un git.exe binaire dans le répertoire à la racine. Les systèmes Windows d'entreprise peuvent utiliser AppLocker ou les stratégies de contrôle d'application Windows pour refuser l'exécution du nom d'exécutable affecté à partir des répertoires de travail des développeurs.
Les consommateurs doivent ouvrir les dépôts non fiables uniquement dans un environnement isolé, tel que Windows Sandbox, jusqu'à ce que l'IDE soit corrigé. Il ne faut pas se fier aux listes de blocage de hachage de fichiers pour cette question.
Analyse de la réponse de Cursor
La partie la plus déconcertante de cette divulgation est l'absence de réponse de la part de Cursor. Au cours de sept mois, Mindgard a tenté à plusieurs reprises d'engager le dialogue par tous les canaux disponibles. La divulgation initiale a été envoyée directement à l'adresse e-mail de signalement de sécurité de Cursor, telle que spécifiée dans le fichier security.txt publié de l'entreprise.