Ce que Cato a trouvé 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, soit 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 a rouvert le dossier, a livré un premier correctif le 1er avril et le second le 1er juin. 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. C'est l'agent qui lit du contenu pour le compte de l'utilisateur: la réponse d'un serveur Model Context Protocol connecté, une page renvoyée par une recherche web ou un fichier interne au projet. Ce contenu porte des ordres cachés que le modèle finit par suivre.
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. Une instruction injectée peut alors écraser un fichier système, par exemple le binaire d'aide du bac à sable ou un profil de shell. La seconde faille exploite une vérification des liens symboliques qui laisse passer en cas d'erreur: quand Cursor ne parvient pas à résoudre un raccourci, il fait confiance au chemin interne au projet et écrit tout droit sur ce même programme d'aide. Une fois ce programme écrasé, la commande suivante s'exécute hors du bac à sable avec tous les droits du développeur.
La liste de lecture est désormais 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 de code se résumait au code que l'on écrivait et aux extensions que l'on installait. Un agent autonome l'élargit à tout ce qu'il lit de lui-même: le README d'une dépendance, la réponse d'un outil, une page récupérée. Chacun de ces éléments est aujourd'hui une 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 de codage auprès de ses ingénieurs, l'outil devient un maillon de la chaîne d'approvisionnement avec une portée jusqu'à la machine, et non un simple greffon de productivité. Sous NIS2 dans l'UE, comme sous les obligations équivalentes que les entreprises britanniques assument déjà, la sécurité du logiciel que vous distribuez à vos équipes relève de la responsabilité du conseil, et un agent non corrigé qui fait confiance à un contenu non vérifié tombe pleinement 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 travaille 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 disposent d'une autorisation autonome d'écrire des fichiers ou d'exécuter des commandes, et qui l'a validée.
L'étape durable consiste à 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 toute écriture hors du projet de travail. L'outil mérite d'être gardé. Les droits qui l'entourent réclament maintenant la rigueur que vous appliquez déjà à tout composant capable de toucher une machine en production.
À lire ensuite: Une IA a mené seule toute une attaque par rançongiciel | Une faille Squid de 29 ans fuite les logins en clair
