Une extension Claude Code piégée sur Cursor a tenté d’installer des portes dérobées SSH pendant environ 11 heures, sans vol de crypto signalé

Une copie piégée de l’extension Claude Code, publiée sous le nom d’Anthropic sur la place de marché de Cursor elle-même, a tenté d’installer une porte dérobée SSH sur des machines de développeurs pendant environ 11 heures le 29 octobre 2026, selon un avis de sécurité de Cursor. Aucun vol de crypto n’est signalé, et aucune source ne dit qu’un portefeuille a été touché ni que la valeur d’un secret a quitté une machine.

Les versions touchées sont Anthropic.claude-code 2.1.312 et 2.1.313 pour Windows et macOS, diffusées via la Cursor VS Code Extension Marketplace entre 2 h 27 et 13 h 35 environ, heure du Pacifique. Cela fait de 09 h 27 à 20 h 35 UTC : les États-Unis étaient encore à l’heure d’été (UTC-7) ce jeudi-là, et The Register donne les mêmes heures UTC. Selon Cursor, ces versions ne sont « pas développées par Anthropic ».

Les développeurs crypto ont de bonnes raisons de regarder de plus près s’ils ont utilisé ces versions. CryptoSlate relève que les conseils de Cursor s’étendraient aux identifiants de développement ou de services financiers du compte concerné, s’blockchain that runs exactly as written when it is called, holding and moving funds according to its code, without an intermediary able to change the outcome.">smart contract holding reserves of two or more tokens, supplied by users, that a decentralized exchange uses to execute trades automatically at a price set by a formula.">pool diverge, compared with simply holding the same tokens in a wallet. It becomes permanent when the provider withdraws.">il y en a. Sur les éléments publiés, le code visait un accès à distance plutôt que des fonds, et le nettoyage va au-delà de l’extension : Cursor prévient que « désinstaller l’extension peut ne pas suffire ».

Comment fonctionnait la porte dérobée de l’extension Claude Code sur Cursor

L’éditeur de sécurité des postes de travail Phorion, qui a repéré la porte dérobée en premier selon The Register, a publié une analyse détaillée, et l’avis de Cursor la recoupe sur les étapes principales. BleepingComputer cite aussi des chercheurs d’OpenSourceMalware. Du code supplémentaire était placé en tête du fichier extension.js minifié et s’exécutait dès que Node chargeait ce fichier, avant l’activation de l’extension : personne n’avait rien à cliquer. D’après Cursor et Phorion, il enchaînait ensuite ces étapes :

1. Il ajoutait une clé Ed25519 contrôlée par l’attaquant, avec le commentaire svc-telemetry, au fichier authorized_keys de l’utilisateur.
2. Il tentait d’activer le service SSH local. Aucune faille n’est exploitée ici, donc il faut des droits d’administrateur ou un sudo sans mot de passe. Cursor indique que l’extension n’a pas ces droits sur la plupart des machines macOS et Windows, où cette étape échoue.
3. Il tentait d’ouvrir un tunnel SSH inversé vers le serveur 134.209.82.225, en réessayant environ toutes les 60 secondes et détaché de l’éditeur : fermer Cursor ne l’arrêtait donc pas.
4. Il installait de la persistance : un LaunchAgent sur macOS, une tâche planifiée nommée SysMon sur Windows avec le dossier Démarrage en secours, et une entrée cron @reboot sur Linux.
5. Il envoyait un rapport unique sur la machine au même serveur, en HTTP non chiffré.

Un tunnel inversé va dans le sens contraire d’une connexion à distance ordinaire. La machine infectée appelle le serveur de l’attaquant, et c’est cette connexion sortante qu’un opérateur utiliserait ensuite pour revenir à l’intérieur. L’avis de Cursor limite les paquets touchés à Windows et macOS, bien que ses indicateurs listent aussi des fichiers Linux et que Phorion décrive un chemin de code Linux.

