Extension Claude Code pour VS Code piégée : une backdoor SSH a visé 5 000 développeurs

Ce qui s'est passé le 29 octobre 2026

Le 29 octobre 2026 vers 09 h 27 UTC, une version piégée de l'extension Claude Code (un plugin d'assistance au développement) pour VS Code a été publiée sur le registre Open VSX et synchronisée automatiquement vers le Cursor Marketplace. Le package malveillant portait l'identifiant anthropic.claude-code@2.1.313 et pesait environ 3,7 Mo, soit environ 7 Ko de plus que le build légitime 2.1.312 publié deux jours plus tôt. L'extension piégée est restée disponible au téléchargement pendant environ 11 heures, jusqu'à sa suppression le 30 octobre vers 20 h 35 UTC (source : StepSecurity). Anthropic a confirmé que ses canaux de distribution officiels n'avaient pas été compromis : un acteur tiers a republié le plugin via un accès non autorisé au registre.

Jusqu'à 5 000 utilisateurs de Cursor ont pu installer cette version. Si vous êtes administrateur d'un VPS Linux ou d'un serveur dédié et que vous utilisez VS Code Remote-SSH ou Cursor pour administrer vos machines, votre poste desktop est potentiellement concerné : la backdoor s'exécute sur le poste de développement, pas sur le serveur distant, mais les clés SSH stockées dans vos répertoires locaux donnent un accès shell direct à tous vos serveurs.

Mécanisme de la backdoor

La version 2.1.313 embarquait trois composants malveillants qui s'activaient dès l'installation du plugin, sans action supplémentaire de l'utilisateur. Le code malveillant s'exécutait en Node.js pur, sans utiliser les API de VS Code, ce qui le rendait difficile à détecter par les mécanismes de sandbox habituels des plugins et extensions.

Le malware installe aussi un mécanisme de persistance adapté au système d'exploitation :

Cette persistance survit à la désinstallation du plugin : supprimer Claude Code de VS Code ou Cursor ne suffit pas à nettoyer le poste. Il faut supprimer manuellement les fichiers de persistance, la clé SSH et redémarrer les services concernés.

Le risque pour les administrateurs de serveurs

L'extension VS Code Remote-SSH est l'un des outils les plus utilisés pour administrer un serveur virtuel ou un serveur dédié depuis un poste desktop. Les administrateurs système qui gèrent des VPS Linux (Ubuntu, Debian ou autre distribution Unix), des VPS Windows ou des serveurs de virtualisation depuis VS Code ou Cursor sont les premiers concernés. Si votre poste a installé la version 2.1.313, l'attaquant disposait potentiellement de vos clés privées SSH et pouvait :

• Se connecter en shell à tous les serveurs listés dans votre fichier ~/.ssh/config (y compris les alias SSH) ou accessibles via vos clés ;
• Exécuter des commandes avec sudo sous votre nom d'utilisateur admin (souvent root sur un VPS) ;
• Déposer des scripts malveillants, des web shells PHP ou des cryptomineurs sur vos serveurs web ;
• Exfiltrer les fichiers de configuration, les bases de données et les secrets stockés sur le serveur (tokens API, credentials SMTP, mots de passe SQL).

La compromission d'un seul poste de développement desktop peut entraîner la compromission de toute votre infrastructure serveur. Que vous soyez hébergeur, administrateur de serveurs de jeu ou admin d'une plateforme web, la sécurité de la chaîne d'approvisionnement logicielle (supply chain) est un enjeu critique.

Quels services vérifier sur vos serveurs

Si votre poste desktop est compromis, partez du principe que l'attaquant a pu se connecter à chaque serveur accessible depuis vos clés SSH. Voici les services et répertoires à vérifier sur chaque serveur virtuel ou dédié concerné.

Vérifier si vous êtes concerné

