vm2 : 12 CVE critiques, le bac à sable Node.js explose

Ce qui s'est passé

Le 7 mai 2026, la communauté sécurité Node.js a découvert un mur d'avis CVE concernant vm2, la librairie de bac à sable JavaScript la plus utilisée de l'écosystème. En une seule journée, douze vulnérabilités d'évasion de sandbox ont été publiées, dont trois notées 10.0 sur l'échelle CVSS, le score maximum. Toutes partagent le même résultat final : un attaquant capable d'injecter du code dans le sandbox vm2 peut s'en extraire et exécuter du JavaScript arbitraire dans le contexte du processus Node.js hôte, avec les mêmes privilèges que l'application.

vm2 n'est pas une librairie obscure. Téléchargée plus de seize millions de fois par semaine sur npm, elle sert de fondation à des dizaines de produits qui acceptent du code JavaScript fourni par des utilisateurs : IDE en ligne, plateformes no-code et low-code, moteurs de règles métier, environnements d'évaluation pédagogiques, fonctions serverless permettant le code dynamique, outils RPA, plateformes de tests automatisés. Ces produits ont besoin d'exécuter du code non fiable de manière contrôlée, et vm2 promet précisément cela : empêcher le code invité de toucher au système de fichiers, au réseau, aux modules natifs ou à l'interpréteur lui-même.

Le bouquet du 7 mai pulvérise cette promesse douze fois de suite. CVE-2026-43997, CVE-2026-44005 et CVE-2026-44006, toutes notées 10.0, exploitent respectivement l'injection d'objets hôtes via les références natives, la pollution de prototype à travers la gamme 3.9.6 à 3.10.5, et un détournement de BaseHandler.getPrototypeOf qui contourne le proxy de protection. CVE-2026-26332 abuse de la classe SuppressedError introduite dans ECMAScript récent pour faire fuir des références hôtes dans le contexte invité. CVE-2026-26956 utilise une coercition Symbol-vers-string pour déclencher une TypeError côté hôte dont l'objet erreur retourne dans le sandbox sans assainissement, exposant directement le contexte global de Node.

Plusieurs des contournements reposent sur des fonctionnalités JavaScript modernes que vm2 n'avait pas anticipées correctement. CVE-2026-24118 abuse de __lookupGetter__, méthode héritée mais toujours présente sur tous les objets standard. CVE-2026-24120 manipule Promise[Symbol.species] pour modifier la classe instanciée lors d'un then chaîné. CVE-2026-44008 contourne la défense neutralizeArraySpeciesBatch ajoutée dans une précédente itération de durcissement. La leçon technique : maintenir un sandbox JavaScript exclusivement en JavaScript devient impossible à mesure que le langage gagne des primitives de réflexion.

La situation est aggravée par un fait communautaire : le mainteneur de vm2, Patrik Simek, a publiquement déprécié le projet le 2 mai 2023, après une vulnérabilité similaire (CVE-2023-30547). Sa conclusion à l'époque : « le modèle de sécurité de vm2 est définitivement cassé, le code ne peut pas être patché de manière sûre ». Depuis, le projet est officiellement marqué comme abandonné sur GitHub et npm. Pourtant, en 2026, vm2 reste citée dans plus de vingt mille dépendances directes, signe que le message de dépréciation ne suffit pas à déloger une librairie aussi profondément ancrée. Les patches 3.11.0, 3.11.1 et 3.11.2 publiés cette semaine sont décrits par leur auteur comme « des mesures d'urgence pour les utilisateurs qui ne peuvent pas migrer immédiatement ».

Côté exploitation, BleepingComputer rapporte qu'aucune campagne active n'a encore été observée dans la nature sur ces CVE spécifiques, mais les chercheurs de Semgrep et d'Endor Labs qui ont participé à la divulgation jugent que des preuves de concept publiques apparaîtront dans les heures qui suivent. CVE-2023-37466 et CVE-2023-30547, publiées dans des conditions similaires en 2023, étaient exploitées en moins de quarante-huit heures après publication. Sur les forums spécialisés, plusieurs équipes red team confirment déjà avoir intégré certains des PoC dans leurs kits internes.

Les recommandations officielles, partagées par GitHub Security Advisories et le CERT-FR, sont triples. Mettre à jour vers vm2 3.11.2 immédiatement pour les services qui ne peuvent pas migrer dans la journée. Planifier une migration vers isolated-vm, qui utilise un véritable isolat V8 plutôt qu'un sandbox JavaScript, ou vers le nouveau Permission Model de Node.js 22 LTS qui offre un confinement au niveau du noyau du runtime. Auditer les chaînes de dépendances avec npm ls vm2 ou npm audit pour identifier les usages indirects, souvent invisibles dans les inventaires de production.

