5 000 développeurs ont-ils vraiment été piratés ? Quel est l’impact réel de l’attaque par empoisonnement d’une extension Cursor à ce jour ?

Note de l’auteur : cet article explique ce que signifie réellement « jusqu’à 5 000 personnes potentiellement touchées » dans l’affaire de l’extension Cursor compromise. Il revient sur la chaîne d’attaque, les cas confirmés, les risques pour les clés API et les vérifications à effectuer, pour distinguer les faits établis des exagérations.

Le 29 octobre 2026, une version compromise de l’extension Claude Code est apparue sur la marketplace de Cursor. Dans les jours qui ont suivi, des titres comme « 5 000 développeurs piratés » ou « fuite massive de clés API Claude » ont commencé à circuler. En réalité, 5 000 est le nombre maximal d’utilisateurs potentiellement touchés indiqué par Cursor, et non le nombre d’intrusions réussies et confirmées.

Il ne s’agit pas de minimiser le risque. Cursor, l’équipe de recherche en sécurité de Microsoft, Phorion, Expel et plusieurs autres organisations ont confirmé que l’incident avait bien eu lieu. Des activités malveillantes ont aussi été observées sur des appareils de clients. Cet article examine six étapes — « distribution, exécution, écriture, possibilité d’exploitation, intrusion effective et perte de données » — pour expliquer les faits vérifiés et les chiffres qui n’ont pas été rendus publics à ce jour.

Ce que vous allez y gagner : à la fin de l’article, vous pourrez évaluer l’impact réel de cette extension Cursor compromise sur vous et votre équipe, puis suivre les recommandations officielles pour effectuer vos vérifications et renouveler vos identifiants.

L’essentiel sur le plug-in Cursor compromis

Commençons par les faits vérifiés. La distinction est importante : il s’agit d’une attaque de la chaîne d’approvisionnement logicielle d’un outil de développement, et non d’une compromission du modèle Claude ou des systèmes internes d’Anthropic.

Anthropic indique ne pas avoir développé ni publié ces versions malveillantes. L’incident ne concerne pas non plus ses systèmes internes ou les ordinateurs de ses employés. Au 2 novembre, aucune conclusion d’enquête publique n’expliquait comment les attaquants avaient obtenu les droits nécessaires pour publier des versions sur la marketplace Cursor.

Chronologie de la compromission du plug-in Cursor

Deux périodes sont faciles à confondre dans cette affaire : la période pendant laquelle les paquets malveillants étaient téléchargeables sur la marketplace et le moment où le code malveillant s’est réellement exécuté sur les appareils concernés. Le second peut intervenir bien après la première : le retrait du plug-in ne signifie pas que les appareils sur lesquels il est installé sont à nouveau sûrs.

Les premières informations indiquaient aussi qu’Open VSX avait été attaqué. OpenSourceMalware a ensuite corrigé cette affirmation, et Socket n’a trouvé aucune trace des versions malveillantes dans le registre Open VSX. À ce jour, Cursor Marketplace est le seul canal dont la compromission est confirmée.

Comment fonctionne l’empoisonnement de l’extension Cursor : d’un chargeur de 66 lignes à un tunnel SSH inversé

Selon les analyses de Phorion et d’OpenSourceMalware, les attaquants ont inséré un chargeur JavaScript malveillant d’environ 66 lignes au début du fichier extension.js d’une extension légitime, avant le code normal. Il se déclenche dès que le module de l’extension est chargé : l’utilisateur n’a pas besoin d’envoyer un message à Claude ni d’autoriser une tâche de programmation. L’interface et les fonctionnalités de Claude Code restent utilisables normalement, et certaines erreurs sont traitées silencieusement, ce qui rend l’attaque difficile à détecter.

La chaîne d’attaque se résume en six étapes :

