Une extension de développement peut sembler aussi anodine qu’un thème de couleur. Pourtant, elle s’exécute au plus près des projets, des fichiers et des accès utilisés chaque jour. Cursor a publié une alerte le 29 octobre 2026, actualisée le lendemain, concernant deux versions malveillantes portant le nom de Claude Code dans sa place de marché d’extensions VS Code. Le nom affiché ne suffisait pas à garantir leur origine.
L’urgence, pour une personne qui utilise cet environnement, consiste à identifier le paquet réellement installé. Accuser indistinctement toutes les extensions ou toutes les distributions de Claude Code brouillerait au contraire le diagnostic.
Deux numéros précis, un canal identifié
L’avis de sécurité de Cursor désigne Anthropic.claude-code 2.1.312 et 2.1.313, distribuées pour Windows et macOS dans la place de marché concernée. Cursor précise que ces versions malveillantes n’ont pas été développées par Anthropic et ne rapporte pas de preuve touchant la distribution officielle ou les autres versions.
Le paquet tentait notamment de collecter des informations sur la machine et d’installer un accès SSH persistant. Le serveur de l’attaquant identifié dans l’enquête a été mis hors service. Cette neutralisation limite ce canal connu, mais ne remplace pas l’examen d’un poste exposé. Certains mécanismes pouvaient échouer sans que l’ensemble de l’exécution soit nécessairement inoffensif.
Retrouver ce qui a vraiment été installé
La première vérification porte sur le nom complet de l’extension, sa version et son origine. Une capture de la liste installée ou un inventaire daté peut aider le support informatique à rapprocher les machines concernées de la période de distribution indiquée dans l’avis. Il est préférable de conserver ces éléments avant une réinstallation générale qui effacerait des traces utiles.
Un poste professionnel doit suivre la procédure de son organisation. Prévenir l’équipe informatique avec des faits précis lui permet d’évaluer les accès associés à la machine : dépôts, services distants, environnements de test et outils de production. Envoyer simplement « mon éditeur est peut-être piraté » laisse trop de questions ouvertes.
La réaction doit rester proportionnée au périmètre confirmé. Une personne qui n’a jamais installé ces versions via ce canal ne se trouve pas automatiquement dans la même situation qu’un développeur les ayant exécutées. À l’inverse, ne pas avoir vu de fenêtre suspecte ne démontre pas l’absence d’activité en arrière-plan.
Désinstaller n’efface pas forcément les conséquences
Supprimer une extension arrête son utilisation normale dans l’éditeur. Cela ne garantit pas la suppression d’un mécanisme de persistance créé ailleurs. C’est pourquoi un incident sur un outil de développement se traite au niveau du système et des accès, pas uniquement dans la liste des modules complémentaires.
Il vaut mieux appliquer les consignes défensives publiées par l’éditeur avec l’aide du support que lancer des scripts de nettoyage récupérés dans des commentaires. Un correctif improvisé peut détruire des preuves, modifier des permissions ou installer un second problème. Le dépannage doit garder une trace des actions entreprises et de leurs résultats.
Le même raisonnement vaut pour les comptes. Changer un mot de passe peut être nécessaire dans un plan de remédiation, mais ne couvre pas à lui seul tous les moyens d’accès. Notre article sur les accès à vérifier après le piratage d’une boîte mail explique pourquoi sessions, autorisations et mécanismes de récupération doivent être examinés ensemble.
Une extension mérite une vraie sélection
Avant d’ajouter un outil, vérifier le lien depuis le site officiel de son éditeur reste une habitude utile. Le nombre de téléchargements, un logo connu ou une description convaincante ne constituent pas une preuve suffisante. Les organisations peuvent aussi limiter les extensions autorisées et tenir un inventaire des versions utilisées.
Il n’est pas nécessaire de transformer chaque installation en audit interminable. Une liste courte d’outils approuvés et une procédure claire pour les nouveaux besoins réduisent déjà la surface d’exposition. Le contrôle devient particulièrement important lorsque l’éditeur contient des accès sensibles ou fonctionne avec des droits élevés.
Les projets doivent pouvoir repartir proprement
Un incident révèle souvent un autre point faible : personne ne sait exactement quelles dépendances et quelles extensions sont nécessaires pour travailler. Documenter un environnement minimal facilite la reconstruction d’un poste et évite de réinstaller, par habitude, tous les outils historiques.
Pour les utilisateurs concernés, le bon réflexe est donc double : suivre l’avis officiel pour traiter l’exposition connue, puis vérifier que le retour au travail s’effectue depuis un environnement maîtrisé. La disparition d’une alerte dans l’éditeur ne constitue pas, à elle seule, une confirmation que toute la machine a été assainie.
Je suis Romain, rédacteur passionné par tout ce qui touche au high-tech, à la crypto, et à l’innovation. Diplômé d’une école de marketing à Paris, je mets ma plume au service des dernières tendances et avancées technologiques.
