Les deux vulnérabilités révèlent une faille native dans les LLM et les IDE assistés par l’IA, affectant bien plus que le simple curseur.
Les chercheurs ont découvert deux vulnérabilités dans l’environnement de développement intégré (IDE) largement utilisé compatible Cursor AI, qui peuvent être exploitées via une injection rapide pour réaliser l’exécution de code à distance (RCE).
Les deux failles, identifiées comme CVE-2026-50548 et CVE-2026-50549, permettent aux attaquants de sortir du bac à sable d’exécution de commandes de Cursor, la couche de protection censée empêcher l’agent IA interne d’effectuer des actions malveillantes sur le système d’exploitation sous-jacent.
« L’exploit ne nécessite aucun privilège utilisateur préalable ni interaction utilisateur spécifique », ont déclaré les chercheurs de Cato Networks, qui ont découvert les failles, dans leur rapport. « Il est déclenché lorsqu’une victime émet une invite inoffensive qui ingère par inadvertance une charge utile contrôlée par un acteur malveillant provenant d’une source non fiable, telle qu’un serveur MCP ou un résultat de recherche sur le Web. »
Cursor, qui a été récemment acquis par SpaceX pour 60 milliards de dollars en actions, produit l’un des outils de codage assistés par IA les plus utilisés dans l’espace d’entreprise. Les deux failles ont été corrigées dans la version 3.0 de l’IDE Cursor, publiée en avril.
Vulnérabilité native dans les LLM
Les grands modèles linguistiques (LLM) sont nativement vulnérables aux instructions malveillantes qui pourraient être cachées dans le contenu qu’ils traitent. Ceci est particulièrement dangereux à l’ère de l’IA agentique, où les LLM sont combinés avec une variété d’outils, notamment des navigateurs et des API qui leur permettent d’accéder à une variété de contenus publics tiers, tels que l’analyse des pages Web dans les résultats de recherche et les flux RSS, le code dans les référentiels, les commentaires dans les trackers de bogues, les e-mails dans les boîtes de réception des utilisateurs et leurs documents.
Protéger les outils d’IA contre l’injection rapide est très difficile et implique généralement une approche à plusieurs niveaux, comprenant des garde-fous intégrés au modèle par le laboratoire d’IA qui l’a créé, des instructions dans les invites du système pour traiter certains contenus comme des données passives, des modèles de superviseur exécutés au-dessus des LLM qui traitent les données, un filtrage par mot-clé traditionnel, une segmentation contextuelle, des contrôles d’accès granulaires, la réintégration des humains dans la boucle pour approuver les opérations sensibles et bien plus encore.
Les IDE assistés par l’IA comme Cursor, ainsi que les faisceaux de codage agentiques en ligne de commande, demandent généralement à l’utilisateur d’approuver par défaut chaque modification de fichier ou commande qu’il doit exécuter. Mais cela n’est pas pratique pour les flux de travail de codage autonomes et conduit rapidement à une lassitude en matière d’approbation.
Une autre façon de résoudre ce problème consiste à exécuter ces flux de travail autonomes dans des conteneurs, des environnements virtualisés ou des bacs à sable, de sorte que si les agents exécutent des instructions malveillantes en raison d’invites malveillantes injectées dans des sources de données tierces, l’impact soit limité. Le curseur utilise un bac à sable d’exécution de commandes qui limite par défaut les écritures de fichiers dans le répertoire du projet en cours.
Défauts logiques dans la couche d’isolation
Cependant, les chercheurs de Cato ont découvert que l’outil prend en charge un paramètre appelé qui permet de remplacer ce chemin par défaut par programme.
« Une injection rapide (servie via une requête inoffensive du serveur MCP ou un résultat Web empoisonné) peut inciter le LLM à définir un chemin contrôlé par les acteurs menaçants en dehors de la portée du projet », ont-ils expliqué.
En exploitant cette erreur, les attaquants pourraient écraser l’exécutable lui-même à partir du chemin de l’application, ou écrire des scripts malveillants dans le fichier de configuration du shell qui est chargé à chaque fois que l’utilisateur exécute une commande, ou dans les dossiers de démarrage du système, comme sur macOS.
Par ailleurs, les chercheurs ont également découvert que les attaquants pouvaient demander à l’agent Cursor de créer un fichier de lien symbolique (lien symbolique) dans le répertoire du projet, pointant vers un fichier résidant en dehors du répertoire.
« Par défaut, l’agent curseur tente de canoniser les chemins (en résolvant les liens symboliques) pour déterminer leur véritable emplacement et vérifier qu’ils se trouvent dans la racine du projet », ont expliqué les chercheurs. « La vulnérabilité se produit parce que la logique de canonisation contient une solution de repli dangereuse : si la canonisation échoue (par exemple, lorsque le chemin n’existe pas ou si le chemin ne dispose pas d’autorisations de lecture sur l’un de ses répertoires), Cursor revient à utiliser le chemin du lien symbolique d’origine dans le répertoire du projet. »
Ces deux vulnérabilités, que Cato a surnommées DuneSlide, peuvent permettre une compromission complète du système d’exploitation sous-jacent en exécutant du code en dehors du bac à sable restreint Cursor. Mais plus encore, ils montrent que l’injection rapide peut être un vecteur d’attaque permettant d’exploiter les vulnérabilités des logiciels utilisés pour mettre en œuvre les agents d’IA.
Cursor est loin d’être le seul IDE ou harnais de codage alimenté par l’IA et, selon les chercheurs, pas le seul à présenter de tels défauts logiques dans ses couches d’isolation.
« Si ces problèmes avaient été des cas isolés de compromission via des injections rapides, nous aurions pu les attribuer à des vulnérabilités spécifiques », ont-ils déclaré. « Cato AI Labs, cependant, est en train de divulguer de manière responsable les vulnérabilités de tous les agents de codage populaires, soulignant qu’une approche plus systémique de la protection est nécessaire. »