Le code contenait aussi des bogues, a relevé Phorion. Sur macOS, le script vérifie l’état de Remote Login sans droits root, reçoit une erreur au lieu du mot « Off » et saute l’étape d’activation, mais la clé et la persistance se retrouvent tout de même sur le disque. L’accès entrant par le tunnel échoue alors, sauf si Remote Login était déjà activé. Phorion insiste : ce n’est pas une protection, puisque la porte dérobée fonctionne si le réglage est activé plus tard. Sous Windows, une fonction d’aide écrit en dur /bin/sh, ce qui, selon la firme, a peu de chances de marcher sur une installation standard. Sous Linux, un test défaillant sur crontab peut effacer les tâches cron existantes de l’utilisateur si le script est relancé.

Cursor en conclut que, sur les machines où l’activation de SSH a échoué, l’attaquant « n’aurait pas pu se connecter par le tunnel ». Le même passage précise que l’extension a tout de même ajouté la clé, installé la persistance et envoyé des informations sur la machine, et il demande aux utilisateurs de suivre les étapes de remédiation dans tous les cas.

Le rapport contenait des noms de variables d’environnement, pas leurs valeurs

Phorion liste le contenu du rapport : nom de la machine, nom d’utilisateur, système d’exploitation et architecture, dossiers personnel et de travail, adresse e-mail Git globale, adresse IP publique, indicateurs d’état de chaque étape, et jusqu’à 40 noms de variables d’environnement contenant KEY, TOKEN, SECRET, PASS, AWS ou GCP. La liste de Cursor concorde sur les noms, les dossiers de travail, l’e-mail Git et l’IP publique.

Phorion est explicite : le rapport n’a pris que les noms, la balise « n’exfiltre pas les valeurs des secrets eux-mêmes », écrit-il. Aucune source consultée pour cet article ne dit qu’une valeur a été envoyée.

Les noms en disent pourtant long. Phorion y voit un inventaire qui aide un opérateur à choisir les machines à traiter en priorité. Prenons deux noms que nous avons inventés pour l’exemple et qui n’apparaissent dans aucune source : une variable appelée DEPLOYER_PRIVATE_KEY ou EXCHANGE_API_SECRET signalerait une machine qui mérite un examen plus poussé, même si le rapport n’en porterait que le nom.

Cette limite vaut pour le rapport, pas pour ce que la porte dérobée a pu permettre ensuite. Cursor le dit lui-même : « La collecte limitée de variables d’environnement n’exclut pas un accès ultérieur aux identifiants via la porte dérobée. » BleepingComputer note que le script ne vole pas directement d’identifiants et y voit le signe que les attaquants comptaient collecter des données sensibles à la main une fois entrés. Aucune source consultée ne rapporte un cas d’un tel accès.

Comment le paquet a atteint la place de marché reste inexpliqué

L’avis de Cursor ne dit pas comment le paquet piégé a pu être publié sous le nom d’Anthropic. The Register a indiqué le 30 octobre que, hors la déclaration ci-dessous, ni Cursor ni Anthropic n’avaient commenté ce point. BleepingComputer a listé la même question sans réponse, ainsi que celle de savoir si les systèmes de Cursor ou d’Anthropic avaient été compromis. Aucune source consultée ne nomme non plus d’attaquant.

La position d’Anthropic nous parvient de seconde main. The Register a rapporté que Felix Rieseberg, membre de l’équipe technique d’Anthropic, a écrit sur X : « Nous travaillons avec Cursor sur cet incident, mais il ne s’agit pas d’une compromission des systèmes d’Anthropic ni des ordinateurs portables de ses employés. » D’après le même article, il a ajouté que « Un acteur malveillant a utilisé un accès à la place de marché de Cursor pour publier une copie piégée » de l’extension, qu’Anthropic n’a « ni conçue ni publiée », que les versions de ses canaux officiels n’étaient pas touchées et que seuls les utilisateurs de Cursor l’étaient. Coindaro n’a pas lu le message lui-même.

