Open VSX a procédé au retrait de 77 evil twin extensions repérées sur sa place de marché. Ces paquets se présentaient comme des outils de développement authentiques, mais ils ont été observés en train d’envoyer des informations sur les environnements de travail des développeurs — parfois de façon très détaillée.
Selon Manifold Security, ces extensions malveillantes ont été publiées entre le 26 juillet et le 1er août 2026. Leur suppression a ensuite été confirmée au 3 août 2026.
Des extensions qui imitent des outils réels
Les chercheurs Ax Sharma et Cody Nash expliquent que, dans une large majorité des cas, les paquets n’expédient que des éléments limités, comme le nom d’hôte de la machine. Cependant, 19 extensions ont été identifiées comme capables de décrire plus précisément le contexte de travail.
Le scénario le plus frappant reste la manière dont l’attaque se fond dans l’écosystème : certains paquets reprennent les noms, namespaces et descriptions d’extensions Open VSX réelles. Ils sont ensuite publiés via des comptes sans lien apparent, avec de faibles numéros de version (par exemple 0.0.1).
Concrètement, l’essentiel de la tromperie repose sur un échange du contenu du fichier extension.js : l’objectif n’est plus de fournir la fonctionnalité annoncée, mais de capturer puis transmettre des données, le tout en se présentant comme de simples « anonymous usage metrics ».
Quelles données étaient envoyées ?
Les 77 paquets ne constituent pas un bloc unique. Les analyses distinguent notamment des versions légères et des charges plus avancées.
- 58 extensions : conçues pour exfiltrer principalement le hostname, et parfois le nom du dossier de l’espace de travail ou la version de l’éditeur.
- les autres extensions : variantes de reconnaissance envoyant davantage d’informations liées au poste et au projet, dont notamment le nom d’utilisateur du système, le nom et la version de l’éditeur, le type d’hôte, l’identifiant de machine, la plateforme et l’architecture, la locale et le fuseau horaire, ainsi que le nom et le chemin complet du dossier ouvert.
Malgré ces différences, un point commun apparaît : les paquets partageaient le même domaine d’exfiltration et des similarités de code et de comportement.
Retrait et point de collecte : mangorbit[.]com
Dans l’ensemble des 77 extensions, les données ont été envoyées vers mangorbit[.]com. Le domaine aurait été enregistré le 15 juillet 2026, soit 11 jours avant la première vague de publication des paquets.
Au-delà de l’envoi de données, les chercheurs notent une interface trompeuse : les extensions affichent un élément dans la barre d’état, accompagné d’un message indiquant que le composant est actif, puis déclenchent l’étape d’exfiltration.
Fonctions de reconnaissance : CI, dépôt Git et indicateurs de contexte
Une deuxième famille de charges a également été associée à des étapes supplémentaires, destinées à comprendre précisément où et comment les développeurs travaillent.
- Inspection des fichiers du répertoire .git pour récupérer des hôtes distants, des organisations, le domaine lié à l’adresse e-mail configurée, la branche courante et le SHA du commit HEAD.
- Recensement d’environ 60 identifiants d’extensions installées, puis récupération du hostname proxy depuis l’environnement.
- Détection d’indicateurs d’intégration continue (CI), et collecte séparée de valeurs comme GITHUB_REPOSITORY, CI_PROJECT_PATH, l’URI Azure DevOps, le slug d’organisation Buildkite, le nom d’utilisateur CircleCI, le nom des codespaces et des éléments de contexte Gitpod.
- Vérification du paramètre d’opt-out de télémétrie de l’éditeur, puis envoi de l’état correspondant.
Plan de secours DNS et mécanisme de relance
Les analyses indiquent aussi l’existence de mesures de contingence. Les variantes prévoyaient une récupération via enregistrement DNS TXT : si le domaine principal était bloqué ou retiré, les paquets pouvaient obtenir une URL d’exfiltration de secours.
Dans la variante de reconnaissance, les chercheurs observent un cycle de reprise plus persistant : environ 15 minutes, 50 minutes et 3h30 après l’initialisation, puis un relancement toutes les 7 à 8 heures. La collecte ne s’arrêterait qu’après sept jours.
Par ailleurs, un poste hors ligne, derrière un proxy ou dans un environnement où la première requête est abandonnée, déclencherait une relance sur la durée d’une semaine.
Repérer l’origine de l’installation
Un autre élément distinctif concerne la capacité à savoir si l’installation provient d’une configuration du dépôt ou d’un choix humain. La variante testait l’existence de références à l’ID de l’extension dans des fichiers du workspace, comme devcontainer.json ou .vscode/extensions.json, puis rendait ce résultat sous forme de drapeau unique.
En clair, cette information aide à répondre à une question opérationnelle : comment l’extension a été introduite et par quelle voie.
Les noms d’extensions affectées
Les chercheurs listent ci-dessous les 19 extensions identifiées dans cette seconde catégorie de collecte. Cette liste sert d’illustration des cas observés, sans forcément couvrir l’ensemble des variantes :
- amd.gaia-vscode
- artsy.artsy-studio-extension-pack
- configcat.configcat-feature-flags
- iotaledger.iota-move
- marketplace.visualstudio
- obyte.oscript-vscode-plugin
- openeuphoria.vscode-euphoria
- oss.sfmc-devtools-vscode
- rumbledb.jsoniq-vscode
- ssagov.uef-snippets
- taskfile.vscode-task
- doi.fileheadercomment
- mengsiCode.vscode-django-boilerplate
- move.move-analyzer
- uavcan.dsdl
- vs-publisher-988541.apexsql-power-tools
- casualjim.gotemplate
- jcamp.dotnet-test-provider-view
- superposition.supertoml-analyzer
Une attaque plus large de type supply chain
La découverte ne s’arrête pas aux extensions Open VSX. Le rapport mentionne également une campagne de chaîne d’approvisionnement logicielle baptisée ChainDrop, impliquant 450 packages npm répartis sur 2 244 artefacts.
L’objectif annoncé est de délivrer un voleur d’informations et d’en tirer parti pour pousser des versions trojanisées. Microsoft signale que certains schémas reposent sur une variante baptisée Mini Shai-Hulud, pouvant s’exécuter automatiquement via un hook de cycle de vie npm preinstall, avant que l’installation ne soit terminée.
Le malware peut aussi utiliser des identifiants GitHub compromis pour injecter des fichiers de configuration dans des dépôts, créant ainsi une persistance et une voie d’infection supplémentaire entre développeurs.
Pourquoi bloquer “les scripts” ne suffit pas
Des experts soulignent que ce type d’attaque met en évidence une limite des défenses courantes. OX Security note que les stratégies centrées uniquement sur le blocage des install scripts et sur l’activation de la 2FA pour les mainteneurs ne couvrent pas l’ensemble du risque.
Le besoin, selon les analyses citées, est d’instaurer un contrôle granulaire des permissions : qu’un package ait ou non l’autorisation d’accéder à des ressources sensibles et d’en extraire des données, par exemple des clés AWS ou des identifiants GitHub, sans que cela soit possible par un simple appel.
Que faire maintenant ?
Avec la suppression des evil twin extensions, l’étape suivante consiste à vérifier si votre environnement a été exposé. Si vous utilisez Open VSX ou un flux de dépendances intégrant des extensions, examinez l’historique d’installations, contrôlez les versions actuelles et surveillez tout comportement inhabituel (processus réseau, exfiltration, fichiers modifiés côté CI ou configuration).
Enfin, gardez un œil sur les bonnes pratiques de durcissement : réduire les permissions des workflows, segmenter l’accès aux secrets et limiter ce qui peut être exécuté automatiquement pendant les installations.
Conclusion : le retrait de 77 evil twin extensions montre à quel point l’écosystème des outils de développement peut être exploité par des acteurs qui imitent des projets légitimes. En combinant vol de données, reconnaissance du contexte de travail et mécanismes de contournement, ces paquets ont cherché à collecter des informations précieuses. La vigilance et une stratégie de permissions plus fines restent essentielles pour limiter l’impact des futures campagnes.
Source: https://thehackernews.com/2026/08/open-vsx-removes-77-malicious-evil-twin.html
