GlassWorm menace Ouvrir VSX en profitant des unités d'extension

Les chercheurs en sécurité ont détecté une variation inquiétante de l'opération appelée GlassWorm qui attaque l'écosystème d'extension pour les éditeurs de code, et cette fois, il profite d'une particularité de l'enregistrement Open VSX. Au lieu d'intégrer directement un chargeur malveillant dans chaque paquet, les attaquants utilisent la relation entre les extensions pour transformer des suppléments apparemment inoffensifs en vecteurs de livraison en mises à jour ultérieures. Cela signifie qu'une extension qui semble légitime au début peut, avec une mise à jour simple, commencer à télécharger le code lié à Glasgow sans que l'utilisateur s'y attende. Vous pouvez lire le rapport technique de l'entreprise qui l'a documenté ici: Socket - Campagne VSX transitoire en verre.

Le mécanisme qu'ils exploitent est basé sur la façon dont les éditeurs installent les extensions indiquées dans les métadonnées : à la fois les propriétés extensionPack et extensionDependences dans le paquet. Le fichier json fait également installer les extensions listées par l'éditeur. Cette logique, conçue pour faciliter l'expérience du développeur, devient dangereuse lorsqu'un acteur malveillant publie d'abord une extension inoffensive et la met ensuite à jour pour déclarer des dépendances aux paquets compromis. La documentation officielle sur le fonctionnement de ces manifestes permet de comprendre les détails techniques : VS Dossier d'extension de code, et le registre où beaucoup de ces extensions sont conservées est Ouvrir VSX.

Selon Socket, depuis la fin de janvier 2026, des dizaines d'extensions malveillantes ont été identifiées dans Open VSX qui imitaient l'utilité commune pour les développeurs : linters, formateurs, codeurs et suppléments conçus pour les assistants de programmation IA. Parmi les signes d'abus, on peut citer l'utilisation de codes d'utilisation plus agressifs, la rotation des adresses de paiement dans la chaîne de blocs Solana et l'utilisation de ces transactions comme « goutte morte » pour résoudre les serveurs de commande et de contrôle; des techniques visant à améliorer la résilience de l'attaque contre l'atténuation traditionnelle.

Parallèlement, les chercheurs d'Aikido ont documenté une tactique complémentaire qui a été vue dans les dépôts GitHub et les paquets npm : l'insertion de caractères Unicode invisibles dans le code source pour cacher un chargeur. Bien que ces caractères ne soient pas appréciés lors de la lecture du fichier dans un éditeur, l'interprétation ultérieure permet le décodage et l'exécution d'une première étape qui à son tour récupère une deuxième étape avec des capacités d'exfiltration des jetons, des lettres d'identité et des secrets. L'analyse de l'aikido avec des exemples et des échantillons techniques est disponible ici: Aikido - GlassWorm retourne: attaque unicode, et un échantillon spécifique de l'utilisation de ces caractères dans un commit peut être trouvé dans ce bouton de requête: Commit avec des caractères invisibles.

L'ampleur de cette infection à source ouverte était remarquable : Aikido a estimé que plus d'une centaine de dépôts à GitHub ont été touchés dans la première semaine de mars 2026, et au moins deux paquets npm avec la même technique ont été détectés, ce qui indique une opération coordonnée couvrant différentes plateformes de distribution de logiciels.

Pour sa part, la recherche d'Endor Labs a mis sur la table une autre variation de la menace dans l'écosystème de npm, où des dizaines de paquets malveillants publiés par des comptes réduits ont été trouvés entre novembre 2025 et février 2026. Ces paquets utilisaient ce qu'on appelle les dépendances dynamiques distantes : les dépendances dont l'origine est une URL HTTP externe au lieu de l'enregistrement lui-même. Cette capacité permet aux opérateurs de modifier le code qui est livré sans publier une nouvelle version dans le registre, ce qui complique la détection et le blocage. Le rapport Endor Labs, avec ses constatations et observations sur les risques de dépendances éloignées, est ici: Endor Labs - Retour de Phantom Corbeau.

L'auteur de ces vagues a été discuté : bien que certains aient analysé la campagne dans le cadre du collectif PhantomRaven, Endor Labs a émis des doutes et des suggestions quant au fait qu'une partie du phénomène pourrait répondre à des expériences de sécurité ou à des recherches, en signalant des signaux d'alarme tels que la collecte de données de masse, la rotation délibérée des comptes et le manque de transparence des paquets. Vous pouvez voir le contexte sur PhantomRaven et l'analyse supplémentaire dans la note de Sonatype: Sonatype - Fantôme Raven npm malware.

Au-delà de la paternité, il y a une leçon technique claire : lorsqu'un paquet ou une extension dépend de ressources qui ne sont pas mises en version dans le registre - soit les paquets distants, soit les adresses de la chaîne de verrouillage qui changent ou les dépendances transitoires ajoutées par les mises à jour - le contrôle du comportement est laissé à la publicité. Cela transforme l'offre open source en une surface d'attaque dynamique où une mise à jour apparemment banale peut introduire des fonctionnalités avec des permissions étendues et des conséquences graves.

Qu'est-ce que cela signifie pour les développeurs et les équipements qui construisent des logiciels? Premièrement, il faut changer la mentalité concernant la confiance implicite qui est déposée dans les extensions et paquets populaires : la réputation peut être achetée ou recréée et un paquet légitime aujourd'hui peut devenir dangereux demain. Deuxièmement, il convient d'inspecter les manifestes et la chaîne de dépendances avant d'incorporer des librairies ou des extensions dans des environnements de production, en prêtant attention aux entrées non standard telles que les dépendances ciblant les URL externes, et les métadonnées qui ajoutent des paquets supplémentaires tels que extensionPack ou extensionDependences.

Il est également important de protéger les titres de créance et les jetons avec des politiques minimales de privilège et de rotation périodique, d'éviter de stocker des secrets dans des variables d'environnement non protégées, d'utiliser des dépôts privés ou des miroirs contrôlés si possible, et d'appliquer une analyse automatisée de la chaîne d'approvisionnement qui détecte les comportements suspects. L'analyse logicielle et les outils de numérisation d'unité peuvent aider à identifier les paquets qui incorporent du code à partir de sources extérieures au registre ou faire des appels inhabituels à l'environnement de fonctionnement.

Enfin, la communauté et la tenue de documents ont un rôle clé à jouer : examiner et resserrer les processus d'édition, déployer des mécanismes pour détecter les modèles d'obfuscation et les dépendances dynamiques, et donner des signaux clairs à l'utilisateur quant à l'origine et à la portée de ce qui est installé. Open VSX et d'autres dépôts ont déjà pris des mesures pour supprimer les extensions malveillantes, mais la réponse technique et opérationnelle doit être continue et collaborative entre les fournisseurs d'outils, l'équipement de sécurité et les développeurs.

Cet épisode rappelle que le confort des écosystèmes de développement modernes - des extensions qui sont installées automatiquement, des dépendances qui sont résolues par un clic - entraîne un coût de sécurité si les garanties ne sont pas mises en œuvre. La défense contre les campagnes comme GlassWorm nécessite à la fois des meilleures pratiques individuelles et des améliorations systémiques dans la manière dont le logiciel libre et ses dépendances sont distribués et examinés.