1. Collecter les informations sur l’hôte : nom de la machine, nom d’utilisateur, système d’exploitation et architecture du processeur, répertoire personnel, répertoire de travail, adresse e-mail Git globale, IP publique, etc.
2. Implanter une clé SSH autorisée : écrire une clé publique contrôlée par les attaquants dans le fichier authorized_keys de l’utilisateur, avec le marqueur svc-telemetry.
3. Tenter d’activer le service SSH : si l’appareil accepte les connexions SSH, les attaquants peuvent potentiellement se connecter à l’aide de la clé implantée.
4. Établir un tunnel SSH inversé : l’appareil victime se connecte à un serveur contrôlé par les attaquants (TCP 22), qui redirige ensuite les connexions vers le service SSH local. Cela permet de contourner certaines restrictions sur les connexions entrantes.
5. Mettre en place la persistance : sur macOS et Windows, une reconnexion automatique est configurée après l’ouverture de session ; sur Linux, elle passe par crontab @reboot. La porte dérobée peut ainsi fonctionner indépendamment de l’extension. En cas d’échec, une nouvelle tentative a lieu environ toutes les 60 secondes.
6. Signaler l’état d’exécution : une balise HTTP transmet au serveur les informations sur l’hôte et le résultat de chaque étape via le port TCP 8099.

Pourquoi l’empoisonnement du plugin Cursor n’est pas une injection d’invite

En voyant que « Claude Code a été compromis », beaucoup pensent d’abord qu’une invite malveillante a manipulé le modèle. Ce n’est pas le cas ici. Il s’agit d’une attaque par exécution de code via une extension : la logique malveillante n’a aucun lien avec les réponses du modèle. Le principe serait le même avec n’importe quel plugin d’IDE altéré. Il est donc inutile de remettre en question la sécurité du modèle Claude lui-même dans cette affaire. Le vrai problème est le suivant : dès qu’un canal de distribution de plugins pour développeurs est usurpé, la chaîne de confiance se brise.

Deux défauts dans le code malveillant

Des erreurs dans le code ont limité la portée de l’attaque. Sur macOS, le code malveillant vérifiait l’état de Remote Login sans privilèges administrateur. Le système renvoyait donc une erreur d’autorisation, et non un état « désactivé ». Or, le programme ne tentait d’activer SSH que s’il détectait clairement cet état. Cette étape échouait donc sur de nombreux Mac où SSH n’était pas déjà activé. Sur Windows, le code appelait à tort /bin/sh, un chemin de type Unix absent des environnements Windows standards, lors de l’installation d’OpenSSH Server.

Ces défauts ne rendent toutefois pas l’attaque inoffensive. Le code malveillant peut toujours enregistrer une clé publique, générer un script de persistance, établir des connexions réseau et transmettre des informations sur la machine. Le risque est nettement plus élevé pour les appareils sur lesquels SSH est déjà activé. Dans un entretien avec WIRED, Calum Hall, cofondateur de Phorion, a également indiqué que, correctement mise en œuvre, cette attaque aurait pu constituer un point d’entrée très dangereux.

5000 développeurs piratés ? Les 6 niveaux d’impact de l’extension Cursor compromise

Le chiffre de « 5000 » vient du communiqué initial de Cursor, publié le 29 octobre : « At most 5,000 users were affected », soit au maximum 5000 utilisateurs touchés. Il s’agit d’une limite supérieure annoncée par Cursor, et non d’un nombre d’intrusions confirmé par un organisme de sécurité indépendant. Le communiqué initial ne mentionnait que la version 2.1.313 ; la version 2.1.312 a été ajoutée lors d’une mise à jour. Cursor n’a toutefois pas indiqué combien d’utilisateurs étaient concernés par chaque version, ni publié de répartition complète après cette révision.

En décomposant l’impact en six niveaux, on distingue mieux ce qui est confirmé de ce qui reste hypothétique :

L’écart entre les deux côtés du graphique reflète celui qui existe entre les titres et les preuves. Plus on descend dans l’entonnoir, moins les preuves publiques sont nombreuses. À ce jour, rien ne permet d’affirmer que « 5000 ordinateurs ont été entièrement contrôlés » ou que « les clés API de 5000 personnes ont été volées ».

Que révèlent les 4 incidents traités par Expel ?

Les 29 et 30 octobre, Expel a traité 4 incidents liés, touchant 4 clients et un Mac par client. Trois de ces Mac utilisaient CrowdStrike Falcon, et le quatrième Microsoft Defender for Endpoint. Dans les 4 incidents, des connexions réseau vers l’adresse IP du serveur des attaquants ont été observées. L’affaire ne se limite donc plus à l’analyse de code en laboratoire.

Le cas le plus marquant est celui d’une exécution différée. Le 30 octobre à 12 h 44, heure de Pékin, un utilisateur s’est connecté à son Mac et a lancé Cursor. Une activité malveillante est apparue une minute plus tard et, à 22 h 29, des connexions vers l’adresse IP des attaquants étaient toujours observées, soit près de 10 heures après. À ce moment-là, le paquet malveillant avait depuis longtemps été retiré de la place de marché. L’explication la plus plausible est que le paquet avait déjà été téléchargé pendant la période d’exposition, puis activé lorsque l’utilisateur a rouvert Cursor.

