Cursor : une injection de prompt a pu transformer l’agent IA en shell local

Les assistants de programmation ne se contentent plus de suggérer quelques lignes de code. Connectés à des dépôts, à des messageries d’équipe et à des outils externes, ils peuvent aussi rechercher de l’information, modifier des fichiers et lancer des commandes. Cette capacité d’action est précisément au cœur d’une vulnérabilité de Cursor révélée par les chercheurs d’AimLabs : une injection de prompt issue de Slack pouvait amener l’agent IA à modifier sa propre configuration, puis à exécuter une commande sur l’ordinateur du développeur.

Le problème, suivi sous la référence CVE-2025-54135, a été corrigé dans Cursor 1.3, mis en ligne le 8 juillet 2025. Mais l’incident dépasse le seul cas de cet éditeur de code assisté par IA. Il met en lumière une difficulté fondamentale : lorsqu’un agent lit des contenus non fiables et possède en même temps des droits d’action sur une machine, une simple phrase cachée dans une source externe peut devenir une instruction opérationnelle.

Une vulnérabilité à l’intersection de l’IA et du poste de travail

Selon AimLabs, la faille pouvait conduire à une exécution de code à distance sur l’appareil d’un utilisateur. Dit plus simplement, un attaquant pouvait influencer Cursor afin que l’outil lance des commandes dans l’environnement local où il était installé. Les chercheurs décrivent le résultat comme la transformation de l’agent de codage en shell local, c’est-à-dire un moyen d’exécuter des commandes sur le poste du développeur.

Le scénario ne repose pas sur une vulnérabilité classique du type débordement de mémoire ou mot de passe volé. Il exploite la manière dont un agent fondé sur un modèle de langage interprète ce qu’il lit. Cursor pouvait se connecter à un serveur MCP, pour Model Context Protocol, afin d’accéder à des outils et à des informations provenant notamment de Slack et de GitHub. Cette ouverture est utile dans un contexte professionnel : l’agent peut retrouver une consigne dans une discussion ou consulter un projet. Elle crée aussi une frontière de confiance délicate.

En effet, le contenu ramené par un connecteur ne doit pas être assimilé à une instruction légitime. Une conversation Slack, une documentation, un ticket ou un fichier présent dans un dépôt peuvent contenir du texte contrôlé par un tiers. Si l’agent confond ce texte avec un ordre à suivre, il peut agir contre l’intérêt de son utilisateur.

AimLabs qualifie l’attaque de data poisoning. Dans ce cas précis, l’enjeu n’est pas nécessairement de modifier les données ayant servi à entraîner le modèle. Le contenu empoisonné est surtout introduit dans le flux d’informations que l’agent consulte au moment où il travaille. Cette nuance est importante : le risque peut apparaître même avec un modèle inchangé et correctement hébergé.

Une correction publiée en vingt-quatre heures

La chronologie communiquée montre une réponse rapide de l’équipe de Cursor après le signalement. Les utilisateurs restés sur une version antérieure à la 1.3 devaient toutefois considérer leur installation comme vulnérable au mécanisme décrit.

Le délai entre le signalement et le correctif est un élément positif, mais il ne rend pas automatiquement sûres les installations déjà déployées. Dans les entreprises, les mises à jour d’outils de développement peuvent être différées par des procédures de validation ou par simple manque de visibilité. Or, un logiciel de codage est souvent utilisé avec des droits étendus sur des projets, des fichiers de configuration, des clés de test ou des environnements locaux.

Comment l’attaque via Slack pouvait-elle fonctionner ?

La démonstration d’AimLabs partait d’un point d’entrée banal : un message Slack. Cursor récupérait des informations de ce service via un serveur MCP. Les chercheurs y ont placé une injection de prompt malveillante, conçue pour influencer les décisions de l’agent.

D’après leur description, le contenu injecté poussait Cursor à modifier son fichier de configuration. La modification ajoutait un serveur MCP supplémentaire, associé à une commande de démarrage malveillante. Une fois cette configuration altérée, Cursor pouvait exécuter immédiatement les instructions associées à ce serveur.

La chaîne d’attaque tient donc en quelques étapes :

• un contenu externe est consulté par l’agent via une intégration ;
• ce contenu renferme une instruction destinée à l’IA plutôt qu’à l’humain ;
• l’agent modifie une configuration locale ;
• la nouvelle configuration provoque l’exécution d’une commande sur la machine hôte.

