Entre le 26 juillet et le 1er août 2026, 77 extensions malveillantes ont été publiées sur Open VSX, le marketplace open source d'extensions pour VS Code géré par la Fondation Eclipse. Identifiées par les chercheurs de Manifold Security, ces extensions utilisaient la technique dite de l'« evil twin » : elles reproduisaient fidèlement le nom, le logo, la description et le namespace d'extensions populaires du VS Code Marketplace officiel de Microsoft, tout en intégrant du code malveillant qui s'exécutait silencieusement en arrière-plan.
L'attaque n'est pas anodine. Selon le rapport publié par The Hacker News le 4 août 2026, 58 des 77 extensions exfiltraient des informations système basiques — hostname, nom d'utilisateur, système d'exploitation, version de VS Code. Plus préoccupant : 19 extensions collectaient des données bien plus sensibles, notamment des métadonnées Git (adresses des remotes, emails de commit, branches actives), des identifiants CI/cloud stockés en variables d'environnement (tokens GitHub, credentials Azure DevOps, clés AWS), et des fichiers de configuration critiques comme .env, .npmrc et .docker/config.json.
Pour les développeurs freelances français qui utilisent VS Code au quotidien — et ils représentent la grande majorité de la communauté — cette attaque illustre un problème systémique : la supply chain des extensions IDE est devenue un vecteur d'attaque majeur, comparable aux attaques sur npm, PyPI ou les GitHub Actions que nous avons déjà analysées. Décryptage complet de l'incident, de son impact, et des mesures de protection à adopter immédiatement.
Chronologie de l'attaque : 7 jours pour compromettre des milliers de développeurs
L'attaque s'est déroulée en une semaine, selon la reconstitution publiée par Bleeping Computer. Le 26 juillet 2026, les premiers lots d'extensions sont apparus sur Open VSX. Les attaquants ont procédé par vagues : d'abord 12 extensions ciblant les outils de formatage (Prettier, Black Formatter), puis 25 extensions ciblant les linters (ESLint, Pylint), et enfin 40 extensions couvrant des outils de productivité et d'infrastructure (GitLens, Docker, Remote SSH). Chaque vague était plus sophistiquée que la précédente, avec un code d'exfiltration de plus en plus discret et des techniques d'obfuscation avancées utilisant du code base64 imbriqué dans des fichiers de configuration légitimes.
Le choix d'Open VSX plutôt que du VS Code Marketplace officiel est stratégique. Open VSX est utilisé par défaut dans plusieurs distributions open source de VS Code — notamment VSCodium, code-server (utilisé dans les environnements Gitpod et GitHub Codespaces en mode open source), et Eclipse Theia. Les développeurs qui utilisent ces distributions pour éviter les télémétries de Microsoft se retrouvent paradoxalement exposés à un risque de sécurité plus élevé sur la supply chain des extensions.
Manifold Security a détecté les premières anomalies le 30 juillet grâce à un système d'analyse automatique qui compare le comportement runtime des extensions avec leurs descriptions de permissions. L'alerte a été transmise à l'équipe Open VSX le 1er août, et les 77 extensions ont été retirées le 3 août. Cependant, le délai de 7 jours entre la première publication et le retrait a laissé une fenêtre d'exposition significative. Open VSX ne publie pas de chiffres de téléchargement détaillés, mais Manifold Security estime que plusieurs milliers de développeurs dans le monde ont pu installer au moins une de ces extensions.
💡 Notre avis d'expert
"Le timing de l'attaque est révélateur. Fin juillet, beaucoup de développeurs français sont en congés ou en effectif réduit. Les équipes de sécurité sont moins réactives, les revues de code moins fréquentes. C'est exactement le moment où les attaquants frappent. Pour les équipes qui utilisent VSCodium ou code-server connecté à Open VSX, la question n'est pas de savoir si un incident similaire se reproduira — c'est quand."
Anatomie d'une extension evil twin : comment l'attaque fonctionne
Le mécanisme d'une extension evil twin est redoutablement simple. L'attaquant identifie une extension populaire sur le VS Code Marketplace officiel — par exemple, esbenp.prettier-vscode (Prettier) avec ses 45 millions d'installations. Il crée ensuite un compte sur Open VSX avec un namespace similaire ou identique (la vérification d'identité étant moins stricte), et publie une extension portant le même nom, le même logo, la même description, et le même README.md que l'originale. La seule différence : du code malveillant injecté dans le fichier extension.js ou dans un fichier de configuration chargé au démarrage.
Manifold Security a détaillé trois niveaux de malveillance dans les 77 extensions découvertes. Le premier niveau (58 extensions) se contentait de récupérer des informations système basiques via l'API os de Node.js : hostname, nom d'utilisateur, système d'exploitation, architecture CPU, version de VS Code. Ces données étaient envoyées en POST à un serveur de commande et contrôle (C2) hébergé sur un domaine jetable. Ce premier niveau servait probablement de phase de reconnaissance : identifier les cibles intéressantes avant de déployer des payloads plus agressifs.
Le deuxième niveau (14 extensions) accédait aux métadonnées Git de l'espace de travail ouvert. En appelant git remote -v, git config user.email, et git log --oneline -5 via child_process.exec(), les extensions récupéraient l'adresse du dépôt distant, l'email du développeur, et les derniers messages de commit. Ces informations permettent de cartographier les projets sur lesquels un développeur travaille, d'identifier des dépôts privés, et de préparer des attaques de spear phishing ciblées.
Le troisième niveau (5 extensions) était le plus dangereux. Ces extensions scannaient les variables d'environnement à la recherche de patterns connus : GITHUB_TOKEN, AZURE_DEVOPS_PAT, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, DOCKER_PASSWORD, NPM_TOKEN. Elles cherchaient également des fichiers de configuration sensibles dans le répertoire home de l'utilisateur : ~/.env, ~/.npmrc, ~/.docker/config.json, ~/.aws/credentials, ~/.kube/config. Le contenu de ces fichiers était exfiltré vers le serveur C2, donnant aux attaquants un accès direct aux pipelines CI/CD, aux registres de conteneurs, et aux infrastructures cloud des victimes.
💡 Notre avis d'expert
"Ce qui rend l'attaque evil twin particulièrement efficace, c'est que les extensions VS Code s'exécutent avec les mêmes privilèges que l'IDE lui-même. Elles ont accès au système de fichiers, aux variables d'environnement, au réseau, et peuvent exécuter des commandes arbitraires via child_process. C'est un privilège énorme pour du code qui est souvent installé d'un clic sans aucune revue. Nous recommandons systématiquement à nos clients de maintenir une whitelist d'extensions approuvées."
Open VSX vs VS Code Marketplace : deux modèles de sécurité différents
Pour comprendre pourquoi cet incident s'est produit sur Open VSX et non sur le VS Code Marketplace, il faut comparer les modèles de sécurité des deux plateformes. Le VS Code Marketplace de Microsoft exige que chaque éditeur (publisher) se vérifie via un compte Azure DevOps, avec une vérification d'identité liée à une adresse email professionnelle ou un compte Microsoft. Les extensions sont également soumises à un scan antivirus et à une analyse statique basique. Open VSX, géré par la Fondation Eclipse en tant que projet communautaire, a historiquement appliqué des contrôles plus souples pour favoriser l'adoption et faciliter la publication par les mainteneurs open source.
Cette différence de modèle n'est pas un défaut intrinsèque d'Open VSX — c'est un compromis délibéré entre accessibilité et sécurité. Open VSX a été créé pour offrir une alternative libre au marketplace propriétaire de Microsoft, et les contraintes légères d'inscription étaient cohérentes avec la philosophie open source. Mais le succès croissant d'Open VSX — utilisé par défaut dans VSCodium, Gitpod, et de nombreux environnements cloud — a changé l'équation de risque. L'attaque des 77 extensions evil twin démontre que la base d'utilisateurs a atteint un seuil qui rend le marketplace attractif pour les attaquants sophistiqués.
Il faut toutefois noter que le VS Code Marketplace n'est pas à l'abri. En janvier 2026, une recherche de l'université de Twente (Pays-Bas) avait identifié 46 extensions malveillantes sur le VS Code Marketplace officiel, exploitées pendant plusieurs mois avant leur retrait. Et en mars 2026, The Hacker News avait rapporté un incident similaire touchant 30 extensions qui exfiltraient des données vers des serveurs en Asie du Sud-Est. Le problème est structurel : les marketplaces d'extensions fonctionnent comme les registres de paquets (npm, PyPI), et souffrent des mêmes vulnérabilités de supply chain.
| Critère | VS Code Marketplace | Open VSX |
|---|---|---|
| Vérification publisher | Azure DevOps + email pro | Compte Eclipse basique |
| Scan antivirus | Oui (automatique) | Partiel |
| Analyse statique | Oui (basique) | Non |
| Namespace protection | Publisher lié au namespace | Namespace libre |
| Délai retrait signalement | 24-72h | 48-96h |
| Incidents connus (2026) | 46 extensions (janvier) | 77 extensions (juillet-août) |
| Utilisateurs principaux | VS Code (Microsoft) | VSCodium, Gitpod, Theia |
La supply chain des extensions IDE : un vecteur d'attaque en pleine croissance
L'incident Open VSX s'inscrit dans une tendance plus large : les attaques de supply chain ciblant les outils de développement sont en croissance exponentielle. Selon le rapport State of Software Supply Chain de Sonatype, le nombre d'attaques supply chain sur les écosystèmes open source a augmenté de 742% entre 2019 et 2025. Les extensions IDE sont le dernier maillon de cette chaîne à être ciblé de manière systématique.
Le modèle d'attaque est logique du point de vue de l'attaquant. Un développeur installe en moyenne 15 à 25 extensions dans son IDE. Chaque extension s'exécute dans le même processus que l'éditeur, avec accès au système de fichiers, aux variables d'environnement, au réseau, et à la possibilité d'exécuter des sous-processus. C'est un privilège comparable à un accès shell complet sur la machine du développeur. Et contrairement aux dépendances npm ou pip, qui font l'objet d'une attention croissante en matière de sécurité, les extensions IDE restent un angle mort dans la plupart des politiques de sécurité d'entreprise.
Pour les développeurs français travaillant dans des contextes réglementés — banques, assurances, santé, défense — cette situation est particulièrement critique. Les exigences de la directive NIS2 et du Cyber Resilience Act européen imposent une maîtrise de la supply chain logicielle, y compris les outils de développement. Un développeur freelance qui installe une extension compromise sur un poste de travail connecte à l'infrastructure d'un client bancaire crée un vecteur d'attaque direct vers des systèmes critiques.
💡 Notre avis d'expert
"L'un des aspects les plus sous-estimés de cette attaque, c'est l'impact sur les développeurs freelances qui travaillent pour plusieurs clients. Un freelance à Paris qui a installé une de ces extensions evil twin a potentiellement exposé les credentials de tous les projets clients ouverts dans son VS Code — une startup fintech, une PME industrielle, un grand compte bancaire. La compromission d'un seul poste de développeur peut se propager à des dizaines d'organisations. C'est pourquoi nous recommandons des workspaces isolés par client, avec des profils VS Code séparés."
Impact pour les développeurs français : une exposition réelle
La France est le troisième contributeur européen à l'écosystème open source derrière l'Allemagne et le Royaume-Uni, selon les chiffres de la Commission européenne. Les développeurs français sont particulièrement exposés à ce type d'attaque pour plusieurs raisons structurelles.
Premièrement, l'adoption de VSCodium est significative dans la communauté open source française. Les entreprises publiques et les organisations qui suivent les recommandations de la DINUM (Direction interministérielle du numérique) en matière de logiciels libres utilisent fréquemment VSCodium, qui se connecte à Open VSX par défaut. L'ironie est palpable : en choisissant une distribution open source de VS Code pour éviter la télémétrie Microsoft, ces organisations se retrouvent exposées à un marketplace moins sécurisé pour les extensions.
Deuxièmement, le tissu économique français du développement freelance augmente le risque de propagation latérale. Un freelance qui travaille pour trois ou quatre clients simultanément — ce qui est courant à Paris, Lyon, Toulouse ou Nantes — utilise le même IDE avec les mêmes extensions pour tous ses projets. Si une extension compromise exfiltre les credentials, elle les exfiltre pour tous les projets clients, multipliant l'impact d'un seul point de compromission. Nous avons déjà souligné ce risque dans notre analyse de la supply chain Python, mais le vecteur extensions IDE est encore moins surveillé.
Troisièmement, les environnements cloud de développement adoptés par les équipes françaises — Gitpod, GitHub Codespaces, ou des instances auto-hébergées de code-server — utilisent souvent Open VSX comme source d'extensions. Quand un développeur installe une extension dans un Codespace, elle s'exécute dans le contexte du conteneur de développement, avec accès aux secrets injectés par la plateforme. L'attaque ne cible plus seulement le poste local du développeur, mais l'infrastructure de développement entière de l'organisation.
Besoin d'un audit de sécurité supply chain pour votre équipe de développement ?
Nos experts sécurité open source auditent vos extensions IDE, dépendances, et pipelines CI/CD. Rapport complet en 48h — identifiez vos vulnérabilités avant les attaquants.
Demander un audit gratuitCe que ça signifie pour vous : comment se protéger concrètement
Si vous êtes développeur et que vous utilisez VS Code, VSCodium, ou tout environnement connecté à Open VSX, voici les actions immédiates à entreprendre pour vous protéger contre les extensions evil twin et les futures attaques supply chain.
- Vérifiez immédiatement vos extensions installées. Ouvrez la liste des extensions (
Ctrl+Shift+X) et pour chaque extension, vérifiez le publisher. Comparez avec le publisher officiel surmarketplace.visualstudio.com. Si une extension provient d'Open VSX et que vous ne l'avez pas installée volontairement depuis cette source, désinstallez-la immédiatement. - Effectuez une rotation de tous vos tokens et credentials. Si vous avez utilisé VSCodium ou une distribution connectée à Open VSX entre le 26 juillet et le 3 août 2026, considérez que vos credentials ont potentiellement été compromis. Régénérez vos tokens GitHub, clés AWS, credentials Azure DevOps, tokens npm, et tout autre secret stocké en variable d'environnement.
- Mettez en place une whitelist d'extensions. VS Code supporte le paramètre
extensions.alloweddans les settings managed pour restreindre les extensions installables à une liste approuvée. Pour les équipes, utilisez leextensions.jsondu workspace avec la propriétérecommendationset formez vos développeurs à n'installer que les extensions recommandées. - Séparez vos profils VS Code par client. Utilisez la fonctionnalité Profiles de VS Code pour créer un profil dédié par projet client, avec un ensemble d'extensions minimal et validé. Cela limite le blast radius en cas de compromission d'une extension à un seul contexte client.
- Surveillez les appels réseau de vos extensions. Utilisez des outils comme
Extension Host Log(accessible viaDeveloper: Show Running Extensions) pour identifier les extensions qui font des appels réseau inattendus. Toute extension de formatage ou de linting qui envoie du trafic HTTP est suspecte. - Auditez vos fichiers de configuration sensibles. Vérifiez les permissions de
~/.env,~/.npmrc,~/.docker/config.json,~/.aws/credentialset~/.kube/config. Ces fichiers ne devraient pas être lisibles par des processus qui n'en ont pas besoin. Considérez l'utilisation d'un gestionnaire de secrets (Vault, 1Password CLI, AWS Secrets Manager) plutôt que des fichiers plats.
💡 Notre avis d'expert
"Le reflexe le plus important à développer, c'est de traiter l'installation d'une extension IDE avec le même niveau de scrutiny qu'une dépendance npm ou un conteneur Docker. Lisez le code source avant d'installer. Vérifiez le publisher. Regardez le nombre d'installations et la date de dernière mise à jour. Si une extension a 200 installations et a été publiée il y a 3 jours, c'est un red flag. La sécurité supply chain n'est pas un problème que la technologie va résoudre seule — c'est un problème de comportement."
Perspectives : vers un renforcement de la sécurité des marketplaces d'extensions
L'incident des 77 extensions evil twin est un point d'inflexion pour la sécurité des marketplaces d'extensions IDE. La Fondation Eclipse a annoncé un plan de renforcement de la sécurité d'Open VSX incluant une vérification d'identité renforcée pour les publishers, un scan automatique des extensions à la publication, et un système de namespace protégé pour les extensions populaires. Ces mesures devraient être déployées au quatrième trimestre 2026.
Côté Microsoft, le VS Code Marketplace a également renforcé ses contrôles après l'incident de janvier 2026. L'introduction d'un système de signature cryptographique des extensions — similaire à Sigstore pour les conteneurs — est en cours de développement et devrait permettre aux développeurs de vérifier l'intégrité et l'authenticité d'une extension avant installation. La communauté open source française, via des organisations comme April et le CNLL, pousse pour que ces standards de sécurité soient adoptés de manière universelle.
En attendant ces améliorations, la responsabilité de la sécurité repose sur chaque développeur. La leçon de cet incident est claire : la confiance implicite dans les marketplaces d'extensions est désormais révolue. Chaque extension installée est un vecteur d'attaque potentiel, et les développeurs français — freelances comme salariés — doivent intégrer la vérification des extensions dans leur hygiène de sécurité quotidienne, au même titre que la mise à jour des dépendances ou la rotation des secrets.
FAQ — Questions fréquentes
Qu'est-ce qu'une extension evil twin sur Open VSX ?
Une extension evil twin est une extension malveillante qui usurpe le nom, le namespace et l'apparence visuelle d'une extension légitime du VS Code Marketplace. Publiée sur Open VSX (le marketplace open source alternatif), elle trompe les développeurs qui pensent installer l'extension originale. Les 77 extensions découvertes par Manifold Security imitaient des extensions populaires comme Prettier, ESLint, GitLens ou Docker.
Quelles données ont été exfiltrées par les extensions malveillantes ?
58 extensions exfiltraient des informations système basiques (hostname, OS, version VS Code). Les 19 plus dangereuses collectaient des métadonnées Git (remotes, branches, emails de commit), des identifiants CI/cloud stockés en variables d'environnement (tokens GitHub, credentials Azure DevOps, clés AWS), et des fichiers de configuration sensibles (.env, .npmrc, .docker/config.json).
Comment vérifier si j'ai installé une extension evil twin ?
Ouvrez VS Code, allez dans Extensions (Ctrl+Shift+X), et pour chaque extension installée, vérifiez le publisher. Comparez-le avec le publisher officiel sur le VS Code Marketplace (marketplace.visualstudio.com). Si le publisher diffère ou si l'extension vient d'Open VSX sans raison, désinstallez-la immédiatement. Après désinstallation, effectuez une rotation de tous vos tokens et credentials.
Open VSX est-il moins sécurisé que le VS Code Marketplace ?
Open VSX, géré par la Fondation Eclipse, applique des contrôles de vérification d'identité moins stricts que le VS Code Marketplace de Microsoft. Le VS Code Marketplace exige une vérification via Azure DevOps, tandis qu'Open VSX a historiquement permis la publication avec moins de friction. Cela ne signifie pas qu'Open VSX est intrinsèquement dangereux — le VS Code Marketplace a aussi eu des incidents similaires — mais le processus de vérification moins strict représente un vecteur que les attaquants exploitent.