Cursor : un dépôt de code piégé suffit à exécuter du code malveillant

Ce 14 juillet 2026, Dark Reading publie une alerte qui concerne directement tous les développeurs qui utilisent des éditeurs de code assistés par IA : l'éditeur Cursor peut, dans certaines conditions, exécuter du code malveillant dès l'ouverture d'un dépôt piégé, sans qu'aucune action supplémentaire ne soit nécessaire de la part du développeur.

Précision importante avant d'aller plus loin : l'article source n'a pas pu être récupéré intégralement au moment de la rédaction. Ce qui suit s'appuie donc sur le titre de l'alerte, sur la documentation officielle de Cursor, et sur les mécanismes de ce type d'attaque déjà documentés sur les éditeurs de code construits à partir de Visual Studio Code. Pour le détail technique complet de la preuve de concept, direction l'article original de Dark Reading, en lien en fin d'article.

Cursor en quelques mots, pour qui découvre

Cursor est un éditeur de code construit sur la base de Visual Studio Code, enrichi d'un agent IA capable de lire un projet, de proposer des modifications, et surtout d'exécuter des commandes (installation de dépendances, lancement de scripts, appels shell) pour le compte du développeur. Cette capacité d'automatisation fait le succès de l'outil auprès des équipes qui veulent aller vite. Elle transforme aussi, mal encadrée, un simple clonage de dépôt en surface d'attaque.

Le vecteur d'attaque décrypté

Le principe général de ce type d'attaque n'est pas propre à Cursor : il concerne tout éditeur qui accepte d'exécuter automatiquement des instructions présentes dans le code source d'un projet qu'on vient d'ouvrir. Plusieurs points d'entrée sont généralement en cause sur ce type d'éditeur.

• Les tâches auto-lancées. Un fichier de configuration de tâches, héritage direct de Visual Studio Code, peut être paramétré pour s'exécuter automatiquement à l'ouverture du dossier, avant même que le développeur ait lu une seule ligne de code.
• Les règles destinées à l'agent IA. Cursor lit des fichiers de règles à la racine du dépôt pour orienter le comportement de son agent. Un dépôt piégé peut y glisser des instructions qui poussent l'agent à exécuter des commandes pour le compte de l'attaquant, en particulier si le mode d'exécution automatique de l'agent est actif.
• Les extensions et serveurs externes recommandés. Un dépôt peut aussi suggérer l'installation d'une extension ou pointer vers un serveur externe, chargé sans confirmation explicite si les protections par défaut ont été désactivées.

Le point commun à ces trois vecteurs : ils s'activent au moment même où vous ouvrez le dossier dans l'éditeur, pas au moment où vous lancez volontairement un script. C'est ce qui rend ce type d'attaque particulièrement sournois pour un développeur pressé qui clone un dépôt trouvé sur un forum, un article technique ou un test de recrutement.

Ce que ça change pour vous, développeur ou PME

Pour une agence ou une PME qui gère du code client, des dépôts open source récupérés, ou des tests techniques envoyés par des candidats externes, ce type de vecteur est loin d'être théorique. Un développeur qui ouvre par réflexe un dépôt reçu par email ou un template trouvé en ligne s'expose potentiellement à une exécution de code sur sa machine, avec les accès que cette machine porte au quotidien : identifiants git, tokens cloud, clés SSH.

Le risque n'est pas propre à Cursor. Visual Studio Code a mis en place depuis plusieurs années un mécanisme de Workspace Trust précisément pour limiter l'exécution automatique de code dans un dossier non vérifié. La question à se poser sur un éditeur enrichi d'IA est de vérifier si cette protection reste active par défaut, et si les fonctionnalités d'agent autonome ne viennent pas la contourner.

Les réflexes à adopter avant d'ouvrir un dépôt inconnu

Quelques habitudes simples réduisent fortement l'exposition, sans renoncer au confort apporté par l'IA.

• Inspectez avant d'ouvrir. Clonez le dépôt sans l'ouvrir dans votre éditeur, et parcourez d'abord les fichiers de configuration sensibles : dossier de tâches et d'extensions, fichiers de règles d'agent, configuration de serveurs externes.
• Désactivez l'exécution automatique sur les dépôts non vérifiés. Gardez le mode restreint ou Workspace Trust actif, et ne passez en mode agent autonome qu'une fois le code relu.
• Isolez le premier passage. Une machine virtuelle jetable, un conteneur dédié ou un environnement de développement conteneurisé sans accès à vos identifiants personnels limite les dégâts en cas de code hostile.
• Séparez les identités sensibles. Évitez d'ouvrir un dépôt douteux depuis une session qui contient vos tokens cloud, vos clés SSH de production ou vos accès administrateur.
• Maintenez votre éditeur à jour. Les correctifs de sécurité sur ces mécanismes d'automatisation sortent régulièrement, et une version à jour reste la première ligne de défense.

Notre lecture chez CZSyn

Cette alerte illustre surtout un changement de nature du risque avec l'arrivée des éditeurs de code IA. Historiquement, le code source d'un dépôt était un objet passif : il fallait l'exécuter volontairement pour qu'il fasse quoi que ce soit. Avec des éditeurs capables d'agir seuls sur instruction du contenu même du dépôt, le simple fait d'ouvrir un dossier devient une action potentiellement risquée. C'est un changement de posture à intégrer, pas une raison de renoncer à ces outils : ils apportent un vrai gain de productivité, à condition de garder la main sur ce qu'ils sont autorisés à exécuter sans validation.

Chez CZSyn, quand nous auditons un poste de développement ou une chaîne de contribution externe (freelances, tests techniques, dépôts open source intégrés), la vérification des permissions par défaut des éditeurs IA fait désormais partie de nos points de contrôle standards, au même titre que la revue des dépendances.

Sources primaires

• Dark Reading, « Cursor IDE Malicious Code Poisoned Repos ».
• Documentation officielle Cursor, docs.cursor.com.
• Visual Studio Code, documentation officielle, « Workspace Trust », mécanisme de sécurité repris par les éditeurs forkés de VS Code.