L’aspect le plus préoccupant est l’absence de possibilité, pour l’utilisateur, de rejeter l’exécution au moment décrit par les chercheurs. Dans un outil traditionnel, l’ajout d’un programme au démarrage ou l’exécution d’une commande système sont généralement des opérations visibles, parfois accompagnées d’une demande de confirmation. Dans un environnement agentique, plusieurs décisions sont enchaînées par le logiciel au nom de l’utilisateur. Si les garde-fous sont insuffisants, cette automatisation réduit la capacité de contrôle humain.

Pourquoi les connecteurs MCP changent l’échelle du risque

Le protocole MCP vise à relier une IA à des outils et à des sources de contexte. Cette logique rend les assistants beaucoup plus utiles : un agent peut s’appuyer sur des discussions de projet, des tickets, du code et des services internes pour répondre à une demande complexe. Mais chaque connexion ajoute également une source potentielle d’instructions non fiables.

Le danger ne vient donc pas uniquement de Slack. Le même raisonnement vaut pour d’autres espaces auxquels un agent pourrait avoir accès : un dépôt GitHub, un fichier de documentation, un commentaire dans un ticket ou une base de connaissances. Dès lors qu’un contenu visible par l’agent est contrôlable par une personne malveillante, il peut servir de support à une injection de prompt.

Cela ne signifie pas qu’il faut renoncer à toute intégration. Il faut en revanche séparer clairement deux catégories de données : celles qui peuvent être lues comme du contexte, et celles qui peuvent autoriser une action. Un texte récupéré sur un service externe ne devrait pas, à lui seul, justifier une modification de configuration ou le lancement d’une commande.

L’affaire Cursor rappelle ainsi que la sécurité d’un agent IA ne dépend pas uniquement de la qualité du modèle de langage. Elle dépend aussi des permissions accordées, des outils appelables, des confirmations demandées et de la façon dont le logiciel traite les contenus externes.

Quelles mesures prendre pour les développeurs et les entreprises ?

La première mesure est la plus immédiate : utiliser Cursor 1.3 ou une version plus récente, puisque le correctif a été intégré à cette version. Vérifier le numéro installé est essentiel, en particulier sur les machines de développement qui ne reçoivent pas automatiquement leurs mises à jour.

Au-delà du correctif propre à cette vulnérabilité, les organisations qui emploient des agents de codage ont intérêt à adopter quelques principes de sécurité. Ils ne suppriment pas le risque d’injection de prompt, mais limitent les conséquences d’un comportement inattendu.

• Appliquer le principe du moindre privilège : un assistant ne devrait disposer que des accès nécessaires à sa tâche, et non de droits étendus par défaut sur l’ensemble du poste ou des projets.
• Contrôler les serveurs MCP configurés : les connexions et les commandes de démarrage associées doivent être connues, validées et régulièrement révisées.
• Limiter les actions automatiques sensibles : modifier une configuration, installer un composant ou lancer une commande mérite un mécanisme de validation explicite lorsque cela est possible.
• Traiter les contenus externes comme non fiables : messages, commentaires, pages de documentation et dépôts peuvent contenir des instructions conçues pour manipuler un agent.
• Former les équipes : les développeurs doivent savoir qu’un texte apparemment anodin peut viser l’IA qui le lit, même s’il ne semble pas suspect à un lecteur humain.

Les contrôles d’accès stricts et les outils de détection d’intrusion, également recommandés dans ce type de contexte, conservent leur utilité. Ils peuvent aider à réduire la surface d’attaque ou à repérer une activité anormale. Toutefois, ils ne remplacent pas une conception prudente de l’agent : l’idéal est d’empêcher qu’un contenu non fiable puisse atteindre une action critique sans contrôle.

Ce qu’il faut surveiller dans les agents de codage

La correction de CVE-2025-54135 répond au scénario identifié dans Cursor, mais AimLabs souligne que la logique d’attaque n’est pas propre à un seul produit. Les modèles de langage sont conçus pour interpréter des instructions en langage naturel. Cette force devient une faiblesse lorsque des instructions malveillantes sont mélangées à des données censées n’être que du contexte.

Le développement des agents autonomes rend cette question plus urgente. Plus un assistant peut agir, plus il devient nécessaire de lui imposer des limites claires : isoler les opérations sensibles, tracer les changements de configuration, demander une confirmation pour les actions à risque et distinguer les ordres de l’utilisateur des données récupérées en ligne ou dans les outils de travail.

Pour les utilisateurs, la leçon est simple : un assistant de code connecté à des services externes doit être considéré comme un composant à privilèges, non comme une simple interface de conversation. Le gain de productivité est réel, mais il doit s’accompagner d’une politique de mises à jour, de permissions et de surveillance adaptée à son pouvoir d’action.