77 extensions Open VSX espionnaient les développeurs — la supply chain des IDE est le nouveau maillon faible

4 août 2026. Manifold Security publie le rapport d’une campagne de 77 extensions malveillantes sur le marketplace Open VSX, le registre ouvert d’extensions pour les éditeurs compatibles VS Code (VSCodium, Eclipse Theia, Gitpod, Code OSS). L’opération, baptisée « evil twin », a duré du 26 juillet au 1er août 2026 — une semaine pendant laquelle des milliers de développeurs ont potentiellement exécuté du code de reconnaissance dans leur environnement de travail.

Les chiffres donnent l’échelle : 58 extensions envoyaient des informations système sommaires ; 19 extensions allaient beaucoup plus loin, exfiltrant les métadonnées des dépôts Git, les variables d’environnement CI et les chemins de projets locaux. Une seule infrastructure d’exfiltration — un domaine partagé — reliait l’ensemble des 77 extensions au même opérateur.

Le mode opératoire : l’evil twin qui se fait passer pour l’original

Les attaquants n’ont pas créé des extensions de toutes pièces. Ils ont cloné des extensions légitimes et populaires — des evil twins — en reproduisant leur nom, leur description et leurs métadonnées. Un développeur qui cherchait « Prettier », « ESLint » ou « GitLens » sur Open VSX pouvait tomber sur une copie malveillante sans s’en rendre compte.

Le code malveillant était intégré dans le post-install script de l’extension — un hook qui s’exécute automatiquement après l’installation, sans interaction utilisateur. Pas de dialogue suspect, pas d’autorisation à donner. L’extension s’installe, le script tourne, les données partent.

Ce qui distingue cette campagne des précédentes attaques typosquatting sur npm ou PyPI, c’est la cible. Les extensions IDE ont accès à l’environnement de développement complet : le système de fichiers local, les dépôts Git clonés, les clés SSH en mémoire, les tokens d’API dans les variables d’environnement. Une extension malveillante ne vole pas un package — elle vole le contexte de travail du développeur.

19 extensions en mode reconnaissance profonde

Manifold Security a catégorisé les extensions en deux groupes. Les 58 extensions « légères » collectaient des informations basiques : version de l’OS, type de CPU, version de VS Code. Du fingerprinting classique, probablement destiné à identifier des cibles à haute valeur.

Les 19 extensions « lourdes » allaient bien plus loin :

• Métadonnées Git : noms de dépôts, branches actives, URLs de remotes — de quoi identifier les organisations et les projets sur lesquels travaille la victime.
• Variables d’environnement CI : tokens d’accès, adresses de registres privés, clés de déploiement. Si la victime développait sur un poste connecté à un pipeline CI/CD, ces variables donnent un accès direct à l’infrastructure.
• Chemins de projets locaux : une carte complète de l’arborescence de travail, révélant la nature des projets (frontend, backend, infrastructure) et les technologies utilisées.

L’ensemble était exfiltré vers un domaine unique contrôlé par l’attaquant, découvert par Manifold Security en analysant le trafic réseau des extensions après installation.

Open VSX : la face cachée de l’écosystème VS Code

Open VSX est le registre d’extensions utilisé par les forks open source de VS Code : VSCodium, Eclipse Theia, Gitpod, Code OSS. Contrairement au Visual Studio Marketplace de Microsoft, qui impose une vérification des éditeurs (Publisher Verification) et des analyses automatisées des extensions publiées, Open VSX a historiquement fonctionné avec une modération plus légère — un compromis assumé pour maximiser l’ouverture de la plateforme.

L’attaque expose la tension entre ouverture et sécurité dans les écosystèmes de plugins. VS Code lui-même compte plus de 50 000 extensions sur le marketplace Microsoft ; Open VSX en héberge des milliers d’autres, souvent portées ou synchronisées automatiquement. La surface d’attaque est colossale, et les outils de détection automatisée — analyse statique du code des extensions, sandboxing des post-install scripts — restent embryonnaires.

Microsoft a introduit en 2025 le Extension Runtime Sandbox qui isole les extensions dans un processus séparé avec des permissions limitées. Mais cette sandbox n’est active que sur le marketplace officiel et ne couvre pas encore tous les scénarios. Open VSX n’a pas d’équivalent.

Ce que les équipes DevOps doivent faire maintenant

L’attaque des 77 extensions Open VSX n’est pas un incident isolé. Elle s’inscrit dans une tendance documentée tout au long de 2026 : 77 % des développeurs utilisent des extensions tierces dans leur IDE, et la surface d’attaque de ces extensions dépasse désormais celle des dépendances logicielles classiques.

Voici les actions concrètes pour vos équipes :

• Auditez vos extensions IDE. Si vos développeurs utilisent VSCodium ou tout éditeur basé sur Open VSX, exécutez ls ~/.vscode-oss/extensions/ et croisez chaque extension avec le rapport de Manifold Security.
• Bloquez l’exécution automatique des post-install scripts. VS Code permet de désactiver les scripts d’installation via le paramètre extensions.autoUpdate et en auditant manuellement les nouvelles installations.
• Migrez vers le marketplace Microsoft vérifié pour les environnements de production. Le Publisher Verification et la sandbox d’extension réduisent significativement le risque — même s’ils ne l’annulent pas.
• Isolez les environnements de développement. Un développeur qui travaille sur du code critique ne devrait pas partager le même poste et les mêmes extensions que son IDE de side project. La segmentation des environnements limite le blast radius d’une extension compromise.
• Surveillez les connexions réseau sortantes des postes de développement. Les 77 extensions exfiltraient vers un domaine unique — une règle de pare-feu sur les postes de dev aurait détecté l’anomalie.

Verdict

L’attaque des 77 extensions Open VSX change un paradigme. La supply chain logicielle ne s’arrête plus aux dépendances npm, PyPI ou Maven. Elle remonte jusqu’à l’outil qui écrit le code — l’IDE et ses extensions. Un plugin « Prettier » malveillant a autant de pouvoir qu’un package npm : il peut voler vos secrets, cartographier vos projets et compromettre vos pipelines CI/CD.

Si votre équipe utilise des éditeurs basés sur Open VSX, l’audit des extensions n’est plus une bonne pratique — c’est une obligation de sécurité immédiate. La campagne de Manifold Security a duré une semaine. La prochaine pourrait durer un mois sans être détectée.

Références

• BleepingComputer, « 77 Open VSX extensions found harvesting developer info », 4 août 2026, par Lawrence Abrams.
• Manifold Security, rapport sur la campagne d’extensions Open VSX, publié le 4 août 2026.
• Eclipse Foundation, « Open VSX Registry », consulté le 5 août 2026.
• Microsoft, « VS Code Extension Runtime Sandbox », documentation, consulté le 5 août 2026.