Ces données ont toutefois des limites claires : 4 incidents ne signifient pas que seuls 4 appareils ont été compromis dans le monde, et il serait incorrect de diviser 4 par 5 000 pour calculer un taux d’infection. De même, la détection d’un tunnel SSH ne prouve pas que les attaquants ont réussi à se connecter. Phorion a également découvert des échantillons sur des Mac de clients, mais on ignore si ses cas recoupent ceux d’Expel : on ne peut donc pas simplement les additionner. Expel a aussi repéré un processus de tunnel malveillant sur une machine qui ne portait pas le marqueur de clé publique svc-telemetry. Se limiter à la recherche d’un seul marqueur risque donc de laisser passer des cas.

Limites du risque pour les clés API dans l’empoisonnement de l’extension Cursor

Le code malveillant sélectionnait jusqu’à 40 variables d’environnement dont le nom contenait KEY, TOKEN, SECRET, PASS, AWS ou GCP. Par exemple, si la variable OPENAI_API_KEY était définie sur la machine, l’attaquant pouvait savoir que le service correspondant était utilisé. Mais les chercheurs ont confirmé que le rapport initial ne transmettait que les noms des variables, et non leurs valeurs.

La formulation correcte est donc la suivante : le code d’attaque pouvait identifier les catégories de configurations sensibles. Si la porte dérobée était effectivement exploitée, l’attaquant pouvait ensuite accéder aux identifiants locaux et au code source. Quant au nombre de clés API réellement volées, aucune donnée publique n’est disponible à ce jour. Affirmer que « toutes les clés API des utilisateurs ont été volées » revient à confondre une possibilité avec un fait avéré. Mais c’est justement parce que l’étendue du risque reste incertaine qu’il faut renouveler les identifiants par précaution.

Analyse des conséquences de l’empoisonnement de l’extension Cursor

Conséquences pour les développeurs

• Désinstaller l’extension ne suffit pas : les responsables du projet avertissent que la désinstallation ou la mise à jour vers 2.1.314 ne supprime pas nécessairement les clés publiques SSH, les éléments de démarrage et les scripts en arrière-plan déjà installés.
• Le code peut encore se déclencher après le retrait : le cas d’activation différée rapporté par Expel montre que les utilisateurs qui n’ont ouvert Cursor qu’après le retrait de l’extension doivent eux aussi vérifier leur machine.
• Les machines dont SSH est toujours actif sont plus exposées : les développeurs laissent souvent Remote Login activé pour le débogage à distance, ce qui contourne justement le défaut d’implémentation du code malveillant.
• Les identifiants exposés ont pu être repérés : même si la porte dérobée n’a pas été exploitée avec succès, l’attaquant peut déjà savoir quels services cloud et API vous utilisez.

Conséquences pour les équipes et le secteur

• La distribution des extensions devient une nouvelle surface d’attaque : les versions d’une même extension peuvent provenir de sources différentes selon la plateforme. Il faut donc tenir compte de la source d’installation et du hash du fichier, sans se limiter au numéro de version.
• Les permissions accordées aux outils de programmation IA sur les postes doivent être réévaluées : les extensions d’IDE s’exécutent généralement avec les droits de l’utilisateur. Elles peuvent lire et modifier le répertoire personnel et établir des connexions réseau. Les entreprises devraient les inclure dans la gestion de leurs postes.
• La réponse à l’incident doit couvrir le cycle de vie des identifiants : il faut évaluer les dépôts, clés API, identifiants cloud et jetons de session accessibles depuis les appareils touchés. Plus les clés utilisées par un projet sont dispersées, plus leur renouvellement coûte cher.

Vérifier une éventuelle compromission d’une extension Cursor et renouveler ses identifiants

Commencez par utiliser les scripts de vérification et de remédiation pour macOS et Windows fournis dans l’annonce officielle de Cursor. Les indicateurs et commandes ci-dessous aident à comprendre et à mener les vérifications, mais ne remplacent pas les scripts officiels ni l’analyse des journaux.

Première étape : vérification rapide de la machine locale (exemple sous macOS)

