Extension Cursor compromise : Anthropic face au risque SSH

Le 29 octobre 2026, une version compromise de l’extension Claude Code d’Anthropic a été distribuée sur le marketplace d’extensions de Cursor. Pendant environ onze heures, les versions 2.1.312 et 2.1.313 ont pu installer un backdoor, un mécanisme d’accès clandestin persistant, sur des ordinateurs Windows et macOS. Cursor estime que jusqu’à 5 000 utilisateurs ont pu être exposés.

L’incident ne met pas seulement en cause une extension dédiée au développement assisté par IA. Il révèle un problème plus large : lorsqu’un éditeur, un marketplace et un outil de programmation se trouvent imbriqués dans la même chaîne, une compromission intermédiaire peut transformer une mise à jour apparemment légitime en vecteur d’intrusion. Le code malveillant collectait des informations sur la machine, ajoutait une clé SSH contrôlée par l’attaquant et tentait d’établir un tunnel distant.

L’affaire fournit surtout un cas concret pour évaluer les responsabilités respectives d’Anthropic et de Cursor, les limites de la confiance accordée aux extensions officielles et les mesures que les équipes de développement doivent appliquer après une installation à risque.

Une extension officielle d’Anthropic distribuée par le mauvais canal

Le point de départ de l’incident est une extension identifiée comme anthropic.claude-code, conçue pour intégrer Claude Code dans un environnement compatible avec Visual Studio Code. Cursor a indiqué que les versions 2.1.312 et 2.1.313 proposées dans son marketplace étaient malveillantes et concernaient Windows et macOS.

L’extension compromise conservait l’apparence et une partie du fonctionnement du composant légitime. Cette proximité est déterminante : un développeur pouvait l’installer comme une mise à jour habituelle, sans télécharger un exécutable présenté comme suspect ni modifier volontairement les paramètres de sécurité de son poste.

Les analyses publiées après l’incident décrivent un chargeur malveillant ajouté au code de l’extension. Selon Panorays, ce chargeur comptait 66 lignes et précédait le code fonctionnel légitime. L’extension pouvait donc continuer à fournir les fonctions attendues tout en exécutant des actions en arrière-plan.

Le risque provenait ainsi moins d’un comportement visible que de la confiance accordée à trois éléments : le nom d’Anthropic, l’identifiant officiel de l’extension et le marketplace intégré à Cursor.

À retenir : une extension portant l’identifiant officiel d’un éditeur ne suffit pas à garantir l’intégrité du paquet réellement distribué.

Jusqu’à 5 000 utilisateurs exposés pendant environ onze heures

Cursor a estimé que l’exposition maximale pouvait atteindre 5 000 utilisateurs. La fenêtre concernée s’étendait approximativement de 2 h 27 à 13 h 35, heure du Pacifique, le 29 octobre 2026, soit environ onze heures.

Sophos situe la période de distribution entre 9 h 27 et 20 h 35 UTC. Les deux indications correspondent à la même séquence temporelle, exprimée dans des fuseaux différents.

Le chiffre de 5 000 désigne des utilisateurs potentiellement exposés, et non un nombre établi de machines effectivement prises en main. L’extension tentait d’exécuter plusieurs actions nécessitant parfois des privilèges ou des conditions réseau particulières. Le risque reste néanmoins significatif : un poste de développeur contient souvent des clés d’accès, des dépôts privés, des jetons d’API et des identifiants utilisables contre des environnements de production.

La portée est aussi amplifiée par le profil des utilisateurs de Cursor. Un environnement de développement peut se trouver au centre de plusieurs chaînes d’accès : dépôts Git, registres de paquets, plateformes cloud, systèmes de déploiement continu et services d’IA. Une compromission locale ne s’arrête donc pas nécessairement à l’ordinateur sur lequel l’extension a été installée.

Un backdoor SSH conçu pour survivre à la désinstallation

Le code malveillant tentait d’ajouter une clé publique SSH contrôlée par l’attaquant au fichier authorized_keys de l’utilisateur. Ce fichier contient les clés autorisées à ouvrir une session SSH sur une machine. Une clé ajoutée à cet emplacement peut permettre une reconnexion ultérieure, indépendamment du fonctionnement normal de l’extension.

Les analyses mentionnent une clé associée au libellé svc-telemetry. L’extension essayait également d’activer le service SSH local et d’établir un reverse SSH tunnel, c’est-à-dire une connexion sortante depuis la machine compromise vers un serveur contrôlé à distance. Cette technique peut permettre à un attaquant de contourner certaines restrictions qui bloquent les connexions entrantes.

Le serveur distant identifié dans les analyses utilisait l’adresse IP 134.209.82.225. Les commandes observées tentaient notamment d’ouvrir un tunnel vers ce serveur sur le port SSH 22. L’objectif était de maintenir un canal d’accès depuis la machine infectée vers l’infrastructure de l’attaquant.

