Votre agent de codeest une supply chain.

Le vrai problème : une extension tourne avec vos droits

Une extension d'IDE n'est pas un plugin de navigateur sandboxé. C'est du code Node.js chargé dans le processus de l'éditeur, avec les permissions de l'utilisateur qui l'a installée : lecture de tous vos dépôts, accès à ~/.ssh, aux variables d'environnement, aux identifiants Git, aux sockets réseau. Sur un poste de développeur en 2026, c'est l'actif le plus précieux du SI — souvent plus que le cluster de staging.

Pendant des années, cette surface est restée théorique parce que les extensions étaient peu nombreuses et signées par leurs éditeurs. L'arrivée des agents de code a changé l'échelle : chaque développeur installe, met à jour et parfois teste plusieurs extensions par mois, souvent depuis des marketplaces tiers, avec la mise à jour automatique activée. C'est exactement le modèle de menaces qu'on a appris à traiter pour npm, sauf qu'ici le paquet tourne avec un accès complet au code source et aux secrets.

L'incident du 29 octobre n'est donc pas un accident isolé. C'est la première démonstration publique à grande échelle de ce que signifie « installer un agent » : le modèle, le prompt et la boucle d'outils ne sont que la partie visible. Le vecteur d'attaque, c'est le paquet qui les transporte.

11 heures, deux versions, 5 000 postes

La chronologie est documentée par l'avis de sécurité de Cursor et par l'analyse de Phorion, qui a détecté l'activité sur les endpoints. Entre 2h27 et 13h35 (heure du Pacifique) le 29 octobre, une version modifiée de l'extension officielle Claude Code a été publiée sur le marketplace VS Code de Cursor, pour macOS et Windows. D'après Kevin Beaumont, Cursor estime à environ 5 000 le nombre de systèmes développeurs impactés. Cursor a retiré le paquet, fermé le marketplace par précaution, fait tourner ses clés et fait mettre hors ligne le serveur de commande ; Anthropic a précisé ne pas être à l'origine de la publication.

Deux versions sont concernées : 2.1.312 puis 2.1.313. La version 2.1.314 publiée ensuite retire la charge utile du paquet — elle ne nettoie pas les machines déjà touchées. C'est le point que la plupart des résumés ont raté : la mise à jour ferme la porte, elle ne sort pas l'intrus.

Anatomie de la charge utile

Le détail technique est instructif, parce qu'il montre à quel point l'attaque est simple. Le fichier extension.js compromis commence par une IIFE ajoutée devant le bundle minifié : elle importe child_process, fs, os, path, http et crypto, puis s'exécute au moment où Node charge le fichier — avant le callback activate() de l'extension. Aucune interaction utilisateur n'est nécessaire : ouvrir l'éditeur suffit.

La séquence, ensuite, est classique :

• Reconnaissance. Collecte du hostname, de l'utilisateur, de l'OS, de l'architecture, du chemin du home, des noms de variables d'environnement, des répertoires de travail, de l'email Git configuré et de l'IP publique. L'inventaire est envoyé en HTTP POST sur /beacon, port 8099.
• Accès. Ajout d'une clé publique Ed25519 contrôlée par l'attaquant à ~/.ssh/authorized_keys, avec les permissions 0700/0600. La clé est commentée svc-telemetry — un détail qui sert à la fois de discrétion et de signature de détection.
• Tunnel. Tentative d'activation du service SSH local (systemctl sous Linux, Remote Login sous macOS, OpenSSH Server sous Windows) et ouverture d'un tunnel SSH inverse, retenté toutes les 60 secondes.
• Persistance. Sous macOS, un LaunchAgent ~/Library/LaunchAgents/com.apple.sysmond.plist qui exécute /bin/sh ~/.config/.smt ; sous Linux, une entrée cron @reboot ; sous Windows, une tâche planifiée SysMon avec un script de démarrage en repli.

Le tableau des indicateurs, utile si vous faites de la chasse :

Les deux bugs qui ont sauvé la mise (par accident)

Le point le plus intéressant de cette affaire est que l'attaque a échoué en grande partie à cause d'erreurs de développement, pas de défenses. Sous macOS, le script teste l'état de Remote Login avec systemsetup -getremotelogin sans élévation. Or la commande, lancée en utilisateur standard, affiche « You need administrator access to run this tool » et sort avec le code 0. Le test /Off/i ne matche donc jamais : la phase d'activation de SSH est sautée. Sous Windows, le chemin d'installation du service passe par un helper qui code en dur /bin/sh, ce qui ne va pas très loin sur un système sans shell POSIX.

Conséquence : sur la plupart des postes, la clé SSH et la persistance étaient bien installées, le beacon bien envoyé, mais l'accès interactif échouait faute de démon SSH actif. Cela ne rend pas l'incident bénin — la reconnaissance et la persistance ont réussi, et un accès aux identifiants restait possible dans un second temps. Cela dit quelque chose de plus utile : la différence entre un incident majeur et une catastrophe a tenu à deux lignes de code. Ne comptez pas là-dessus la prochaine fois.

Détecter et remédier sans attendre un EDR

La vérification de base tient en une commande. Sous macOS et Linux :

grep -qs svc-telemetry ~/.ssh/authorized_keys && echo "clé trouvée" || echo "non impacté"

Sous Windows, en PowerShell, cherchez dans $HOME\.ssh\authorized_keys et C:\ProgramData\ssh\administrators_authorized_keys. Complétez par la recherche des artefacts du tableau ci-dessus : ~/.config/.smt, ~/.config/smt.cmd, com.apple.sysmond.plist, tâche SysMon, cron @reboot, fichiers .stk_* dans le dossier temporaire. Un antivirus qui n'a pas encore l'échantillon en base ne vous aidera pas ; ces chemins, si.

Si un hôte est positif, l'ordre compte : isoler la machine du réseau, retirer la clé et les mécanismes de persistance, tuer les processus de tunnel, puis faire tourner depuis un autre poste tous les identifiants accessibles depuis cet hôte — tokens Git, clés cloud, sessions de navigateur, secrets en variables d'environnement. La collecte initiale ne portait que sur les noms de variables, mais rien ne garantit qu'un accès ultérieur n'aurait pas élargi la collecte. Et un rebuild reste l'option la plus sûre quand l'hôte avait accès à la production.

Checklist de production

1. Traitez le marketplace d'IDE comme un registre de paquets. Versions épinglées et inventoriées, mise à jour automatique désactivée sur les postes qui détiennent des secrets de production, miroir interne pour les extensions autorisées.
2. Ajoutez svc-telemetry et les chemins d'artefacts à votre supervision. Une alerte sur toute modification de authorized_keys hors processus d'onboarding coûte moins cher qu'un EDR et couvre aussi les cas bénins.
3. Séparez les postes. Un laptop qui a les clés cloud de production ne devrait pas être celui sur lequel on teste trois extensions d'agent par semaine.
4. Répétez la rotation. Un incident de ce type n'est propre que si vous savez quels identifiants étaient accessibles. Inventaire des secrets par poste, sinon la remédiation est une conjecture.
5. Ne confondez pas mise à jour et nettoyage. 2.1.314 retire la charge utile du paquet ; elle ne supprime ni la clé, ni le LaunchAgent, ni la tâche planifiée déjà posés.

Besoin de concevoir des workflows IA fiables, d'auditer l'architecture d'un LLM ou de former votre équipe ? Découvrez comment nous travaillons chez Kaleido-Lab.