GlassWorm est de retour : 73 extensions « dormantes » publiées sur OpenVSX — la marketplace alternative pour Visual Studio Code et VSCodium — viennent d’être identifiées comme un vecteur de chaîne d’approvisionnement orchestré par les opérateurs du malware GlassWorm. Pour les PME et ETI dont les équipes développement utilisent ces extensions au quotidien, l’impact peut être immédiat : vol de tokens cloud, exfiltration de variables d’environnement et compromission silencieuse des pipelines CI/CD.
GlassWorm sur OpenVSX : ce qu’il faut savoir
La campagne GlassWorm repose sur un schéma désormais classique mais redoutable : publier des extensions légitimes ou utilitaires, attendre quelques semaines voire mois (d’où le terme « sleeper »), puis pousser une mise à jour malveillante via le mécanisme automatique d’OpenVSX. Au moment du déclenchement, l’extension exécute du code obfusqué qui :
- Lit les fichiers
.env, les configurations Git et les tokens stockés dans le système d’exploitation. - Capture les identifiants cloud (AWS, GCP, Azure) accessibles via les CLI installés sur le poste.
- Installe une porte dérobée persistante qui survit aux désinstallations de l’extension.
- S’auto-propage en publiant de nouvelles extensions infectées avec les credentials volés des éditeurs compromis.
BleepingComputer a recensé 73 extensions infectées au moment de la publication. La marketplace OpenVSX, utilisée notamment par VSCodium, Cursor, Theia et plusieurs IDE forkés, ne dispose pas du même niveau de signature et de revue que le marketplace officiel de Microsoft.
Pourquoi cette campagne GlassWorm vise les PME-ETI
Les extensions VS Code sont devenues un point d’attaque privilégié car elles bénéficient d’une confiance implicite : elles s’exécutent dans le contexte du développeur, avec accès aux clés SSH, aux registres de paquets internes et aux secrets de production. Pour une PME industrielle qui utilise un IDE forké comme Cursor pour ses développements internes, un seul poste compromis peut donner accès à l’ensemble du SI.
Indicateurs de compromission à surveiller
- Connexions sortantes inattendues vers des domaines en
.xyz,.topou des IP basées sur Tor depuis les postes développeurs. - Mise à jour récente d’extensions installées via OpenVSX que vous n’aviez pas validée.
- Apparition de nouveaux processus enfants de
Code.exeoucodiumexécutant Node.js avec arguments inhabituels. - Tentatives d’accès au keychain ou au gestionnaire d’identifiants Windows depuis l’IDE.
Plan de réponse en 6 étapes face à GlassWorm
- Inventaire immédiat : recensez toutes les extensions VS Code/VSCodium/Cursor installées sur les postes développeurs. Une commande comme
code --list-extensionsexécutée à distance via votre EDR ou MDM permet de centraliser la liste. - Croiser avec la liste GlassWorm : comparez votre inventaire à la liste publiée par BleepingComputer et l’équipe sécurité d’OpenVSX. Désinstallez immédiatement toute extension correspondante.
- Rotation des secrets : faites tourner tous les tokens cloud, les clés SSH et les credentials de registres privés (npm, GitHub, GitLab, artifactory) accessibles depuis les postes potentiellement infectés.
- Allowlist d’extensions : déployez une politique restreignant les extensions autorisées via la configuration
extensions.allowlistou un IDE managé. Ne tolérez que les extensions auditées. - Surveillance EDR : créez des règles spécifiques sur les processus enfants des IDE et les accès aux fichiers
.env,.aws/credentials,~/.ssh/. - Communication interne : prévenez les équipes dev. La sensibilisation aux risques de la supply chain côté IDE est encore trop faible.
Bonnes pratiques pour limiter le risque GlassWorm à long terme
La menace GlassWorm illustre une tendance plus large : les attaquants ne ciblent plus uniquement les paquets npm ou PyPI, mais l’ensemble de l’écosystème outils du développeur. Trois mesures structurantes :
- Préférez le marketplace officiel de Microsoft pour VS Code lorsque c’est possible — il dispose de processus de signature et de takedown plus matures qu’OpenVSX.
- Isoler les environnements de développement : passez à des dev containers ou des VM dédiées, pour éviter qu’une extension compromise n’accède aux secrets du poste personnel.
- Auditez la chaîne complète : extensions IDE, paquets, images Docker, runners CI. Un audit annuel ne suffit plus — l’automatisation continue est désormais incontournable.
Pour aller plus loin sur la sécurisation des outils dev, consultez notre article dédié à la sécurisation des assistants IA dans le code et notre guide sur la supply chain npm après l’incident Bitwarden CLI.
GlassWorm n’est qu’un symptôme : tant que les marketplaces d’extensions resteront un angle mort de la chaîne d’approvisionnement, ces attaques se répéteront. Auditez vos extensions OpenVSX aujourd’hui — pas demain.