L’extension mettait aussi en place des mécanismes de persistance. Selon les analyses publiées, ces mécanismes pouvaient s’appuyer sur les tâches planifiées de Windows, cron sur macOS ou Linux, ainsi que sur un LaunchAgent pour macOS. Le retrait de l’extension ne suffisait donc pas nécessairement à supprimer tous les composants installés.

Les informations recherchées par le code malveillant

Le code collectait des données de reconnaissance sur l’environnement local, notamment :

• le nom de la machine ;
• le nom de l’utilisateur ;
• le système d’exploitation et son architecture ;
• le chemin du répertoire personnel ;
• les noms des variables d’environnement ;
• les répertoires de travail ;
• l’adresse e-mail configurée dans Git ;
• l’adresse IP publique.

Panorays indique que le code pouvait transmettre les noms d’un maximum de 40 variables d’environnement. Même lorsque les valeurs ne sont pas directement exfiltrées, leurs noms peuvent révéler la présence de clés cloud, de jetons de services ou d’outils internes.

L’extension envoyait ces informations vers le serveur distant au moyen d’une requête HTTP vers le port 8099. Pour une équipe de sécurité, ces données constituent une première cartographie de la machine et de son contexte de développement.

Cursor a retiré l’extension et interrompu son marketplace

Cursor a déclaré avoir bloqué le serveur distant, retiré l’extension compromise et publié des indicateurs de compromission. L’entreprise a également temporairement mis son marketplace hors ligne afin de retirer le paquet et de reconstruire le service.

La réponse opérationnelle comprenait plusieurs volets :

• suppression des versions compromises ;
• interruption de l’infrastructure distante associée à l’attaque ;
• publication d’indicateurs techniques ;
• reconstruction du marketplace ;
• vérification des autres extensions distribuées par le service.

Les informations publiées indiquent que Cursor n’a pas identifié d’autre extension compromise dans le cadre de cet incident. L’entreprise a toutefois recommandé aux utilisateurs ayant installé les versions concernées de vérifier leur système, de supprimer les accès non autorisés et d’envisager la rotation des identifiants potentiellement accessibles depuis la machine.

La coupure du marketplace limite la diffusion du paquet, mais elle ne remplace pas une réponse sur les postes déjà exposés. Une extension malveillante peut modifier le système avant son retrait, ce qui impose une investigation locale et non une simple désinstallation.

Le rôle d’Anthropic dans la chaîne de confiance

Les analyses publiées soulignent que les versions malveillantes n’ont pas été développées par Anthropic, même si elles utilisaient l’identité de son extension Claude Code. Anthropic a ensuite rendu disponible la version propre 2.1.314 sur Open VSX et sur le marketplace de Microsoft pour Visual Studio Code.

Cette distinction est essentielle pour comprendre la chaîne de responsabilité. Anthropic contrôle le logiciel qu’il publie, tandis que Cursor contrôle le canal par lequel une copie a été distribuée à ses utilisateurs. Pour l’utilisateur final, ces niveaux sont difficiles à distinguer : le nom affiché reste celui d’Anthropic, alors que le paquet installé peut avoir été altéré dans le circuit de distribution.

L’incident ne permet pas, à lui seul, d’attribuer une intention ou une défaillance précise à chaque acteur au-delà des faits rendus publics. Il montre en revanche que la signature de marque et l’identité d’un éditeur ne remplacent pas les contrôles d’intégrité du marketplace.

Pourquoi les assistants de programmation augmentent le risque

Les assistants de programmation disposent d’un accès privilégié à l’environnement de travail. Pour être utiles, ils doivent souvent lire le code du projet, exécuter des commandes, accéder au système de fichiers et interagir avec Git ou des outils de construction.

Une extension de développement ne se comporte donc pas comme un simple module d’interface. Elle peut se trouver dans une position capable d’observer les chemins de travail, les réglages du poste, les processus et les informations nécessaires au déploiement.

Cette concentration de privilèges explique pourquoi une compromission d’extension peut être plus dangereuse qu’une attaque limitée à une application isolée. Le poste du développeur donne fréquemment accès à :

• des dépôts privés et des clés Git ;
• des jetons d’API pour des services d’IA ;
• des identifiants de registres de paquets ;
• des configurations Kubernetes ou cloud ;
• des secrets injectés par les outils de développement ;
• des environnements de test et de production.

La présence d’un assistant d’IA ne crée pas nécessairement ces privilèges, mais elle ajoute une couche logicielle active dans l’éditeur. Si cette couche est remplacée par un paquet hostile, la confiance accordée à l’outil peut accélérer l’exécution du code malveillant.

Le cas Cursor rappelle aussi qu’un outil destiné à accélérer le développement devient une cible attractive précisément parce qu’il se trouve au cœur du travail quotidien. Sa valeur pour les développeurs est également sa valeur potentielle pour un attaquant.

La chaîne d’approvisionnement logicielle reste le point faible

Une chaîne d’approvisionnement logicielle désigne l’ensemble des composants, éditeurs, dépôts, systèmes de compilation et canaux de distribution qui interviennent avant l’installation d’un logiciel. La compromission de Cursor illustre une attaque située entre la production du code par Anthropic et son installation par l’utilisateur.