# 1. 检查授权公钥中是否有攻击者标记（注意：没找到不代表安全，可能漏报）
grep -n "svc-telemetry" ~/.ssh/authorized_keys

# 2. 检查持久化文件与启动项
ls -la ~/.config/.smt ~/.config/.smtk ~/Library/LaunchAgents/com.apple.sysmond.plist 2>/dev/null

# 3. 检查是否存在与恶意服务器的连接
lsof -nP -i | grep "134.209.82.225"

# 4. 确认 Remote Login 状态（需要管理员权限）
sudo systemsetup -getremotelogin

Sous Windows, utilisez schtasks /query /tn SysMon pour vérifier la tâche planifiée, puis cherchez sysmon.cmd dans le dossier de démarrage. Si vous trouvez l’un de ces indicateurs, conservez les preuves, isolez l’appareil, puis nettoyez-le à l’aide des scripts officiels. Si vous ne pouvez pas rétablir un état de confiance sur l’appareil, envisagez de réinstaller le système et de renouveler les identifiants depuis un autre appareil de confiance.

Deuxième étape : recenser les noms des variables d’identifiants exposés

Le script ci-dessous filtre les variables d’environnement à l’aide des mêmes mots-clés que le code malveillant. Il affiche uniquement les noms, pas les valeurs, pour vous aider à dresser la liste des identifiants à renouveler. Une fois le renouvellement terminé, effectuez un appel API simple pour vérifier que la nouvelle clé fonctionne :

import os, re, openai

# 与恶意代码相同的关键词，列出可能被“摸底”的变量名
pattern = re.compile(r"KEY|TOKEN|SECRET|PASS|AWS|GCP")
print([k for k in os.environ if pattern.search(k.upper())])

# 在可信设备上轮换后，用新 Key 验证调用
client = openai.OpenAI(
    api_key=os.environ["NEW_API_KEY"],
    base_url="https://api.apiyi.com/v1"  # APIYI OpenAI 兼容接口
)
r = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "ping"}]
)
print(r.choices[0].message.content)

import os
import re
import openai
from typing import List

KEYWORDS = re.compile(r"KEY|TOKEN|SECRET|PASS|AWS|GCP")

def list_sensitive_env_names(limit: int = 40) -> List[str]:
    """只返回疑似凭证的环境变量名称，绝不输出值。
    limit 与恶意代码的筛选上限保持一致，用于还原攻击者可能看到的视图。"""
    names = [k for k in os.environ if KEYWORDS.search(k.upper())]
    return sorted(names)[:limit]

def verify_new_key(model: str = "gpt-4o-mini") -> bool:
    """轮换后验证新 Key 是否可正常调用"""
    client = openai.OpenAI(
        api_key=os.environ.get("NEW_API_KEY", ""),
        base_url="https://api.apiyi.com/v1"
    )
    try:
        resp = client.chat.completions.create(
            model=model,
            messages=[{"role": "user", "content": "ping"}],
            max_tokens=10
        )
        return bool(resp.choices[0].message.content)
    except Exception as e:
        print(f"验证失败: {e}")
        return False

if __name__ == "__main__":
    print("可能暴露给攻击者的变量名：")
    for name in list_sensitive_env_names():
        print("  -", name)
    print("新 Key 验证结果：", verify_new_key())

Troisième étape : renouveler les identifiants par ordre de priorité

🎯 Conseil technique : si votre projet se connecte directement à plusieurs plateformes comme OpenAI, Claude et Gemini, vous devrez, après un incident, vous connecter à chaque console pour révoquer et recréer les clés. La recommandation officielle consiste à centraliser l’invocation des modèles via APIYI apiyi.com : une seule clé donne accès aux principaux modèles et l’interface est compatible avec OpenAI. Lors d’un renouvellement, il suffit alors de modifier la configuration à un seul endroit. Cela facilite aussi le suivi centralisé de l’utilisation et la détection des dépenses anormales.

Questions fréquentes (FAQ)

Empoisonnement d’une extension Cursor : points clés