Connectez-vous à votre poste de développement desktop (celui sur lequel VS Code ou Cursor est installé) et exécutez les vérifications suivantes. Les commandes ci-dessous fonctionnent sur tout système Unix (Ubuntu, Debian et autres distributions Linux) et sur macOS.

1. Vérifier la clé SSH malveillante

Cherchez la clé svc-telemetry dans votre fichier authorized_keys :

grep "svc-telemetry" ~/.ssh/authorized_keys 2>/dev/null

Si cette commande renvoie une ligne, votre poste a été compromis.

2. Vérifier les fichiers de persistance

Cherchez les fichiers déposés par le malware dans vos répertoires de configuration :

# Linux et macOS
ls -la ~/.config/.smt 2>/dev/null
ls -la ~/.config/.smtk 2>/dev/null
ls -la $TMPDIR/.stk_* 2>/dev/null

# macOS : LaunchAgent
ls ~/Library/LaunchAgents/com.apple.sysmond.plist 2>/dev/null

# Linux : crontab
crontab -l 2>/dev/null | grep -iE "smt|stk"

3. Vérifier sous Windows avec PowerShell

Sur un poste Windows, ouvrez PowerShell en tant qu'administrateur et exécutez :

# Chercher la clé malveillante
Select-String -Path "$env:USERPROFILE\.ssh\authorized_keys" -Pattern "svc-telemetry"

# Chercher la tâche planifiée SysMon
Get-ScheduledTask | Where-Object { $_.TaskName -eq "SysMon" }

# Chercher le script de démarrage
Test-Path "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd"

# Chercher les fichiers de configuration du malware
Test-Path "$env:USERPROFILE\.config\smt.cmd"
Test-Path "$env:TEMP\.stk_*"

4. Vérifier les connexions réseau vers le C2

Recherchez des connexions actives vers l'adresse IP du serveur de commande et contrôle :

# Linux
ss -tnp | grep "134.209.82.225"

# macOS
lsof -i @134.209.82.225

# Windows (PowerShell)
Get-NetTCPConnection | Where-Object { $_.RemoteAddress -eq "134.209.82.225" }

Si l'une de ces vérifications est positive, passez immédiatement aux étapes de nettoyage ci-dessous. Vérifiez ensuite chacun de vos serveurs accessibles depuis ce poste en suivant nos tutoriels sécuriser SSH sur VPS Linux et auditer l'activité d'un serveur avec auditd.

Nettoyer un poste compromis

Si les vérifications précédentes révèlent une compromission, procédez dans cet ordre.

1. Supprimer la clé SSH malveillante

Sur Linux, macOS ou dans un shell Unix :

sed -i.bak '/svc-telemetry/d' ~/.ssh/authorized_keys

Sous Windows, dans PowerShell :

$akFile = "$env:USERPROFILE\.ssh\authorized_keys"
(Get-Content $akFile) | Where-Object { $_ -notmatch "svc-telemetry" } | Set-Content $akFile

Vérifiez que la ligne a bien disparu :

grep "svc-telemetry" ~/.ssh/authorized_keys

2. Tuer le tunnel inverse et supprimer la persistance

Sur Linux et macOS :

# Tuer les processus SSH vers le C2
pkill -f "134.209.82.225"

# Supprimer les fichiers de persistance
rm -f ~/.config/.smt ~/.config/.smtk ~/.config/smt.cmd
rm -f $TMPDIR/.stk_* ~/.ssh/.stk_*

# Linux : nettoyer le cron
crontab -l 2>/dev/null | grep -vE "smt|stk" | crontab -

# macOS : supprimer le LaunchAgent
launchctl unload ~/Library/LaunchAgents/com.apple.sysmond.plist 2>/dev/null
rm -f ~/Library/LaunchAgents/com.apple.sysmond.plist

