Extension VS Code piégée : 5 000 développeurs infectés par une backdoor SSH via le marketplace Cursor — êtes‑vous concerné ?

Une extension malveillante diffusée sur le marketplace de Cursor a infecté des milliers d’utilisateurs : c’est le type d’attaque en chaîne (« supply‑chain ») qui inquiète particulièrement les entreprises et les développeurs. L’extension incriminée, « Claude Code VS Code » en version 2.1.312 et 2.1.313, contenait un loader JavaScript capable d’installer une backdoor SSH sur machines Windows et macOS. Entre l’apparition du paquet compromis et son retrait, environ 5 000 installations ont été enregistrées.

Comment la compromission s’est‑elle matérialisée ?

Selon les éléments publiés par Cursor, la version malveillante est restée disponible pendant une fenêtre d’environ 11 heures le 29 octobre. Le paquet intégrait un code qui, une fois l’extension exécutée dans l’IDE Cursor (basé sur VS Code), réalisait plusieurs actions automatisées : collecte d’informations système (nom d’hôte, utilisateur, OS, architecture, chemins d’accès, variables d’environnement, adresse e‑mail Git, IP publique), ajout d’une clé SSH, activation d’un service SSH local et ouverture d’un tunnel SSH inversé (reverse tunnel) si l’IDE tournait avec des privilèges élevés.

Pour assurer la persistance, la backdoor utilisait les mécanismes natifs des systèmes : LaunchAgent sous macOS et une tâche planifiée sous Windows. Le tunnel était rétabli toutes les 60 secondes, garantissant une fenêtre d’accès régulière à la machine compromise pour l’attaquant distant.

Portée et responsabilités : qui est concerné ?

Cursor (récemment acquis par SpaceX) a réagi en retirant l’extension et en mettant temporairement hors ligne son marketplace. L’entreprise indique que le paquet malveillant n’a pas été développé par Anthropic (éditeur de Claude) et que les autres extensions n’ont pas été compromises. Anthropic, contacté, a confirmé qu’aucun système interne ni notebook de ses employés n’avait été affecté.

Cependant, la communication publique laisse encore des zones d’ombre : Cursor n’a pas détaillé précisément la faille qui a permis l’upload du paquet malveillant sur le marketplace. S’agit‑il d’un compte développeur compromis, d’une vulnérabilité dans le processus de validation des extensions, ou d’une compromission interne ? L’absence de transparence complète limite la capacité des équipes de sécurité à tirer des enseignements opérationnels.

Quelles sont les actions que doivent entreprendre les utilisateurs ?

Les utilisateurs ayant installé la version 2.1.312 ou 2.1.313 doivent :

vérifier et désinstaller immédiatement l’extension compromise ;

mettre à jour vers la version « propre » 2.1.314 si l’extension est nécessaire ;

contrôler les clés SSH présentes sur la machine (authorized_keys, services SSH configurés) ;

rechercher et supprimer toute tâche planifiée (Windows) ou LaunchAgent suspect (macOS) ;

analyser les logs réseau pour détecter des connexions sortantes inhabituelles et, le cas échéant, isoler la machine.

Pour les organisations, il est impératif d’appliquer une réponse coordonnée : inventorier les postes de développement ayant installé l’extension, évaluer l’exposition (privilèges administrateurs, accès aux dépôts Git, secrets locaux), procéder à un audit complet et envisager une rotation des clés SSH si un accès a pu être établi.

Pourquoi ces attaques supply‑chain sont‑elles si dangereuses ?

La chaîne d’approvisionnement logicielle repose sur la confiance : des millions de développeurs installent quotidiennement des extensions et bibliothèques depuis des sources officielles. Quand un acteur malveillant compromet un point de distribution légitime, il contourne la plupart des protections classiques (antivirus, filtrages réseau de premier niveau) et bénéficie d’un effet multiplicateur massif. L’incident Cursor illustre ce risque : un paquet signé ou publié via un canal officiel profite de la présomption de sécurité et touche rapidement un grand nombre de cibles.

Le volet technique : reverse SSH et persistance

Le choix technique de la backdoor est significatif. L’ouverture d’un tunnel SSH inversé permet à l’attaquant d’établir une connexion chiffrée vers une machine compromise située derrière un NAT ou un pare‑feu, sans nécessiter de ports entrants ouverts côté cible. La persistance via LaunchAgent ou tâches planifiées garantit la résilience du point d’accès, rendant la suppression délicate si le nettoyage initial est incomplet.

Mesures préventives et bonnes pratiques

Limiter les privilèges : exécuter l’IDE et les extensions avec le moins de privilèges possible pour réduire l’impact d’une compromission.

Surveiller les modifications de configuration : mise en place d’alertes sur création de services, tâches planifiées ou nouveau contenu dans authorized_keys.

Adopter une stratégie de gestion des extensions : whitelist, revue périodique, politiques d’installation contrôlées en contexte professionnel.

Maintenance du marketplace : les éditeurs de plateformes doivent renforcer les contrôles d’intégrité des paquets, la traçabilité des upload et les mécanismes d’authentification des contributeurs.

Quel enseignement tirer pour l’écosystème des outils de développement ?

Au‑delà de l’incident Cursor, il s’agit d’un nouvel appel à la prudence pour l’écosystème : renforcer la sécurité des chaînes de distribution, améliorer la transparence des fournisseurs et développer des outils d’analyse automatisée des paquets avant publication. Les équipes de sécurité doivent intégrer la surveillance des dépendances et extensions à leur plan de défense — pas seulement les applications « de production », mais aussi les postes des développeurs, souvent point d’entrée privilégiés pour des attaques ultérieures.

Cet épisode rappelle que la confiance dans les canaux officiels n’exclut pas la vigilance : le compromis d’un simple paquet peut suffire à ouvrir une porte approfondie dans des environnements sensibles. Les entreprises et les utilisateurs doivent traiter ces incidents comme des alertes stratégiques et adapter leurs pratiques en conséquence.