.png)
Dix-huit minutes, 2,2 millions de cibles
Ce fut une semaine difficile pour GitHub. Hier, GitHub a confirmé avoir été victime d'une violation. Les attaquants auraient extrait des données d'environ 3 700 dépôts internes, et le point d'entrée était une extension VS Code empoisonnée exécutée sur la machine d'un employé de GitHub.
La veille, Nx Console (une extension VS Code populaire pour le système de build monorepo Nx) a révélé le mécanisme qui a rendu la compromission possible. En matière de sécurité, les extensions VS Code sont le Far West.
Ce qui s'est passé avec Nx Console
Le 18 mai, la version 18.95.0 de l'extension Nx Console (2,2 millions d'installations, badge d'éditeur vérifié) a été téléchargée sur le Visual Studio Marketplace à 12h30 UTC. Microsoft n'a pas signalé le téléchargement. Le mainteneur de Nx n'a reçu l'e-mail de notification de téléchargement du marketplace qu'à 12h36 UTC, six minutes plus tard. La version compromise a été dépubliée à 12h47 UTC et Microsoft a entièrement enregistré le retrait à 12h48 UTC. Exposition totale sur le Visual Studio Marketplace : environ dix-huit minutes.
La même version a également été diffusée sur OpenVSX. Des rapports précédents indiquaient qu'OpenVSX n'avait pas été affecté, mais l'avis mis à jour des mainteneurs indique qu'elle y a été active de 12h33 UTC à 13h09 UTC. Soit environ trente-six minutes, le double de la fenêtre du Visual Studio Marketplace.
Selon l'avis, toute personne ayant installé Nx Console avec la mise à jour automatique activée pendant ces fenêtres devrait considérer avoir été compromise, et tout ce qui se trouvait sur le disque (jetons, secrets, clés SSH, tout ce qui est lié aux identifiants) devait être renouvelé.
La cause première était un jeton GitHub d'un contributeur qui avait été récupéré lors d'une précédente attaque de la chaîne d'approvisionnement, puis utilisé pour publier la version malveillante. Le pipeline de publication a accepté le jeton volé sans vérification, ce qui était tout ce dont les attaquants avaient besoin.
La mise à jour automatique est le véritable problème
Chaque marketplace d'extensions populaire est livré avec la mise à jour automatique activée par défaut. VS Code, Cursor, toute la gamme. Le raisonnement est logique isolément, car la plupart des développeurs ne mettent jamais rien à jour manuellement, donc le désactiver signifie une longue traîne d'éditeurs exécutant du code obsolète et vulnérable.
Le compromis n'a plus de sens une fois que l'on prend en compte les éditeurs hostiles/compromis. La mise à jour automatique offre à un attaquant qui contrôle une version un canal de diffusion direct vers chaque machine exécutant cette extension. Les marketplaces n'imposent aucune étape de révision ni période d'attente entre la publication d'une mise à jour et son téléchargement par les clients installés.
La vérification elle-même n'a pas d'intervalle fixe unique. Il y a un minuteur de secours de 12 heures dans extensionsWorkbenchService.ts (1 heure sur Insiders avec une mise à jour de produit en attente), une vérification immédiate au démarrage une fois que le workbench est inactif, et plusieurs déclencheurs basés sur des événements (vérification des mises à jour de produits, modification de la politique de liste blanche, passage d'une connexion mesurée à non mesurée, activation de l'option de vérification automatique). En plus de tout cela, il existe un chemin distinct qui détecte les mises à jour comme un effet secondaire de toute autre interaction avec le marketplace. Lorsque VS Code interroge la galerie pour quelque raison que ce soit (barre latérale des extensions visible, recherche sur le marketplace, invites de recommandation, sous-systèmes d'arrière-plan qui récupèrent les métadonnées de la galerie), il synchronise le résultat avec les extensions installées et, si certaines sont désormais obsolètes, déclenche eventuallyAutoUpdateExtensions, qui s'installe via un délai limité à 1 seconde. Avec extensions.autoUpdate activé (par défaut), l'installation se fait en arrière-plan sans aucune invite.
La fenêtre de dix-huit minutes sur le Visual Studio Marketplace a détecté tout éditeur en cours d'exécution ayant interagi avec la galerie concernant l'extension Nx Console pendant ces minutes : barre latérale visible, recherche sur le marketplace, consultation de recommandations, ou tout sous-système d'arrière-plan récupérant les métadonnées de la galerie. À travers les fuseaux horaires et les heures de travail, pour une extension avec 2,2 millions d'installations et une barre latérale des extensions que de nombreux développeurs laissent ouverte, cette population est bien plus importante que ce qu'un simple minuteur périodique ne le suggérerait. Lors de nos propres tests de ces fonctionnalités, nous avons constaté que la mise à jour automatique se déclenchait quelques minutes après la publication d'une nouvelle version, ce qui correspond au chemin de synchronisation de la galerie plutôt qu'au minuteur de 12 heures. La fenêtre OpenVSX a fait de même pendant environ trente-six minutes.
La chronologie des mainteneurs révèle également le délai de détection que la mise à jour automatique engendre. Six de ces dix-huit minutes se sont écoulées avant même que le mainteneur ne voie la notification de téléchargement du marketplace. La mise à jour automatique installait la version malveillante sur les machines des utilisateurs pendant ces six minutes, avant qu'aucun humain du côté de l'éditeur n'ait pu savoir qu'il fallait agir.
Pourquoi cela continue de fonctionner
Le cas Nx n'est pas la première fois qu'un tel événement se produit avec une extension VS Code. En novembre 2025, le compromis d'AsyncAPI a été le premier événement de la vague du ver Shai-Hulud 2.0. Les attaquants avaient volé les jetons de publication npm et OpenVSX d'AsyncAPI, qui se trouvaient dans les secrets du dépôt GitHub depuis des années, et les avaient utilisés pour pousser des paquets npm AsyncAPI malveillants et une version malveillante de l'extension AsyncAPI VS Code sur OpenVSX. Au moins un développeur a signalé avoir été infecté via l'extension sur le traqueur de problèmes du projet avant que les mainteneurs ne puissent déprécier les versions affectées. Le même mécanisme était à l'œuvre : un identifiant volé, utilisé pour pousser du code malveillant vers une base d'utilisateurs à mise à jour automatique sur une courte période.
Plusieurs facteurs sont défavorables aux défenseurs ici :
- Un nombre élevé d'installations et des badges d'éditeur vérifié signalent la confiance, et c'est cette confiance que les attaquants cherchent à détourner. Les extensions populaires sont déjà installées sur des millions de machines, de sorte qu'une version compromise pousse automatiquement du code malveillant dans toutes ces installations existantes, sans nécessiter d'ingénierie sociale contre de nouveaux utilisateurs.
- Les extensions sont distribuées sous forme de JavaScript interprété plutôt que de binaires compilés. La charge utile malveillante de Nx Console était de 2 777 octets injectés dans un fichier minifié, qui a ensuite récupéré un dropper obfusqué de 498 Ko à partir d'un commit orphelin dans le dépôt officiel
nrwl/nxdépôt. L'EDR n'a aucune signature pour un diff JavaScript minifié contre une extension à laquelle les utilisateurs font déjà confiance. - Les identifiants des mainteneurs sont plus faciles à hameçonner ou à récupérer qu'ils ne devraient l'être. Le cas Nx a commencé avec un jeton provenant d'un compromis distinct, utilisé en aval contre une cible de confiance. Le cas AsyncAPI a commencé avec un jeton OpenVSX qui se trouvait dans un secret de dépôt GitHub depuis des années.
- La communauté devient rapide pour détecter cela, mais dix-huit minutes de distribution automatique suffisent à causer des dommages, et ce n'est que sur l'un des deux marketplaces hébergeant l'extension.
Une fois qu'il est sur une machine, le marketplace ne peut plus vous aider
Les marketplaces n'ont également aucun moyen de rappeler une extension une fois qu'elle a été installée. Le retrait de la liste arrête les nouvelles installations, mais toute personne ayant déjà téléchargé la version malveillante continue de l'exécuter jusqu'à ce qu'elle mette à jour vers une version propre ou la désinstalle manuellement. La mise à jour automatique finira par faire passer les utilisateurs affectés à la version corrigée une fois que le mainteneur en aura publié une, mais le marketplace n'a pas de coupe-circuit et aucun moyen de restaurer une installation plus rapidement.
L'analyse de Wiz Research sur la longue traîne de Shai-Hulud 2.0 montre cette dynamique en pratique. L'extension malveillante AsyncAPI VS Code (v1.0.1) a été retirée d'OpenVSX le 26 novembre 2025, mais le registre est revenu à la version propre précédente (v1.0.0). Les copies installées en v1.0.1 n'ont vu aucune version plus récente disponible, de sorte que la mise à jour automatique ne s'est jamais déclenchée. L'extension a continué à fonctionner sur les machines des développeurs et à exfiltrer des identifiants pendant près d'un mois, représentant plus de 90 % des infections à longue traîne de la campagne et environ 100 à 200 nouveaux dépôts compromis par jour du 25 novembre au 24 décembre. Le flux n'a cessé que lorsque AsyncAPI a publié une version propre v1.1.0 le 24 décembre (après que Wiz Research leur ait signalé le problème la veille), date à laquelle les IDEs se sont mis à jour automatiquement et les nouveaux compromis quotidiens sont tombés à une poignée en quelques jours.
Microsoft retire également les listes en silence. Aucune notification n'est envoyée aux utilisateurs qui ont installé l'extension pendant la période d'exposition. Leur éditeur n'affiche pas de message "vous avez peut-être installé une version compromise, veuillez vérifier votre machine". À moins que vous n'ayez suivi l'actualité de la sécurité le jour de l'incident, votre seul signal pourrait être que l'extension a cessé d'apparaître dans les résultats de recherche du marketplace. Le dépôt Nx Console contient déjà un problème d'un développeur demandant, de bonne foi, pourquoi l'extension avait disparu du marketplace. La plupart des utilisateurs ne songeraient pas à poser la question.
L'effet combiné est que la seule réponse efficace du marketplace est d'empêcher les nouvelles installations d'une version connue comme étant malveillante. Pour les développeurs qui ont déjà téléchargé la version malveillante pendant la période, le nettoyage leur incombe entièrement et dépend de leur capacité à être informés de l'incident par un autre canal que le marketplace lui-même.
Que faire concrètement
Si vous aviez Nx Console installé avec la mise à jour automatique pendant ces périodes le 18 mai, les recommandations de l'avis de sécurité sont le bon point de départ : faire pivoter les jetons, les secrets, les clés SSH et tout autre élément accessible depuis la machine affectée. Quiconque a exécuté la version OpenVSX est concerné par la fenêtre plus longue de trente-six minutes plutôt que par celle du Visual Studio Marketplace.
Pour la problématique plus large, l'intervention simple consiste à introduire un délai entre la publication d'une version et le moment où son installation est autorisée. La solution Aikido Protection des appareils intègre par défaut une période de rétention de 48 heures sur les nouvelles versions de packages et d'extensions, ce qui aurait permis de détecter Nx Console (et la récente tâche récurrente compromission de PyPI) sans que personne n'ait eu à l'identifier comme malveillant au préalable. En tant qu'individu sans solution tierce, le plus proche que vous puissiez faire est de désactiver les mises à jour automatiques des extensions dans VS Code et de mettre à jour selon un calendrier délibéré. C'est plus lent, et vous aurez un jour ou deux de retard sur les versions légitimes. C'est le prix à payer pour ne pas exécuter le code fraîchement publié par d'autres sur votre ordinateur portable dès sa publication.
VS Code prend déjà en charge la surface de politique sous-jacente pour en faire un paramètre au niveau de l'organisation. Le extensions.allowed La politique d'entreprise permet aux administrateurs de restreindre les éditeurs, les extensions et même les versions spécifiques pouvant être installés sur les appareils gérés. Une option de délai de temporisation en plus (quelque chose comme "n'installer automatiquement que les versions de plus de N heures") s'intégrerait dans le même paramètre. Il n'y a aucune bonne raison technique pour qu'elle n'existe pas déjà, et étant donné la fréquence de ces incidents sur le marketplace qu'il intègre, elle devrait exister. Il en va de même pour Cursor et tout autre éditeur basé sur VS Code : si vous autorisez déjà les organisations à appliquer une liste blanche, laissez-les également appliquer un délai de temporisation.
L'affaire GitHub fera la une pendant des semaines parce que la victime est célèbre, et le même mécanisme sous-jacent continuera de produire des brèches. Tant que les marketplaces pousseront automatiquement les mises à jour depuis des comptes qui peuvent être compromis d'une douzaine de manières ordinaires, chaque extension populaire est à un jeton volé de se transformer en ver.
Aikido Device Protection
Si vous souhaitez un délai de temporisation dès aujourd'hui sans attendre que VS Code ou Cursor en intègre un nativement, nous vous recommandons Aikido Device Protection. Il applique une politique d'âge minimum configurable (48 heures par défaut) aux installations de packages et d'extensions au niveau de l'appareil, de sorte que la même politique couvre tout éditeur basé sur VS Code utilisé par vos développeurs.
