4 min de lecture
77 extensions Open VSX, publiées entre le 26 juillet et le 1er août 2026, se faisaient passer pour des outils AMD, Azure, Salesforce ou IOTA. Les plus abouties fouillaient le dossier .git, listaient les variables d’environnement CI/CD, et renvoyaient tout ça vers un domaine enregistré onze jours avant la première publication.
Un domaine créé avant même la première extension
On voit passer beaucoup de campagnes de typosquatting sur des registries de paquets, mais celle-ci a un détail qui mérite qu’on s’y arrête : le domaine d’exfiltration, mangorbit.com, a été enregistré le 15 juillet 2026, soit onze jours avant la publication de la première extension malveillante.
Note du PandaRedacteur: Ce n’est pas de l’opportunisme, c’est une campagne préparée aux petite oignons. Ou tout simplement un travail a finaliser avant de partie en vacances :)
Manifold Security a baptisé la campagne “Evil Twin” parce que chaque extension malveillante se présentait comme le jumeau d’un outil légitime : des noms qui évoquent AMD (amd.gaia-vscode), Azure, Salesforce, ConfigCat, ou encore le projet IOTA (iotaledger.iota-move). Rien d’exotique dans le nommage ; c’est justement ce qui les rendait crédibles dans une recherche rapide sur le marketplace.
Un développeur qui cherche une extension officielle ne vérifier rarement l’éditeur avec la même rigueur qu’il vérifierait un package npm en production. La confiance implicite dans l’IDE, c’est la surface d’attaque.
Les chercheurs ont réussi à relier les 77 extensions à la même campagne grâce à un domaine d’exfiltration partagé et à des similarités de code et de comportement réseau — la marque de fabrique d’un opérateur unique qui a industrialisé la publication.
Deux niveaux de sophistication, un seul objectif
Il y a ici deux familles bien différentes dans le même lot :
- 58 extensions “légères” : elles se contentent de renvoyer le hostname de la machine, parfois le nom du dossier workspace et la version de l’éditeur. Peu de bruit, peu de valeur immédiate — probablement un moyen de cartographier les victimes avant une seconde vague.
- 19 extensions “profondes” : nom d’utilisateur OS, hostname, identifiant machine, éditeur et version, architecture, locale, fuseau horaire, et surtout le chemin complet du dossier workspace. Ces dix-neuf-là allaient inspecter le répertoire
.gitpour en extraire les remotes, l’organisation associée, le domaine de l’email configuré, la branche courante et le hash du commitHEAD.
Note du PandaRedacteur : le jour où une extension VS Code lit votre
.git/configavant même que vous ayez tapé une ligne de code, ce n’est plus une extension, c’est un stagiaire curieux avec un accès peu recommandable.
Et surtout : les extensions les plus poussées énuméraient plusieurs dizaines d’extensions installées et allaient chercher des identifiants d’environnements CI/CD et cloud — GitHub, GitLab, Azure DevOps, Buildkite, CircleCI, GitHub Codespace, Gitpod. Sur un poste de développeur ordinaire, c’est gênant. Sur un runner CI ou un Codespace éphémère où l’extension s’installe automatiquement via devcontainer.json ou .vscode/extensions.json, c’est une porte ouverte directement sur la chaîne de build.
Une infrastructure de secours qui ne laisse rien au hasard
Ce qui distingue cette campagne d’un typosquatting artisanal, c’est la résilience de son infrastructure d’exfiltration. En cas d’échec du domaine principal, les extensions basculaient sur une requête DNS TXT pour récupérer une URL alternative => la même technique de dissimulation que je décrivais dans DNS TXT, quand l’injection de prompt se cache dans un enregistrement DNS. Le rythme des tentatives suivait un calendrier précis : ~15 minutes, puis 50 minutes, puis 3,5 heures, puis toutes les 7 à 8 heures pendant sept jours. De quoi survivre à un blocage réseau temporaire ou à un premier passage de filtrage DNS.
Impact potentiel
| Confidentialité | Critique | Structure `.git`, identité de la machine, variables d'environnement CI/CD exposées. |
| Intégrité | Élevé | Des identifiants CI/CD volés ouvrent la porte à une modification de la chaîne de build en aval. |
| Disponibilité | Faible | Aucun objectif de disruption observé dans cette campagne. |
| Réputation | Modéré | Impact direct sur les marques usurpées (AMD, Azure, Salesforce...) et sur la confiance dans le marketplace Open VSX. |
Ce que je vous recommande de vérifier
- Auditer la liste des extensions installées sur les postes de développement et dans les images
devcontainer.json/.vscode/extensions.jsonversionnées dans vos dépôts — ce sont elles qui déclenchent une installation automatique sans validation humaine. - Épingler les extensions à un éditeur et un identifiant vérifiés plutôt qu’à un simple nom, et bloquer les extensions récemment publiées sur les postes qui touchent à la CI/CD.
- Surveiller les résolutions DNS TXT sortantes depuis les runners CI et les Codespaces : c’est un canal rarement filtré et de plus en plus utilisé comme fallback de C2, qu’on parle d’extensions IDE ou d’agents de codage.
- **Faire tourner les secrets et tokens CI/CD **(GitHub, GitLab, …) si une extension Open VSX inconnue a été installée sur un poste ou un environnement éphémère entre le 26 juillet et le 1er août 2026.