• Nature de l’incident : le marketplace de Cursor a distribué une extension altérée. Il s’agit d’une attaque de la chaîne d’approvisionnement, pas d’une faille du modèle Claude.
• Ce que signifie 5 000 : c’est la limite haute du nombre de personnes potentiellement touchées, communiquée officiellement, et non le nombre d’intrusions confirmées.
• Ce qui est confirmé : un organisme indépendant a observé une activité malveillante et des connexions sortantes sur un Mac réel.
• Ce qui n’a pas été communiqué : le nombre de connexions à distance réussies, le nombre de clés volées et les pertes financières.
• Risque principal : le code malveillant peut encore se déclencher après le retrait de l’extension. La désinstaller ne garantit pas la suppression de la porte dérobée.
• Mesures à prendre : exécuter le script officiel, renouveler les identifiants depuis un appareil de confiance et utiliser APIYI apiyi.com pour réduire le nombre de clés à gérer.

En résumé

Les points essentiels de l’incident :

1. Distinguer les titres des preuves : il y a plusieurs niveaux entre « jusqu’à 5 000 personnes potentiellement touchées » et « 5 000 personnes piratées ». Les preuves publiques actuelles confirment des cas réels d’exécution du code malveillant.
2. L’attaque est réelle, mais son efficacité était limitée : le code malveillant pouvait installer une porte dérobée et assurer sa persistance, mais des défauts d’implémentation sur macOS et Windows ont réduit les chances de réussite des connexions à distance.
3. Une seule vérification ne suffit pas : il faut croiser la source d’installation, les empreintes des fichiers, les processus, les connexions réseau et les éléments lancés au démarrage. Une recherche limitée à svc-telemetry risque de passer à côté de certains cas.

Si vous avez utilisé l’extension Claude Code via le marketplace de Cursor entre le 29 et le 30 octobre, commencez par suivre les consignes officielles de vérification, puis renouvelez vos identifiants par ordre de priorité. Pour les API des modèles, vous pouvez en profiter pour regrouper vos clés dispersées sur APIYI apiyi.com : leur renouvellement en urgence sera plus simple la prochaine fois.

📚 Références

1. Avis de sécurité officiel de Cursor : chronologie de l’incident, versions, empreintes des fichiers malveillants et scripts de nettoyage
2. Lien : cursor.com/blog/claude-code-extension-security-notice

3. À savoir : consultez d’abord cet avis pour vérifier votre installation. Il contient des scripts de correction pour macOS et Windows.

4. Microsoft Security Research : analyse de la chaîne d’attaque de l’extension malveillante Claude Code

5. Lien : microsoft.com/en-us/security/blog/2026/10/30/inside-malicious-claude-code-branded-cursor-extension-persistent-ssh-backdoor/

6. À savoir : permet de vérifier les limites de la chaîne d’approvisionnement, le mécanisme SSH et les détails de la persistance.

7. Phorion : Official Claude Code Extension Compromise

8. Lien : phorion.io/blog/offical-claude-code-vsx-compromise/

9. À savoir : détails techniques sur le chargeur de 66 lignes, les différences entre plateformes et les défauts du code.

10. Expel : Fake Claude Code extensions in Cursor

11. Lien : expel.com/blog/blog-fake-claude-code-extension-cursor-ssh-backdoor/

12. À savoir : quatre incidents réels chez des clients et des cas d’exécution différée.

13. Socket : Cursor Removes Malicious Claude Code Extension

14. Lien : socket.dev/blog/claude-code-extension-compromise
15. À savoir : vérification des enregistrements Open VSX et npm, avec correction des premières informations erronées.

Auteur : équipe technique APIYI
Échanges techniques : contactez-nous depuis la page d’accueil APIYI, sur apiyi.com. Pour plus d’informations sur l’intégration, consultez le centre de documentation docs.apiyi.com.

Articles connexes

• Extension Claude Code empoisonnée : porte dérobée dans la version 2.1.313, 5 étapes pour la détecter et la supprimer: Le 29 octobre, Claude Code 2.1.312 et 2.1.313 sur Cursor Marketplace ont exposé jusqu’à 5 000 utilisateurs à une porte dérobée SSH : en 5 étapes, vérifiez la clé publique svc-telemetry, supprimez LaunchAgent et les tâches planifiées, passez à la version 2.1.314+ et renouvelez vos accès GitHub, cloud et votre clé APIYI.
• Claude Max renommé Ultra : la limite de 5 heures a-t-elle été supprimée ? 3 changements à connaître: Claude Max 20x devient Ultra et Max 5x devient Max, sans changement de prix ; les comptes Ultra vérifiés n’ont plus de limite sur 5 heures, mais leur plafond hebdomadaire reste inchangé ; un tableau comparatif, 3 étapes de vérification et des calculs vous aident à décider si vous devez changer d’offre.