.png)
Dix-huit minutes, 2,2 millions de cibles
La semaine a été difficile pour GitHub. Hier, GitHub a confirmé avoir été victime d'une intrusion. Les pirates auraient extrait des données d'environ 3 700 dépôts internes, et le point d'entrée aurait été une extension VS Code malveillante exécutée sur l'ordinateur d'un employé de GitHub.
La veille, Nx Console (une extension VS Code très populaire pour le système de compilation monorepo Nx) avait révélé le mécanisme qui avait rendu cette faille possible. En matière de sécurité, les extensions VS Code, c'est le Far West.
Que s'est-il 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é mise en ligne sur le Visual Studio Marketplace à 12 h 30 UTC. Microsoft n'a pas signalé cette mise en ligne. Le responsable de Nx n'a reçu l'e-mail de notification de mise en ligne du Marketplace qu'à 12 h 36 UTC, soit six minutes plus tard. La version compromise a été retirée à 12 h 47 UTC et Microsoft a officiellement enregistré le retrait à 12 h 48 UTC. Durée totale d'exposition sur le Visual Studio Marketplace : environ dix-huit minutes.
La même version a également été publiée sur OpenVSX. Selon des informations précédentes, OpenVSX n'était pas concerné, mais l'avis mis à jour par les responsables indique qu'elle y a été disponible de 12 h 33 UTC à 13 h 09 UTC. Cela représente environ trente-six minutes, soit deux fois la durée de la fenêtre sur le Visual Studio Marketplace.
Selon l'avis de sécurité, toute personne ayant installé Nx Console avec la mise à jour automatique activée pendant ces périodes doit considérer que son système a été compromis, et tout ce qui se trouve sur le disque (jetons, secrets, clés SSH, tout élément lié aux identifiants) doit être renouvelé.
La cause première résidait dans le 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é ce jeton volé sans le remettre en question, ce qui a suffi aux attaquants.
Le problème, c'est justement la mise à jour automatique
Toutes les plateformes d'extensions populaires sont configurées par défaut pour effectuer des mises à jour automatiques. VS Code, Cursor, toute la gamme. Cette logique est tout à fait valable en soi, car la plupart des développeurs ne mettent jamais rien à jour manuellement ; ne pas activer cette fonctionnalité reviendrait donc à laisser une multitude d'éditeurs fonctionner avec un code obsolète et vulnérable.
Ce compromis perd tout son sens dès lors que l'on tient compte des éditeurs malveillants ou compromis. La mise à jour automatique offre à un pirate informatique qui contrôle une version un canal de diffusion direct vers chaque machine exécutant cette extension. Les boutiques en ligne n'imposent aucun contrôle préalable ni aucune période d'attente entre la publication d'une mise à jour et le moment où les clients qui l'ont installée la téléchargent.
La vérification en elle-même ne suit pas un intervalle fixe. Il y a un Minuterie de secours de 12 heures dans extensionsWorkbenchService.ts (Une heure dans « Insiders » avec une mise à jour du produit en cours), une vérification immédiate au démarrage une fois que l'atelier est inactif, et plusieurs déclencheurs basés sur des événements (vérification des mises à jour des produits, modification de la politique de liste blanche, passage d'une connexion avec forfait à une connexion illimité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 en tant qu'effet secondaire de toute autre interaction avec la boutique. Lorsque VS Code interroge la galerie pour quelque raison que ce soit (barre latérale des extensions visible, recherche dans la boutique, suggestions de recommandations, sous-systèmes en 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, incendies Mise à jour automatique des extensions, qui s'installe via un délai limité à 1 seconde. Avec extensions.autoUpdate (par défaut), l'installation s'effectue en arrière-plan sans demande de confirmation.
La fenêtre de dix-huit minutes sur le Visual Studio Marketplace a permis de détecter tout éditeur en cours d'exécution ayant interagi avec la galerie en accédant à la fiche de Nx Console pendant ces minutes : barre latérale visible, recherche sur le Marketplace, consultation des recommandations ou tout sous-système d'arrière-plan récupérant les métadonnées de la galerie. Compte tenu des différents fuseaux horaires et horaires de travail, sur une extension comptant 2,2 millions d'installations et dont la barre latérale « Extensions » reste ouverte chez de nombreux développeurs, cette population est bien plus importante que ne le laisserait supposer un simple minuteur périodique. Lors de nos propres tests de ces fonctionnalités, nous avons constaté que la mise à jour automatique se déclenchait dans les minutes suivant 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.
Le chronologie des responsables de maintenance met également en évidence 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 responsable de maintenance ne prenne connaissance de la notification de mise en ligne sur la boutique d'applications. Pendant ces six minutes, la mise à jour automatique a téléchargé la version malveillante sur les ordinateurs des utilisateurs, avant même qu'un membre du personnel de l'éditeur n'ait pu être mis au courant et intervenir.
Pourquoi cela continue de fonctionner
L'affaire Nx n'est pas la première fois qu'un tel incident touche une extension de VS Code. En novembre 2025, la compromission d'AsyncAPI avait marqué le coup d'envoi de la vague de vers 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 déployer des paquets npm AsyncAPI malveillants ainsi qu'une version malveillante de l'extension VS Code d'AsyncAPI sur OpenVSX. Au moins un développeur a signalé avoir été infecté via l'extension sur le système de suivi des problèmes du projet avant que les responsables de maintenance ne puissent déprécier les versions concernées. Le même mécanisme était à l'œuvre : des identifiants volés, utilisés pour diffuser du code malveillant à une base d'utilisateurs bénéficiant de la mise à jour automatique pendant une courte période.
Plusieurs facteurs jouent en défaveur des défenseurs dans ce cas :
- Un nombre élevé d'installations et les badges d'éditeur certifié sont des gages de confiance, et c'est précisément cette confiance que les pirates cherchent à détourner. Les extensions populaires sont déjà présentes sur des millions d'ordinateurs ; ainsi, une version compromise permet d'injecter automatiquement du code malveillant dans toutes ces installations existantes, sans qu'il soit nécessaire de recourir à des techniques d'ingénierie sociale auprès de nouveaux utilisateurs.
- Les extensions sont fournies sous forme de code JavaScript interprété plutôt que de binaires compilés. La charge utile malveillante de Nx Console, d'une taille de 2 777 octets, a été injectée 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/nxréférentiel. EDR ne dispose d'aucune signature pour un diff JavaScript minifié par rapport à une extension à laquelle les utilisateurs font déjà confiance. - Les identifiants des administrateurs sont plus faciles à pirater ou à récupérer par hameçonnage qu'ils ne devraient l'être. L'affaire Nx a débuté avec un jeton issu d'une autre intrusion, qui a ensuite été utilisé contre une cible de confiance. L'affaire AsyncAPI a quant à elle commencé avec un jeton OpenVSX qui se trouvait depuis des années dans un secret de dépôt GitHub.
- La communauté réagit de plus en plus vite, mais dix-huit minutes de diffusion automatique suffisent pour causer des dégâts, et ce n'est que sur l'une des deux boutiques en ligne hébergeant l'extension.
Une fois qu'il est installé sur un appareil, la boutique d'applications ne peut plus vous aider
Les boutiques d'applications n'ont par ailleurs aucun moyen de retirer une extension une fois qu'elle a été installée. Le retrait de la fiche produit empêche toute nouvelle installation, mais toute personne ayant déjà téléchargé la version malveillante continuera à l'utiliser jusqu'à ce qu'elle passe à une version corrigée ou la désinstalle manuellement. La mise à jour automatique finira par faire passer les utilisateurs concernés à la version corrigée dès que le responsable de la maintenance en aura publié une, mais la boutique d'applications ne dispose d'aucun « kill switch » ni d'aucun moyen de revenir en arrière plus rapidement.
L'analyseWiz sur la « longue traîne » de Shai-Hulud 2.0 illustre cette dynamique dans la pratique. L'extension malveillante AsyncAPI pour VS Code (v1.0.1) a été retirée d'OpenVSX le 26 novembre 2025, mais le registre est revenu à la version précédente non compromise (v1.0.0). Les copies installées de la v1.0.1 n'ont pas détecté de 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 de longue durée issues de la campagne et environ 100 à 200 nouveaux dépôts compromis par jour entre le 25 novembre et le 24 décembre. Le flux ne s'est arrêté que lorsque AsyncAPI a publié une version v1.1.0 propre le 24 décembre (après que Wiz leur ait signalé le problème la veille), moment auquel les IDE se sont mis à jour automatiquement et où le nombre de nouvelles compromissions quotidiennes est tombé à une poignée en quelques jours.
Microsoft retire également les extensions en toute discrétion. Aucune notification n'est envoyée aux utilisateurs qui les ont installées pendant la période d'exposition. L'éditeur ne fait pas apparaître de message du type « Vous avez peut-être installé une version compromise, veuillez vérifier votre ordinateur ». À moins d'avoir suivi l'actualité de la sécurité le jour de l'incident, le seul indice pourrait être que l'extension ne s'affiche plus dans les résultats de recherche du Marketplace. Le dépôt Nx Console contient déjà une demande d'un développeur qui demande, de bonne foi, pourquoi l'extension a disparu de la boutique. La plupart des utilisateurs ne penseraient pas à poser la question.
En conséquence, la seule mesure efficace que peut prendre la boutique en ligne consiste à empêcher l'installation de nouvelles versions connues pour être défectueuses. Pour les développeurs qui ont déjà téléchargé la version malveillante pendant cette période, la responsabilité du nettoyage leur incombe entièrement, et ils doivent pour cela prendre connaissance de l'incident par un autre canal que la boutique en ligne elle-même.
Que faire concrètement ?
Si vous aviez installé Nx Console avec la mise à jour automatique pendant ces fenêtres le 18 mai, les recommandations de l'avis de sécurité constituent le bon point de départ : renouvelez les jetons, les secrets, les clés SSH et tout autre élément accessible depuis la machine concernée. Toute personne ayant exécuté la version OpenVSX est concernée par la fenêtre plus longue de trente-six minutes, et non par celle du Visual Studio Marketplace.
D'une manière générale, la solution la plus simple consiste à introduire un délai entre la publication d'une version et le moment où son installation est autorisée. Aikido Protection des appareils est livré avec une période d'attente par défaut de 48 heures pour les nouvelles versions des paquets et des 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 besoin de la signaler comme malveillante au préalable. En tant que particulier ne disposant pas d'une solution fournie par un éditeur, le mieux que vous puissiez faire est Désactiver les mises à jour automatiques des extensions dans VS Code et optez plutôt pour une mise à jour selon un calendrier défini. C'est plus lent, et vous aurez un ou deux jours de retard sur les versions officielles. C'est le prix à payer pour ne pas exécuter sur votre ordinateur portable le code que d'autres viennent de publier dès sa mise en ligne.
VS Code prend déjà en charge l'infrastructure de gestion des politiques nécessaire pour que cela devienne une paramètre au niveau de l'organisation. Le extensions autorisées La politique d'entreprise permet aux administrateurs de limiter les éditeurs, les extensions et même les versions spécifiques pouvant être installées sur les appareils gérés. Une option de délai d'attente en plus de cela (du type « n'installer automatiquement que les versions datant de plus de N heures ») s'intégrerait parfaitement dans ce même paramètre. Il n'y a aucune raison technique valable pour que cela n'existe pas déjà, et compte tenu de la fréquence à laquelle ces incidents se produisent sur la boutique d'applications fournie avec le logiciel, cela devrait être le cas. Il en va de même pour Cursor et tout autre éditeur basé sur VS Code : si vous permettez déjà aux organisations d'appliquer une liste blanche, permettez-leur également d'appliquer un délai d'attente.
L'affaire GitHub va faire parler d'elle pendant des semaines, car la victime est célèbre, et le même mécanisme sous-jacent continuera à générer des failles de sécurité. Tant que les boutiques en ligne publieront automatiquement les mises à jour provenant de comptes susceptibles d'être piratés de multiples façons, chaque extension populaire n'est qu'à un jeton volé de se transformer en ver informatique.
Protection Aikido
Si vous souhaitez mettre en place un délai d'attente dès aujourd'hui sans attendre que VS Code ou Cursor en intègrent un nativement, nous vous recommandons Aikido Protection. Cette solution applique une politique de délai d'attente minimum configurable (48 heures par défaut) pour l'installation de paquets et d'extensions au niveau de l'appareil ; ainsi, cette même politique s'applique à tous les éditeurs basés sur VS Code utilisés par vos développeurs.