C’est le récit d’Anthropic, et aucune source consultée ne le confirme de façon indépendante. Il laisse aussi ouverte la question de savoir comment l’accès à la place de marché a été obtenu, et par qui. Reuters, dans une dépêche reprise par le Gulf Daily News, a indiqué qu’Anthropic n’avait pas répondu immédiatement à une demande de commentaire, et BleepingComputer a dit avoir contacté les deux entreprises et mettre son article à jour si elles répondaient.

The Register précise que le message répondait à des figures de la cybersécurité qui avaient évoqué une brèche chez Anthropic ; le média ne les nomme pas et n’expose pas leurs preuves. L’avis de Cursor ne contient aucune déclaration d’Anthropic. Phorion qualifie la fiche d’extension officielle sur la Cursor Marketplace, et aucune source consultée n’explique qui contrôlait la publication sur cette place de marché.

Cursor décrit sa propre réponse dans l’avis. Il a retiré la version malveillante, bloqué toute diffusion supplémentaire et fermé temporairement la place de marché. Il a ensuite audité les accès, affirme qu’aucune autre extension n’a été altérée, changé ses clés, reconstruit la place de marché et l’a rouverte. Il a aussi travaillé avec l’hébergeur et indique que le serveur de l’attaquant est hors ligne. Il ne fait état d’aucune preuve que d’autres versions de l’extension ou la distribution officielle aient été touchées. Comme pour le récit d’Anthropic, ce sont des déclarations de l’entreprise elle-même. Un serveur hors ligne ne nettoie pas une machine pour autant : d’après le code décrit plus haut, la clé et les tâches de relance restent en place tant que personne ne les retire.

Le périmètre a bougé pendant les deux premiers jours, et les articles plus anciens peuvent donc se tromper. Les premiers comptes rendus citaient npm, Open VSX et la Visual Studio Code Marketplace de Microsoft ; BleepingComputer indique qu’il a ensuite été confirmé que Cursor était la seule source. Phorion a corrigé son propre article pour nommer la place de marché de Cursor le 30 octobre à 09 h 13 UTC. Il ne citait d’abord que la 2.1.313 et a ajouté la 2.1.312 le 31 octobre à 00 h 43 UTC, après la mise à jour de l’avis de Cursor le 30 octobre à 11 h 30, heure du Pacifique (18 h 30 UTC). The Register et BleepingComputer ne donnent toujours que la 2.1.313.

Le nombre de personnes touchées n’est pas établi. Reuters a rapporté le 30 octobre que Cursor disait jusqu’à 5 000 utilisateurs touchés. The Register et BleepingComputer écrivent « jusqu’à 5 000 développeurs » sans source, le premier parlant d’infectés et le second d’exposés. L’avis de Cursor, que nous avons rouvert le 2 novembre, ne donne aucun chiffre : ce nombre reste donc non vérifié.

Que vérifier : les étapes de Cursor pour les machines concernées

Les conseils de Cursor valent pour toute personne ayant installé ou mis à jour ces versions depuis sa place de marché, sous macOS ou Windows, pendant la fenêtre en cause. Selon Cursor, la clé et la persistance ont été installées même là où l’activation de SSH a échoué : une étape SSH ratée n’est donc pas une raison de sauter la vérification. En résumé, l’avis demande aux utilisateurs de :

1. Chercher la clé. Sous macOS, Cursor donne cette commande : grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "svc-telemetry key found" || echo "No key found; machine not impacted". Sous Windows, sa vérification est une recherche PowerShell dans les fichiers authorized_keys, reproduite dans l’avis.
2. Chercher les indicateurs publiés dans les journaux des postes, du réseau et des installations d’extensions.
3. Isoler toute machine qui montre que la charge a été exécutée ou que la porte dérobée a été installée.
4. Supprimer la clé non autorisée, la persistance et les processus de tunnel, puis décider s’il faut reconstruire la machine.
5. Renouveler les identifiants et les sessions accessibles depuis les machines touchées, depuis un système de confiance.