D'après The Hacker News, les premières plateformes à publier des avis de mitigation sont CodeSandbox, StackBlitz et plusieurs fournisseurs de fonctions serverless tiers. Les éditeurs RPA UiPath et Automation Anywhere n'ont pas encore communiqué. Les équipes DevSecOps françaises interrogées par LeMagIT signalent que la chasse aux dépendances indirectes monopolise leurs astreintes depuis le bulletin du CERT-FR publié dans la matinée du 8 mai.

Pourquoi c'est important

Le scénario vm2 incarne le pire cauchemar du DevSecOps moderne : une librairie largement déployée, officiellement abandonnée par son mainteneur depuis trois ans, mais qui continue de tourner en production parce que sa migration coûte cher et que sa surface fonctionnelle est unique dans l'écosystème npm. Les douze CVE de cette semaine confirment un constat que les chercheurs en sécurité martèlent depuis 2023 : un sandbox JavaScript écrit en JavaScript est ontologiquement vulnérable. Chaque nouvelle primitive du langage, chaque nouveau type d'objet introduit par TC39, ouvre potentiellement une fuite de référence vers le contexte hôte que le sandbox ne peut pas anticiper.

L'impact métier est considérable et inégalement réparti. Les plateformes SaaS qui exposent des moteurs de règles JavaScript à leurs clients, comme certains outils CRM ou ERP, font face à un risque de compromission multi-tenant : un client malveillant peut potentiellement accéder aux données d'autres clients hébergés sur la même instance. Les fonctions serverless qui acceptent du code dynamique deviennent un vecteur d'escalade vers l'infrastructure du fournisseur. Les outils éducatifs qui exécutent les soumissions des étudiants risquent l'exfiltration de bases de données pédagogiques, parfois rattachées à des données nominatives soumises au RGPD.

Le précédent de 2023 est instructif. Lorsque CVE-2023-37466 avait été publiée, l'entreprise Tabby (extension VS Code de complétion de code) avait été obligée de basculer en urgence vers isolated-vm en quarante-huit heures, retardant deux releases majeures. Replit avait, de son côté, désactivé temporairement plusieurs fonctionnalités d'exécution. En 2026, l'écosystème a appris : les acteurs sérieux ont déjà migré, mais la longue traîne — petits SaaS, projets internes d'entreprise, sous-dépendances — reste massivement exposée. C'est cette longue traîne que les attaquants vont cibler.

Sur le plan réglementaire, les organisations soumises à NIS2 doivent considérer cet épisode comme un événement de sécurité significatif au sens de l'article 23. Une exploitation réussie pourrait déclencher l'obligation de notification à l'ANSSI dans les vingt-quatre heures, surtout pour les opérateurs de services essentiels qui exposent des fonctions de scripting à leurs utilisateurs. Au niveau Cyber Resilience Act, dont les obligations entrent progressivement en vigueur, le maintien en production d'une dépendance publiquement dépréciée peut être qualifié de manquement à l'obligation de diligence du fabricant, particulièrement quand il s'agit d'une librairie centrale au modèle de menace.

Enfin, l'affaire vm2 reflète un débat structurel : faut-il continuer à entretenir des projets open source critiques abandonnés via des fonds de soutien type Open Source Security Foundation, ou accepter la dépréciation et forcer la migration ? La Linux Foundation, sollicitée en 2024, avait refusé de prendre vm2 sous son aile, jugeant le modèle architectural intrinsèquement non maintenable. Cette position se vérifie aujourd'hui : douze CVE en une semaine ne sont pas une coïncidence, c'est un échec de conception. Les architectes logiciel doivent en tirer la leçon : pour exécuter du code non fiable, isoler au niveau du processus, du conteneur ou du noyau, jamais au niveau du runtime applicatif seul.

Ce qu'il faut retenir

• vm2 reçoit douze CVE critiques le 7 mai 2026, dont trois notées 10.0 sur 10 ; toutes permettent l'évasion du sandbox et l'exécution de code arbitraire.
• La librairie est officiellement dépréciée depuis 2023 mais reste utilisée dans plus de 20 000 dépendances ; le patch 3.11.2 corrige toute la série, mais la migration vers isolated-vm est la seule réponse durable.
• Les plateformes SaaS multi-tenant, fonctions serverless dynamiques et outils éducatifs sont en première ligne ; les organisations NIS2 doivent intégrer cet incident dans leur évaluation de risque chaîne d'approvisionnement logicielle.