Le 29 octobre 2026, entre 17 h 27 et 4 h 35 le lendemain, heure de Pékin (soit environ 11 heures), l’extension officielle Claude Code du catalogue Cursor a été remplacée par une version malveillante contenant une porte dérobée SSH. Les versions concernées sont les 2.1.312 et 2.1.313, sur macOS arm64 et Windows x64. Selon Cursor, jusqu’à 5 000 utilisateurs l’auraient téléchargée ou installée par mise à jour automatique.
Il ne s’agissait pas d’une fausse extension glissée dans le catalogue. Le paquet installé portait le nom officiel Anthropic.claude-code, et son interface comme ses fonctionnalités semblaient normales. Beaucoup d’utilisateurs ignorent donc l’avoir installé. C’est aussi pourquoi désinstaller l’extension ou la mettre à jour ne suffit pas. Le code malveillant a déjà ajouté une clé publique SSH, configuré un script persistant qui se lance au démarrage et envoyé des informations sur la machine à l’attaquant. Pour terminer le nettoyage, il faut faire trois choses : supprimer la clé, supprimer le mécanisme de persistance et renouveler les identifiants.
L’essentiel : cet article détaille 5 étapes selon la logique « ce que vous allez voir → quoi faire → comment vérifier que cela a fonctionné ». Même sans expertise en sécurité, un développeur peut ainsi effectuer les vérifications et le nettoyage en une trentaine de minutes, renouvellement de la clé API APIYI compris.
Légende : la fenêtre malveillante a duré environ 11 heures ; la version 2.1.314 est la première version saine publiée après l’incident.
Pas de panique : que s’est-il passé avec l’extension Claude Code compromise ?
Commençons par les faits. Toutes les informations du tableau ci-dessous proviennent de l’avis de sécurité de Cursor et des réponses publiques de membres d’Anthropic.
| Point | Faits |
|---|---|
| Incident | L’extension Anthropic.claude-code du marketplace Cursor a été modifiée pour y implanter une porte dérobée SSH persistante |
| Versions concernées | 2.1.312 et 2.1.313 (Cursor a ajouté la version 2.1.312 lors de la mise à jour de son avis le 30 octobre) |
| Plateformes | macOS (darwin-arm64), Windows (win32-x64) ; le code contient aussi une branche Linux |
| Période d’exposition | Le 29 octobre de 02 h 27 à 13 h 35, heure du Pacifique, soit du 29 octobre à 17 h 27 au 30 octobre à 04 h 35, heure de Pékin |
| Étendue | Selon Cursor, jusqu’à 5 000 utilisateurs ont pu être exposés. Il s’agit d’une estimation des personnes exposées, pas d’un nombre d’infections confirmées |
| Situation actuelle | Les versions malveillantes ont été retirées ; le marketplace a été fermé, reconstruit et audité avant de rouvrir ; Cursor indique que l’hébergeur a mis hors ligne le serveur de l’attaquant |
| Versions saines | La version 2.1.314 est la première version saine ; au 31 octobre, la plus récente est la 2.1.316 |
Légende : capture de la page de l’avis de sécurité de Cursor (à ajouter lors de l’édition).
Plusieurs informations erronées ont circulé au début de l’incident. Voici trois points à rectifier :
- La version 2.1.312 figure elle aussi parmi les versions concernées. Cursor n’avait initialement annoncé que la version 2.1.313, avant d’ajouter la 2.1.312. Si vous avez installé la version 2.1.312 depuis le marketplace Cursor pendant la période d’exposition, vous devez aussi vérifier votre machine.
- Seul le marketplace Cursor a été compromis. Certains premiers articles indiquaient qu’Open VSX, le marketplace de Microsoft et npm étaient également touchés. Ces informations ont depuis été corrigées. Socket a audité l’historique des modifications du registre et n’a trouvé aucune trace de publication ou de suppression de la version 2.1.313.
- La version 2.1.313 n’a jamais été publiée sur les canaux officiels d’Anthropic. David Dworken, ingénieur sécurité chez Anthropic, indique que cette version n’est jamais apparue sur Open VSX, le marketplace officiel de VS Code ou un quelconque hébergement officiel d’Anthropic. Pour éviter toute confusion dans les numéros de version, la version officielle suivante est passée directement à 2.1.314.
On ne sait pas encore qui est responsable ni comment cette personne a obtenu les droits de publication. Selon Felix Rieseberg, d’Anthropic, ni les systèmes de l’entreprise ni les ordinateurs de ses employés n’ont été compromis : quelqu’un a utilisé un accès au marketplace Cursor pour publier la version modifiée. L’avis de Cursor n’explique pas comment l’attaquant a obtenu les droits de publication. Cursor avait ouvert les soumissions publiques à son marketplace en octobre, mais les communications officielles ne précisent pas s’il existe un lien avec cette compromission. Nous ne tirerons donc aucune conclusion à ce sujet. Pour les développeurs, mieux vaut d’abord vérifier sa machine que spéculer sur la cause.
Pourquoi même l’extension officielle Claude Code a pu être compromise
La première réaction est souvent : comment un paquet officiel peut-il être malveillant ? Pour le comprendre, il faut d’abord savoir comment fonctionnent les extensions d’IDE. Une extension s’exécute avec les permissions de l’IDE : elle peut lire et modifier votre code, les variables d’environnement et les fichiers de votre répertoire utilisateur. Son code s’exécute dès son chargement, sans que vous ayez besoin d’ouvrir une fenêtre de dialogue ni même de l’utiliser.
L’analyse de Phorion montre que le code malveillant était une fonction immédiatement invoquée (IIFE) de 66 lignes, insérée tout au début du fichier extension.js, avant le code normal de l’extension. Elle s’exécutait dès que Node chargeait le module, avant même le rappel activate habituel. Le fichier extension.js modifié pesait 3 692 922 octets, soit environ 7 Ko de plus que la version saine précédente. Il ne dépendait pas du hook postinstall de npm : il ne s’agissait donc pas d’un paquet npm piégé, mais d’une modification directe du code dans le paquet d’installation VSIX.
On peut faire une comparaison : ce n’est pas comme si quelqu’un avait glissé un faux médicament dans une pharmacie. C’est plutôt comme si une boîte de marque authentique, sur le rayon officiel, avait été remplacée par une version contenant une substance ajoutée. Le nom, l’emballage et le code-barres sont vrais ; seul le contenu a été altéré. Dans cet incident, le réflexe habituel qui consiste à « vérifier l’éditeur officiel » ne suffisait donc pas.
Légende : la chaîne de la porte dérobée compte six étapes ; désinstaller l’extension ne met fin qu’à la première.
Trois idées reçues reviennent souvent à propos de cet incident :
- « Un nom de paquet officiel garantit une build officielle » : ici, le nom du paquet et l’identité de publication étaient bien officiels, mais la build n’avait pas été produite par Anthropic. Open VSX propose aussi une version 2.1.312 : c’est une version saine, publiée le 27 octobre. Un même numéro de version peut donc correspondre à des sources et à des niveaux de sécurité différents.
- « Seule la version 2.1.313 pose problème » : la version 2.1.312 du marketplace de Cursor était elle aussi malveillante.
- « Désinstaller ou mettre à jour suffit à régler le problème » : l’avis de Cursor précise que la simple désinstallation de l’extension peut ne pas suffire, car la charge utile laisse derrière elle des scripts de persistance qui s’exécutent indépendamment.
Porte dérobée dans l’extension Claude Code : 5 étapes pour vérifier et nettoyer votre système
Suivez ces 5 étapes dans l’ordre. Les trois premières servent à vérifier le système, la quatrième à le nettoyer et la cinquième à terminer l’intervention. Pour chacune, vous trouverez les actions à effectuer et les critères de validation.
Légende : un processus en 5 étapes. Le remplacement des identifiants à la cinquième étape est indispensable.
① Vérifiez la version et la source de l’extension. Ouvrez le panneau des extensions de Cursor, recherchez Claude Code et vérifiez son numéro de version et son éditeur. Dans le terminal, examinez ensuite le dossier ~/.cursor/extensions/ (sous Windows : %USERPROFILE%\.cursor\extensions\) pour voir s’il contient des dossiers dont le nom comprend anthropic.claude-code-2.1.312 ou 2.1.313. Même si vous utilisez maintenant une version plus récente, la présence d’un ancien dossier indique que vous avez peut-être installé une version concernée pendant la période d’exposition.
② Vérifiez la clé publique svc-telemetry. Sous macOS et Linux, exécutez grep -n svc-telemetry ~/.ssh/authorized_keys. Sous Windows, vérifiez les deux fichiers %USERPROFILE%\.ssh\authorized_keys et C:\ProgramData\ssh\administrators_authorized_keys. Le code malveillant cherche la chaîne svc-telemetry dans le fichier : vérifier uniquement les commentaires ne suffit donc pas. Exécutez aussi ssh-keygen -lf ~/.ssh/authorized_keys pour afficher les empreintes de toutes les clés publiques et comparez-les une par une à celle de l’attaquant : SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk.
③ Vérifiez les mécanismes de persistance et les processus de tunnel. Les éléments à vérifier dépendent du système :
- macOS :
~/Library/LaunchAgents/com.apple.sysmond.plist,~/.config/.smt,~/.config/.smtk, ainsi que les fichiers.stk_*dans le dossier temporaire. Le nom de ce LaunchAgent le fait passer pour un composant système Apple, mais il s’agit en réalité d’un élément de démarrage au niveau de l’utilisateur. - Windows : exécutez
schtasks /query /tn SysMonpour vérifier la tâche planifiée ; cherchezsysmon.cmddans le dossier de démarrage, ainsi que%USERPROFILE%\.config\smt.cmdet%TEMP%\.stk_*. - Linux : exécutez
crontab -let cherchez une entrée contenant@rebootqui pointe vers~/.config/.smt. - Toutes les plateformes : vérifiez si des processus
sshouautosshont l’argument-R '*:0:localhost:22'.
| Étape | Action | Critère de validation |
|---|---|---|
| ① Source de l’extension | Vérifier le panneau des extensions et ~/.cursor/extensions/ |
Aucun dossier 2.1.312 / 2.1.313 ; version actuelle ≥ 2.1.314 |
| ② Clé publique | Rechercher svc-telemetry et comparer les empreintes |
Aucune correspondance dans les deux types de fichiers authorized_keys |
| ③ Persistance | Vérifier plist / SysMon / cron / processus de tunnel | Aucun fichier concerné et aucun processus ssh avec l’argument -R |
| ④ Nettoyage | Exécuter le script officiel de Cursor et mettre à jour | Le script se termine avec le code 0, puis les vérifications ①②③ ne révèlent plus rien |
| ⑤ Identifiants | Remplacer les identifiants Git, CI, cloud et SSH, ainsi que les clés API | Les anciens identifiants sont désactivés et les journaux d’appels ne présentent aucune anomalie |
④ Si vous êtes touché, exécutez le script officiel de nettoyage. Si le point ② ou ③ révèle un problème, suivez les instructions de Cursor. Sur macOS, téléchargez cursor.com/static/security/claude-code-extension/remediate-macos.sh, puis exécutez bash remediate-macos.sh sous le compte utilisateur concerné (sans utiliser root). Sur Windows, téléchargez remediate-windows.ps1, ouvrez PowerShell avec l’option « Exécuter en tant qu’administrateur », puis lancez powershell -ExecutionPolicy Bypass -File .\remediate-windows.ps1. Téléchargez le script uniquement depuis le site officiel de Cursor et évitez les outils de « nettoyage en un clic » de provenance inconnue. Le script supprime l’extension malveillante, les mécanismes de persistance, les processus de tunnel et la clé publique de l’attaquant. Si des éléments subsistent, il se termine avec un code de sortie non nul. Après le nettoyage, mettez l’extension à jour vers une version supérieure à 2.1.314. Au 31 octobre, vous pouvez directement installer la version 2.1.316.
⑤ Renouvelez vos identifiants. Cela concerne notamment les tokens GitHub / GitLab, les tokens CI/CD, les clés d’accès des fournisseurs cloud, les clés privées SSH, les tokens npm / PyPI, ainsi que la clé API APIYI apiyi.com configurée sur cette machine. Effectuez ces opérations depuis une machine de confiance. Si les journaux SSH montrent que le tunnel a effectivement été utilisé, Phorion recommande de reconstruire l’hôte : c’est plus sûr que de nettoyer chaque élément individuellement.
Pourquoi il faut vérifier la porte dérobée Claude Code, même si la plupart des machines n’ont pas été accessibles
Commençons par la nouvelle plutôt rassurante. Selon l’analyse de Phorion, un bug dans le code malveillant a empêché l’activation du service SSH sur la plupart des machines.
Sur macOS, le script exécute systemsetup -getremotelogin avec les droits d’un utilisateur standard. La commande renvoie un message indiquant que des droits administrateur sont nécessaires, mais son code de sortie reste 0. Le script vérifie uniquement si la sortie contient Off. Comme ce n’est pas le cas, il croit à tort que la connexion à distance est déjà activée et saute l’étape d’activation de SSH. Sur Windows, la commande PowerShell chargée d’installer OpenSSH Server est confiée à une fonction auxiliaire qui utilise /bin/sh en dur. Or, une installation Windows standard ne dispose pas de /bin/sh : cette étape échoue donc très probablement. Cursor indique aussi que l’activation du service SSH et l’établissement du tunnel échouent, sauf si Cursor a été lancé avec des droits administrateur, ce qui est rare.
Mais cela ne signifie pas que tout va bien. La clé publique, le script de persistance et la balise de reconnaissance ont bien été installés. Pour reprendre une analogie : l’outil de crochetage des attaquants était défectueux, donc beaucoup de portes ne se sont pas ouvertes. Mais la clé est déjà dans la serrure, et une nouvelle tentative a lieu toutes les 60 secondes.
| Catégorie | Indicateur (IOC, neutralisé) | Description |
|---|---|---|
| Réseau | 134[.]209[.]82[.]225:22，nom d’utilisateur tunnel |
Destination du tunnel SSH inversé |
| Réseau | 134[.]209[.]82[.]225:8099/beacon |
Balise HTTP en clair qui transmet des informations sur la machine |
| Clé publique | Commentaire svc-telemetry |
Ajoutée à authorized_keys |
| Empreinte | SHA256:0Z6R+DF64Do2nwQic8a7kkfDLNNk4IiK+2U2Rci4htk |
Empreinte de la clé publique de l’attaquant |
| Clé privée du tunnel | SHA256:KOAU57+ZG6u3MG4WwzPzPX2O5YEe9qdOC1Bl+6MVyDQ |
Écrite dans un fichier .stk_* du répertoire temporaire |
| Fichier | SHA-256 de extension.js commençant par ecb58cb2 |
Fichier principal de l’extension malveillante ; valeur complète dans l’annonce de Cursor |
Légende : capture du tableau des hachages VSIX malveillants (à ajouter lors de l’édition).
Quelques situations méritent une attention particulière :
- Remote Login était déjà activé. Si vous aviez activé la connexion à distance sur votre Mac dans « Réglages système → Général → Partage », ou si
Get-Service sshdindique que le service est en cours d’exécution sur Windows, les conditions nécessaires à l’exploitation de la porte dérobée sont réunies. - La mise hors ligne du serveur ne signifie pas que la machine est saine. Le serveur de l’attaquant est actuellement hors service, mais le script de persistance continue de tenter de s’y connecter. Tant qu’il n’est pas supprimé, la machine reste vulnérable.
- Vérifiez les journaux de connexion SSH. Sur macOS, vous pouvez exécuter
log show --predicate 'process == "sshd"' --last 7d. Sur Linux, consultez/var/log/auth.log; sur Windows, consultez le journal OpenSSH/Operational dans l’Observateur d’événements. Cherchez en priorité les authentifications réussies provenant de127.0.0.1ou::1et utilisant la clé publique svc-telemetry. Si vous en trouvez une seule, considérez que la machine a fait l’objet d’une connexion non autorisée et envisagez de la reconstruire.
Le code malveillant a également collecté le nom de la machine, le nom d’utilisateur, des informations système, le répertoire de travail, l’adresse e-mail globale Git, l’adresse IP publique et les noms de 40 variables d’environnement au maximum. La conclusion de Phorion est claire : le bug a réduit la probabilité d’une connexion non autorisée, mais il ne faut pas le considérer comme une protection.
Faut-il remplacer sa clé APIYI après la compromission de l’extension Claude Code ?
Oui. Le code malveillant collectait les noms des variables d’environnement contenant KEY, TOKEN, SECRET, PASS, AWS ou GCP. Même s’il ne lisait pas directement leurs valeurs, l’attaquant sait désormais quels identifiants sont présents sur votre machine. Dès que le tunnel est disponible, il peut lire de manière interactive les valeurs des variables d’environnement, les fichiers de configuration et l’historique du shell. Si les versions 2.1.312 ou 2.1.313 ont été installées sur cette machine pendant la période concernée, considérez donc que la clé APIYI apiyi.com configurée dessus a pu être exposée.
Précisons un point : APIYI n’a pas été piraté. Le risque est indirect : quelqu’un a pu lire la clé présente sur votre machine. Il faut donc remplacer la clé, sans pour autant paniquer. Voici comment procéder :
| Étape | Action | Vérification |
|---|---|---|
| 1 | Ouvrez la page des jetons dans la console : api.apiyi.com/token |
La liste des clés existantes s’affiche |
| 2 | Cliquez sur « Ajouter » en haut à droite, puis choisissez le groupe ClaudeCode pour la clé destinée à Claude Code |
Une nouvelle clé commençant par sk- est générée |
| 3 | Remplacez la valeur de ANTHROPIC_AUTH_TOKEN par la nouvelle clé et conservez https://api.apiyi.com pour ANTHROPIC_BASE_URL |
La section env de ~/.claude/settings.json est également mise à jour |
| 4 | Rouvrez le terminal et redémarrez Claude Code | Les conversations et les appels fonctionnent normalement |
| 5 | Retournez sur la page des jetons et désactivez ou supprimez l’ancienne clé | L’ancienne clé apparaît comme désactivée |
| 6 | Consultez les journaux d’appels | Aucune consommation ne correspond à des modèles ou à des horaires inhabituels |
Si vos scripts utilisent l’interface compatible OpenAI, pensez aussi à remplacer la clé associée à base_url="https://api.apiyi.com/v1" dans votre code. Envoyez ensuite une requête de test avec la nouvelle clé pour vérifier qu’elle fonctionne. Si l’ancienne clé est encore utilisée sur d’autres machines ou dans d’autres projets, remplacez-la partout, pas seulement sur une machine.
🎯 Bonne pratique : la page des jetons d’APIYI apiyi.com permet de définir un plafond de solde et une date d’expiration pour chaque clé. Nous vous conseillons d’utiliser une clé par machine et de séparer les clés de développement et de production. En cas d’incident similaire, vous n’aurez ainsi qu’à désactiver la clé concernée.
Enfin, rappelons que les clés APIYI ne sont pas les seules à remplacer. Les jetons GitHub / GitLab, les clés CI, les clés d’accès aux fournisseurs cloud, les clés privées SSH et les jetons npm / PyPI doivent également être renouvelés. Effectuez ces opérations depuis une machine de confiance.
FAQ sur la compromission de l’extension Claude Code
Q1 : J’utilise uniquement la marketplace officielle de VS Code. Suis-je concerné ?
Rien ne permet actuellement de l’affirmer. La seule source de distribution vérifiable est la Cursor Marketplace : la version malveillante 2.1.313 n’a été trouvée ni sur la marketplace de Microsoft ni sur Open VSX.
Q2 : J’utilise uniquement Claude Code CLI, sans extension IDE. Suis-je concerné ?
Non, pas par cet incident. Le paquet CLI sur npm n’a pas été compromis ; seule l’extension VSIX distribuée sur la marketplace de Cursor est concernée.
Q3 : J’utilise Cursor, mais je n’ai pas installé l’extension Claude Code. Suis-je concerné ?
Non. Le code malveillant ne s’exécute que lorsque cette extension est chargée. En cas de doute, recherchez `svc-telemetry` comme indiqué à l’étape ② : quelques secondes suffisent pour vérifier.
Q4 : La mise à jour vers la version 2.1.314 suffit-elle à me protéger ?
La mise à jour empêche uniquement une nouvelle compromission. Les clés publiques et scripts de persistance déjà installés, ainsi que les informations divulguées, ne disparaîtront pas pour autant. Il faut encore suivre les étapes ②③④⑤.
Q5 : Dois-je installer la version 2.1.316 ?
Vous pouvez. Au 31 octobre, la version 2.1.316 est la plus récente sur GitHub Releases, et les versions 2.1.314 et 2.1.316 sont toutes deux saines. Il n’y a pas eu de version 2.1.315 entre les deux : c’est normal.
Q6 : Faut-il réinstaller le système ?
Si seule la clé publique ou la persistance a été détectée, l’exécution du script officiel suivie d’une nouvelle vérification suffit généralement. Si les journaux SSH montrent que le tunnel a effectivement été utilisé, Phorion recommande de reconstruire l’hôte : l’échantillon ne permet pas de savoir ce que l’attaquant a fait après sa connexion.
Q7 : Les 5 000 personnes correspondent-elles à des infections confirmées ?
Non. Cursor parle de « 5 000 utilisateurs au maximum » : il s’agit d’une estimation de l’exposition liée aux téléchargements et aux mises à jour automatiques, pas d’un nombre d’infections confirmées. Cursor indique qu’il contactera directement les utilisateurs concernés.
Q8 : Mon ordinateur peut-il être contrôlé à distance ?
En raison du bug mentionné plus haut, le service SSH n’a pas été activé sur la plupart des machines macOS et Windows, et le serveur de l’attaquant est désormais hors ligne. Mais si la connexion à distance était déjà activée sur votre machine, le risque est réel. Consultez les journaux SSH pour savoir si une connexion a eu lieu.
Q9 : Ma clé APIYI peut-elle avoir été divulguée ?
La plateforme APIYI elle-même n’a pas été compromise. Le risque vient du fait que les variables d’environnement de votre machine peuvent avoir été lues. Il est donc conseillé de créer une nouvelle clé sur api.apiyi.com/token, de mettre à jour votre configuration, puis de désactiver l’ancienne clé.
Empoisonnement de l’extension Claude Code : l’essentiel
- Versions touchées : les versions 2.1.312 et 2.1.313 du catalogue Cursor. Les autres canaux officiels ne sont pas concernés.
- Exécution au chargement : pas besoin d’utiliser l’extension ; son chargement suffit à installer une porte dérobée.
- Trois traces à rechercher : une clé publique dans
authorized_keys, un script de persistance et les informations transmises par le beacon. - La plupart des utilisateurs n’ont pas subi de connexion malveillante : le code malveillant contenait un bug, mais ce n’est pas une raison pour se passer de vérifications.
- Nettoyage : exécutez le script officiel, passez à une version supérieure à 2.1.314 et, si nécessaire, reconstruisez l’hôte.
- Identifiants à renouveler : faites une rotation des identifiants Git, CI, cloud et SSH, ainsi que des clés APIYI.
Références
- Avis de sécurité de Cursor : versions touchées, IOC et script de nettoyage
- Lien :
cursor.com/blog/claude-code-extension-security-notice - Analyse technique de Phorion : analyse du code malveillant et du bug
- Lien :
phorion.io/blog/offical-claude-code-vsx-compromise - Analyse de StepSecurity : vérification du registre et des versions
- Lien :
stepsecurity.io/blog/claude-code-extension-trojanized - Versions GitHub de Claude Code : historique officiel des versions
- Lien :
github.com/anthropics/claude-code/releases
Bilan
La particularité de cet incident, c’est que la version malveillante utilisait le nom du paquet officiel. Vérifier simplement que l’éditeur est officiel ne suffit donc pas. Voici l’ordre recommandé : vérifiez d’abord la version et la provenance de l’extension, puis recherchez la clé publique et les mécanismes de persistance. Si vous trouvez des indicateurs de compromission, exécutez le script officiel. Enfin, renouvelez tous les identifiants depuis une machine de confiance. Les utilisateurs d’APIYI peuvent en profiter pour revoir les groupes, les quotas et les durées de validité de leurs clés selon le principe « une machine, une clé ». Pour la configuration, consultez la documentation de gestion des jetons d’APIYI sur apiyi.com.
Auteur : l’équipe technique d’APIYI
Échanges techniques : contactez-nous depuis la page d’accueil du site officiel d’APIYI. Pour configurer l’accès à Claude Code, consultez le centre de documentation sur docs.apiyi.com.
Cette fois, changer de version ne suffit pas : il faut aussi traiter les clés, la persistance et les identifiants.