Sous Windows, dans PowerShell (en tant qu'administrateur) :

# Supprimer la tâche planifiée
Unregister-ScheduledTask -TaskName "SysMon" -Confirm:$false

# Supprimer le script de démarrage
Remove-Item "$env:APPDATA\Microsoft\Windows\Start Menu\Programs\Startup\sysmon.cmd" -Force

# Supprimer les fichiers de configuration
Remove-Item "$env:USERPROFILE\.config\smt.cmd" -Force -ErrorAction SilentlyContinue
Remove-Item "$env:TEMP\.stk_*" -Force -ErrorAction SilentlyContinue

Après la suppression, redémarrez votre poste pour vérifier que la persistance ne se réactive pas.

3. Migrer vos clés SSH

Partez du principe que vos clés SSH privées sont compromises. La migration vers de nouvelles clés est indispensable. Générez une nouvelle paire et déployez la clé publique sur chacun de vos serveurs virtuels :

ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_new -C "votre-email"

Consultez notre tutoriel configurer une clé SSH sur VPS Linux sans perdre l'accès pour la procédure complète de migration. Supprimez l'ancienne clé de tous les fichiers authorized_keys de vos VPS et serveurs dédiés.

4. Changer tous les credentials accessibles

Si le tunnel inverse a été actif, l'attaquant a pu accéder à tout ce qui était accessible depuis votre poste. Renouvelez :

• Les mots de passe des bases de données (MySQL, PostgreSQL, SQL Server, Redis) ;
• Les tokens API (GitHub, GitLab, services cloud comme AWS et GCP) ;
• Les credentials FTP et SMTP de vos serveurs web ;
• Les jetons de session et cookies admin de vos applications et CMS ;
• Les tokens CI/CD et les secrets stockés dans les variables d'environnement.

Vérifiez aussi vos sauvegardes : si un backup automatique a capturé l'état compromis d'un serveur, ne le restaurez pas en l'état.

Leçons de sécurité supply chain pour les administrateurs

Cet incident illustre un vecteur d'attaque en pleine expansion : la compromission de la chaîne d'approvisionnement logicielle. Les plugins d'éditeurs de code, les packages npm, les modules PyPI (Python) et les images Docker sont autant de points d'entrée potentiels. Voici les bonnes pratiques pour limiter le risque :

• Installer les extensions depuis les canaux officiels. Pour Claude Code, le canal officiel est le VS Code Marketplace. Les registres tiers comme Open VSX sont des miroirs sur lesquels n'importe qui peut publier un package portant le même nom.
• Vérifier l'éditeur avant installation. VS Code affiche l'éditeur vérifié (badge bleu) sur le Marketplace officiel. Un plugin sans badge ou avec un éditeur différent de celui attendu doit être traité avec méfiance.
• Épingler les versions des extensions. Désactivez les mises à jour automatiques pour les plugins critiques. Préférez une mise à jour manuelle après vérification du changelog et de l'URL de publication.
• Isoler le poste d'administration. Si possible, administrez vos serveurs depuis un poste desktop dédié qui n'installe que le strict minimum. Utilisez un agent SSH avec confirmation pour chaque connexion plutôt que des clés sans passphrase.
• Auditer régulièrement authorized_keys. Sur chaque VPS et serveur dédié, vérifiez périodiquement le contenu de ~/.ssh/authorized_keys pour chaque nom d'utilisateur. Automatisez cette vérification avec un script shell exécuté par cron ou un outil de monitoring (sécuriser un VPS Ubuntu).
• Activer les mises à jour de sécurité automatiques sur vos serveurs Linux (Ubuntu, Debian) pour que les correctifs critiques soient appliqués sans délai (automatiser les mises à jour de sécurité sur VPS Ubuntu).

Chronologie de l'incident

Le hash SHA-256 du fichier malveillant est ecb58cb29078d9646ad1dcdbe51526f2d9cfea06be5fb2ab183e8ecc3ab6bf15. Ce hash permet de vérifier si une copie locale de l'extension correspond au build compromis.

Questions fréquentes