Ce que Cato a trouve dans Cursor
Cato AI Labs a divulgué deux vulnérabilités critiques dans Cursor, l'éditeur de code à IA que son fabricant dit utilisé par plus de la moitié des Fortune 500. Baptisées DuneSlide et suivies sous les identifiants CVE-2026-50548 et CVE-2026-50549, toutes deux portent un score CVSS de 9,8 sur 10, ou 9,3 sur la nouvelle échelle 4.0. Elles sont corrigées dans Cursor 3.0, publié le 2 avril 2026, et toute version antérieure est touchée.
Aucune exploitation active n'était constatée au moment de la divulgation. Le chemin vers le correctif n'a pas été lisse. Cato a signalé le problème le 19 février, l'éditeur l'a d'abord rejeté le 23 février, puis l'a rouvert, a livré un correctif le 1 avril et le second le 1 juin, et les numéros CVE ont été attribués le 5 juin.
Comment une page web devient une commande
La technique est l'injection d'instructions sans le moindre clic. Le développeur ne tape jamais d'ordre malveillant. À la place, l'agent lit du contenu au nom de l'utilisateur: une réponse d'un serveur Model Context Protocol connecté, une page renvoyée par une recherche ou un fichier du projet. Ce contenu porte des ordres cachés que le modèle suit ensuite.
La première faille détourne le paramètre working_directory. Quand l'agent le fixe sur un chemin non standard, Cursor ajoute ce chemin à sa liste d'écriture autorisée sans le vérifier, si bien qu'une instruction injectée peut écraser un fichier système comme le binaire assistant du bac à sable ou un profil de shell. La seconde faille exploite une vérification de liens symboliques qui cède à l'erreur: quand Cursor ne peut pas résoudre un raccourci, il fait confiance au chemin interne au projet et écrit tout droit vers le même assistant. Écrasez cet assistant et la commande suivante s'exécute hors du bac à sable avec tous les droits du développeur.
La liste de lecture est desormais la surface d'attaque
Le déplacement inconfortable porte sur ce qui compte comme entrée. Pendant des années, le modèle de menace d'un éditeur était le code que vous écriviez et les extensions que vous installiez. Un agent autonome l'élargit à tout ce qu'il lit de lui-même: le README d'une dépendance, une réponse d'outil, une page téléchargée. Chacune d'elles est désormais instruction exécutable, et le rayon d'impact est le système d'exploitation plutôt qu'un onglet de navigateur.
Pour une entreprise qui a déployé des assistants IA auprès de ses ingénieurs, cela fait de l'outil un composant de la chaîne d'approvisionnement avec une portée jusqu'à la machine, et non un greffon de productivité. Sous NIS2 dans l'UE, transposée en France et accompagnée par l'ANSSI, la sécurité du logiciel que vous distribuez au personnel relève de la direction, et un agent non corrigé qui fait confiance à un contenu non vérifié tombe précisément sous ce devoir.
Ce que les dirigeants devraient faire cette semaine
L'étape immédiate est l'hygiène des versions. Vérifiez que chaque développeur est sur Cursor 3.0 ou plus récent, car rien d'antérieur n'est sûr, et posez la même question pour tout autre éditeur à agent ou assistant d'IDE en service. Établissez quels outils IA ont l'autorisation autonome d'écrire des fichiers ou d'exécuter des commandes, et qui l'a validée.
L'étape durable est de traiter les sources de lecture d'un agent comme non fiables par défaut. Limitez les serveurs Model Context Protocol qu'une équipe peut connecter, tenez les agents à l'écart des contenus externes non relus quand vous le pouvez et exigez une approbation humaine pour les écritures hors du projet de travail. L'outil mérite d'être gardé; les droits autour de lui réclament maintenant la même rigueur que vous appliquez déjà à tout composant capable de toucher une machine en production.
À lire ensuite: Le risque de jailbreak a maintenant une note · Votre agent IA fait confiance à un outil piégé
