Par Tsuky 
Le code semblait appartenir à une extension familière aux développeurs. Son nom, son interface et ses principales fonctions correspondaient à Claude Code, l'outil d'Anthropic permettant d'utiliser un assistant IA dans un environnement de programmation. Mais une modification du JavaScript exécuté au démarrage transformait cette extension en outil d'intrusion.
Pendant environ onze heures, le 29 octobre, des utilisateurs de Cursor ont pu recevoir ce package modifié depuis la marketplace d'extensions intégrée à l'éditeur. Le code malveillant cherchait à autoriser l'accès SSH à la machine, puis à ouvrir un chemin de communication persistant vers un serveur externe.
L'incident concerne une attaque de la chaîne d'approvisionnement logicielle : un composant distribué comme une extension légitime a été altéré avant d'arriver chez certains utilisateurs. Ce mécanisme ne nécessite pas de convaincre chaque développeur d'exécuter volontairement un fichier suspect. L'installation ou une mise à jour automatique de l'extension pouvait suffire à déclencher le chargement du code.
Onze heures d'exposition sur la marketplace Cursor
Cursor situe la période de distribution entre 2 h 27 et 13 h 35, heure du Pacifique, le 29 octobre 2026. Les versions 2.1.312 et 2.1.313 de l'extension anthropic.claude-code figurent dans l'avis de sécurité actualisé.
L'entreprise estime que jusqu'à 5 000 utilisateurs ont pu être affectés. Ce plafond décrit l'exposition potentielle : il ne prouve pas que 5 000 ordinateurs ont subi une intrusion réussie, ni que des informations confidentielles ont été dérobées sur chacun d'eux.
Le package malveillant n'a pas été développé par Anthropic. Microsoft indique avoir vérifié que les versions falsifiées n'ont pas été distribuées depuis la marketplace officielle Visual Studio de Microsoft ni depuis les canaux npm officiels concernés.
Anthropic a également indiqué à Microsoft que ses propres systèmes n'avaient pas été compromis. Les éléments disponibles limitent l'incident à la chaîne de distribution utilisée par Cursor.
Cette distinction évite de présenter toutes les installations de Claude Code, ou l'ensemble des utilisateurs de Visual Studio Code, comme victimes de la même attaque.
Une extension apparemment fonctionnelle, avec du JavaScript supplémentaire
L'analyse du code montre que les attaquants ont inséré un chargeur JavaScript malveillant avant le fonctionnement habituel de l'extension.
Le code s'exécutait lorsque le module était chargé. L'utilisateur n'avait pas besoin d'envoyer une instruction particulière à Claude Code pour déclencher les premières opérations.
Le programme pouvait interroger l'environnement local, modifier certains fichiers et lancer des commandes du système d'exploitation. Pendant ce temps, les fonctions ordinaires de l'extension restaient disponibles, ce qui pouvait réduire les signes visibles d'une anomalie.
Les informations collectées comprenaient notamment le nom de la machine, celui de l'utilisateur, le système d'exploitation, son architecture, les répertoires de travail et l'adresse électronique configurée pour Git.
Le code recherchait également des variables d'environnement dont les noms évoquaient des secrets, par exemple des clés API ou des identifiants d'accès à des services cloud.
Microsoft précise un point essentiel : le chargeur analysé transmettait les noms des variables correspondantes, pas directement leurs valeurs. Cette collecte ne prouve donc pas, à elle seule, le vol des secrets qu'elles pourraient contenir.
Si l'attaquant obtenait ensuite un accès interactif à la machine, d'autres données pouvaient néanmoins devenir accessibles. L'analyse d'un poste affecté ne doit donc pas s'arrêter à la seule liste des informations envoyées par le chargeur initial.
La porte dérobée cherchait à utiliser SSH
Le mécanisme central reposait sur SSH, un protocole couramment utilisé par les développeurs et les administrateurs pour accéder à des machines distantes.
Le code tentait d'abord d'ajouter une clé publique contrôlée par l'attaquant au fichier d'autorisation SSH de l'utilisateur. Cette modification pouvait permettre à la personne possédant la clé privée correspondante de se faire reconnaître par le service SSH, si celui-ci était accessible et correctement configuré.
Le programme essayait ensuite d'activer le service SSH local et de lancer une connexion sortante vers un serveur distant.
Cette connexion devait établir un tunnel SSH inversé. Au lieu de demander à l'attaquant de se connecter directement à une machine potentiellement protégée par un pare-feu, le poste ciblé prenait l'initiative de communiquer avec l'infrastructure adverse.
Une fois le tunnel fonctionnel, l'attaquant aurait pu tenter d'accéder au service SSH local à travers cette liaison.
Il ne faut cependant pas confondre l'intention du code et l'obtention effective d'un accès. La réussite dépendait des droits de l'utilisateur, de l'état du serveur SSH local et de la configuration du serveur distant.
Des erreurs techniques ont limité l'attaque
L'un des éléments les plus importants du dossier concerne les défauts de programmation du malware.
Selon Cursor et les analyses spécialisées, la tentative d'activation du service SSH échouait dans de nombreuses configurations Windows et macOS ordinaires.
Sur macOS, certaines commandes nécessitant des privilèges administrateur ne fonctionnaient pas correctement lorsque l'éditeur était lancé avec les droits habituels de l'utilisateur.
Sur Windows, des incompatibilités dans la manière d'exécuter les commandes compliquaient également la mise en service de SSH.
Ces défauts ont probablement empêché un grand nombre d'accès interactifs. Ils ne signifient pas que le programme était inoffensif.
Le code pouvait encore ajouter une clé d'autorisation, créer des fichiers de persistance et transmettre certaines informations sur la machine.
Un poste dont le service SSH était déjà actif, ou un éditeur démarré avec des privilèges inhabituels, pouvait présenter un profil de risque différent.
L'ampleur des intrusions effectivement réussies reste à établir. Les informations publiques ne permettent pas de transformer le plafond de 5 000 utilisateurs potentiellement exposés en nombre confirmé de sessions SSH ouvertes par l'attaquant.
Le malware cherchait à survivre à la fermeture de Cursor
La menace ne se limitait pas à la durée d'exécution de l'éditeur.
Le programme installait ou tentait d'installer des mécanismes permettant de relancer le tunnel après une fermeture de session ou un redémarrage.
Sur macOS, il utilisait un LaunchAgent, mécanisme normalement destiné au démarrage de tâches associées à un compte utilisateur.
Sur Windows, il tentait de créer une tâche planifiée et prévoyait également un script dans le dossier de démarrage de l'utilisateur.
Microsoft documente aussi une logique de persistance Linux dans le chargeur analysé, même si l'avis principal de Cursor vise les packages distribués pour Windows et macOS.
Les scripts malveillants tentaient de rétablir la connexion à intervalles réguliers, approximativement toutes les soixante secondes après un échec.
Cette architecture explique pourquoi la désinstallation de l'extension ne constitue pas nécessairement une remédiation suffisante. Des fichiers et des mécanismes de démarrage pouvaient avoir été écrits en dehors du répertoire de l'extension.
Cursor a coupé la distribution et fait désactiver le serveur
Cursor annonce avoir retiré les versions falsifiées dès leur identification, avant de suspendre temporairement l'ensemble de sa marketplace par précaution.
L'entreprise indique avoir audité les autres extensions, renouvelé ses clés et reconstruit l'infrastructure du service avant sa remise en ligne.
Elle a également travaillé avec l'hébergeur de l'infrastructure utilisée par les attaquants pour rendre leur serveur inaccessible.
Cette désactivation interrompt le fonctionnement prévu des connexions vers cette destination. Elle ne supprime toutefois pas les éventuelles clés, scripts ou tâches déjà installés sur les ordinateurs des développeurs.
La fermeture d'un serveur de commande et de contrôle limite donc la capacité opérationnelle de l'attaque, sans démontrer à elle seule que toutes les machines affectées ont retrouvé un état sûr.
Comment vérifier si son ordinateur a été concerné
Le premier critère est le mode d'installation. Les utilisateurs doivent vérifier s'ils ont installé ou mis à jour l'extension Claude Code depuis la marketplace Cursor pendant la fenêtre du 29 octobre.
L'attention doit porter sur les versions 2.1.312 et 2.1.313, mentionnées dans les communications actualisées de Cursor et Microsoft.
Les équipes de sécurité peuvent ensuite rechercher les indicateurs techniques publiés dans les avis officiels.
Parmi ceux-ci figure une clé SSH ajoutée avec le commentaire svc-telemetry. Microsoft recommande de vérifier l'identité cryptographique de la clé, et non de supprimer aveuglément toute entrée dont le nom pourrait lui ressembler.
La recherche doit également couvrir les mécanismes de démarrage inhabituels, les connexions SSH sortantes, les processus associés et les fichiers de persistance documentés.
L'absence d'un indicateur unique ne suffit pas toujours à exclure toute exposition. Inversement, un nom de fichier ou de tâche rencontré isolément peut nécessiter une analyse avant d'être qualifié de malveillant.
Pour les entreprises, la vérification doit prendre en compte les journaux d'installation des extensions et les postes mis à jour automatiquement.
Supprimer l'extension ne suffit pas toujours
Cursor fournit des procédures et des scripts de remédiation adaptés aux plateformes concernées.
Microsoft recommande de préserver les éléments utiles à l'enquête avant de procéder au nettoyage lorsque des signes d'exécution du code malveillant sont observés.
Les opérations de remédiation peuvent comprendre le retrait de l'extension falsifiée, la suppression des clés SSH non autorisées, l'arrêt des processus suspects et la désactivation des mécanismes de persistance confirmés.
Un administrateur doit éviter de supprimer des clés SSH légitimes ou des tâches système uniquement parce qu'elles portent un nom ressemblant à un indicateur de l'attaque.
Si les investigations révèlent un accès à des identifiants ou si la confiance dans la machine ne peut pas être rétablie, la révocation des sessions et la rotation des secrets depuis un appareil sain deviennent nécessaires.
Dans certains cas, une reconstruction complète du poste peut être préférable à un nettoyage manuel difficile à vérifier.
Les scripts de remédiation doivent provenir de la communication officielle de Cursor et être examinés avant exécution, en particulier lorsqu'ils demandent des privilèges élevés.
Pourquoi les extensions d'éditeurs constituent une cible privilégiée
Les extensions d'outils de développement disposent souvent d'un accès important au poste de travail.
Elles peuvent lire les fichiers ouverts, interagir avec des projets logiciels et, selon leur architecture, exécuter du code ou appeler des commandes locales.
Cette capacité est indispensable à de nombreuses fonctions avancées, notamment les assistants de programmation capables de modifier un projet ou de lancer des tests.
Elle devient dangereuse lorsqu'une extension distribuée par un canal supposé fiable est remplacée par une version malveillante.
Le nom d'un éditeur connu ou l'identifiant d'un plugin populaire ne constituent pas, à eux seuls, une preuve d'intégrité du package installé.
La sécurité dépend également de l'authentification des éditeurs, des contrôles appliqués à la publication et des mécanismes de mise à jour.
Dans les entreprises, limiter les extensions aux fournisseurs approuvés et différer certaines mises à jour peut réduire l'exposition à une publication malveillante de courte durée.
Ces mesures ne suppriment pas tous les risques, mais elles peuvent donner aux équipes de sécurité du temps pour détecter un incident avant une diffusion massive.
Une attaque contre la distribution, pas une compromission démontrée d'Anthropic
L'affaire illustre une confusion fréquente dans les incidents de chaîne d'approvisionnement.
Le package utilisait le nom et l'identifiant d'une extension connue, mais cela ne signifie pas que son éditeur d'origine avait publié le code malveillant.
Anthropic affirme ne pas être à l'origine des versions concernées. Microsoft indique que les canaux officiels vérifiés n'ont pas distribué les packages falsifiés.
La question de savoir précisément comment les attaquants sont parvenus à diffuser ces versions sur la marketplace Cursor reste distincte de l'analyse de leur fonctionnement.
Les éléments publics confirment l'altération de la distribution et le comportement malveillant du code. Ils n'établissent pas encore une attribution définitive à un groupe d'attaquants ni la cause initiale complète de la compromission.
Le principal risque persiste après la fin de la fenêtre d'attaque
La publication du 30 octobre apporte une information essentielle aux développeurs : la menace ne disparaît pas automatiquement parce que les versions malveillantes ont été retirées et que le serveur adverse est hors ligne.
Les postes ayant exécuté le chargeur peuvent conserver des modifications locales.
Les équipes concernées doivent donc distinguer trois questions : le package a-t-il été installé, son code s'est-il exécuté et un accès non autorisé a-t-il réellement fonctionné ?
Les réponses peuvent être différentes d'une machine à l'autre.
L'incident rappelle enfin que les outils de développement assistés par IA s'appuient sur des écosystèmes d'extensions aussi sensibles que ceux des logiciels traditionnels.
Les capacités nouvelles des assistants ne remplacent pas les règles élémentaires de sécurité de la chaîne d'approvisionnement. Dans cette affaire, le véritable enjeu n'est pas une erreur commise par un modèle de langage, mais la confiance accordée à un logiciel installé au cœur de l'environnement de développement.