Si la clé est trouvée, Cursor considère la machine comme touchée : les étapes 3 à 5 s’appliquent, tout comme son script de nettoyage. Il en existe un pour macOS, à lancer avec l’utilisateur concerné et non en root, et un pour Windows, à lancer depuis PowerShell en administrateur. Chacun se termine avec un code non nul si quelque chose subsiste. L’avis ne donne ni vérification ni script pour Linux ; la liste de remédiation de Phorion couvre les éléments Linux. Les questions vont à [email protected].

Les principaux indicateurs ci-dessous viennent de l’avis de Cursor, et l’analyse de Phorion les recoupe. Les empreintes de fichiers et celles des clés SSH figurent dans l’avis. Phorion conseille de vérifier l’empreinte en plus du commentaire.

Deux services que le code utilisait pour trouver l’IP publique, ifconfig.me et api.ipify.org, sont légitimes et ne prouvent rien à eux seuls. Pour savoir si quelqu’un a réellement utilisé une porte dérobée, Phorion conseille de chercher dans les journaux SSH des connexions depuis 127.0.0.1 ou ::1 faites avec cette clé, car les sessions passées par le tunnel semblent venir de la machine elle-même. Il recommande aussi d’arrêter la boucle de relance /bin/sh et de vérifier que Remote Login n’a pas été activé de manière inattendue.

Les deux analyses divergent sur les identifiants. Cursor demande de renouveler tout ce que les machines touchées peuvent atteindre. Phorion lie ce renouvellement à l’activation de SSH ou à la preuve d’une connexion entrante. La consigne de Cursor est la plus stricte des deux.

Nos propres conseils aux développeurs crypto, en plus de ceux de Cursor

Cette section est celle de Coindaro, pas de Cursor ni de Phorion, et il s’agit d’hygiène générale, pas de réponse à incident. Elle vaudrait avec ou sans cet incident.

• Gardez les phrases de récupération et les clés privées qui contrôlent des fonds réels hors des machines de développement, comme le décrit notre guide sur la sécurité de la seed phrase.
• Utilisez des clés jetables pour les tests, afin qu’une clé de test divulguée ne protège rien de valeur.
• Donnez aux clés API d’exchange les droits les plus étroits que la tâche permet, et laissez les retraits désactivés lorsque la plateforme offre ce choix.
• Téléchargez tout script de nettoyage depuis la page de l’éditeur, jamais depuis une copie qui circule dans un chat ou un forum.

Un canal de confiance de nouveau, mais aucune perte signalée cette fois

Coindaro a couvert plusieurs attaques récentes passées par un tiers plutôt que par une blockchain, le schéma exposé dans notre guide sur les endroits où les piratages crypto ont vraiment lieu. Ce cas partage la voie d’entrée mais pas, à ce stade, le résultat. Les chiffres du tableau sont ceux rapportés dans chacun de nos articles précédents.

Fearless Wallet est le plus proche dans la forme, puisque les deux sont des extensions, mais la différence compte : celle-là prenait directement des clés privées, alors que celle-ci, d’après les éléments disponibles, a pris des noms de variables d’environnement et tenté d’ouvrir une porte. CryptoSlate dit qu’aucun des deux avis qu’il a examinés n’établit un vol de crypto ni un ciblage propre à la crypto. Les machines de développeurs étaient ici la cible, et aucune source consultée ne relie l’incident à un groupe connu ou à d’autres piratages récents.

Les questions auxquelles personne n’a encore répondu

Plusieurs questions restent ouvertes au 2 novembre. Ni Cursor ni Anthropic n’a expliqué comment l’attaquant a obtenu l’accès pour publier le paquet, et aucun nombre d’installations n’est confirmé à la source. Aucune source consultée ne rapporte une machine réellement pénétrée par un tunnel, ni un identifiant dérobé. Phorion dit ne pas comprendre pourquoi le rapport est aussi parti vers une adresse locale, 127.0.0.1 sur le port 8099.

Cursor a mis à jour son avis pour la dernière fois le 30 octobre et Phorion son analyse le 31 octobre. Aucune des deux pages n’affichait rien de plus récent lors de notre vérification du 2 novembre.