Le paquet pouvait être reconnu comme officiel par son identifiant tout en contenant du code ajouté. Cette situation met en évidence plusieurs contrôles nécessaires : signature des artefacts, vérification reproductible des versions, séparation des droits d’administration et surveillance des changements inattendus.

Un marketplace constitue lui-même une infrastructure critique. Il doit protéger les comptes de publication, contrôler les mises à jour, conserver des journaux d’audit et détecter les écarts entre le paquet soumis et le paquet distribué. La disponibilité du service est secondaire si l’intégrité des extensions n’est pas garantie.

La question dépasse Cursor. Les environnements compatibles avec Visual Studio Code reposent sur des extensions provenant d’éditeurs multiples. Plus le nombre de composants augmente, plus l’organisation doit distinguer l’extension autorisée, la version approuvée et le paquet effectivement installé.

Les contrôles prioritaires pour les éditeurs et marketplaces

• Signer les extensions et vérifier la signature avant distribution.
• Conserver une traçabilité complète entre le code source, la compilation et le paquet publié.
• Protéger les comptes d’éditeurs par une authentification forte et des droits minimaux.
• Détecter les modifications introduites après la validation de l’éditeur.
• Isoler les services de marketplace des systèmes capables de modifier les artefacts publiés.
• Publier rapidement les indicateurs de compromission et les versions corrigées.
• Prévoir un mécanisme de révocation qui signale les installations déjà effectuées.

Ces mesures ne garantissent pas l’absence d’incident, mais elles réduisent la durée de distribution et facilitent l’identification des machines concernées.

Ce que les équipes doivent vérifier après l’installation

Les organisations qui ont installé les versions 2.1.312 ou 2.1.313 doivent traiter le poste comme potentiellement compromis jusqu’à la fin de l’analyse. La désinstallation de l’extension ne suffit pas, car les mécanismes SSH et de persistance peuvent rester présents.

Les vérifications prioritaires portent sur les éléments directement décrits dans les indicateurs publiés :

• présence d’une clé inconnue dans ~/.ssh/authorized_keys ;
• apparition d’une clé associée à svc-telemetry ;
• connexions ou processus liés à 134.209.82.225 ;
• tunnels SSH sortants inhabituels ;
• tâches planifiées ou entrées cron récemment créées ;
• LaunchAgent inconnus sur macOS ;
• activation inattendue du service SSH ;
• changements récents dans les variables d’environnement et les fichiers de configuration.

Les commandes de diagnostic doivent être adaptées au système, aux droits de l’utilisateur et aux procédures internes. Une organisation ne doit pas supprimer précipitamment des fichiers susceptibles de servir à l’analyse forensique.

La rotation des secrets accessibles depuis le poste est également nécessaire. Elle doit couvrir les clés SSH, les jetons Git, les identifiants cloud, les clés d’API et les secrets de registres de paquets. La priorité dépend de la criticité des services et de la durée pendant laquelle le poste est resté connecté.

Pour les environnements professionnels, le traitement doit inclure les journaux des fournisseurs cloud, des dépôts de code et des systèmes d’identité. Les traces d’authentification peuvent confirmer si un secret a été utilisé après l’installation de l’extension.

À retenir : l’action correcte n’est pas seulement de supprimer l’extension, mais de rechercher la persistance, révoquer les secrets accessibles et examiner les connexions sortantes.

Notre avis : Cursor doit transformer l’incident en contrôle permanent

L’incident montre que le principal risque ne vient pas uniquement d’un code malveillant dans une extension. Il vient de l’écart entre l’identité affichée et l’artefact réellement distribué. Pour un outil de développement, cet écart est suffisamment grave pour justifier une vérification cryptographique systématique et visible par l’utilisateur.

Cursor a retiré l’extension, bloqué le serveur distant, interrompu temporairement son marketplace et publié des indicateurs de compromission. Ces mesures répondent à l’urgence. La prochaine étape doit être plus structurelle : rendre vérifiable la provenance de chaque extension, signaler les versions révoquées et fournir aux équipes un inventaire fiable des installations concernées.

Anthropic doit également continuer à distinguer clairement ses canaux de distribution et ses versions authentiques. La disponibilité de la version 2.1.314 sur Open VSX et le marketplace Microsoft fournit un point de retour vers une version propre, mais la confiance dépendra de la capacité des utilisateurs à vérifier que cette version est bien celle installée.

Dans les six prochains mois, les assistants de programmation seront jugés sur un critère plus exigeant que leur productivité : leur capacité à fonctionner dans une chaîne logicielle contrôlable, auditable et réversible. Les équipes qui accordent des accès larges à leurs extensions sans inventaire ni rotation des secrets prennent un risque disproportionné.

La question qui reste ouverte est celle-ci : les marketplaces d’outils d’IA vont-ils traiter les extensions comme de simples modules, ou comme des composants de sécurité à part entière ?