CVE-2026-43997 : vm2 sandbox escape RCE (CVSS 10.0)

Les faits

Une équipe de chercheurs en sécurité a divulgué le 6 mai 2026 un ensemble de douze vulnérabilités critiques dans vm2, une bibliothèque Node.js largement utilisée pour exécuter du code JavaScript non fiable dans un environnement isolé. Trois d''entre elles — CVE-2026-43997, CVE-2026-44005 et CVE-2026-44006 — atteignent le score CVSS maximal de 10.0, ce qui en fait des vulnérabilités au plus haut niveau de criticité possible. Toutes permettent à du code JavaScript exécuté à l''intérieur du sandbox vm2 de s''échapper de l''isolement et d''exécuter du code arbitraire avec les privilèges du processus Node.js hôte.

Selon The Hacker News, BleepingComputer et CSO Online, les vulnérabilités exploitent toutes une faiblesse de conception fondamentale du mécanisme interne de bridge de vm2, qui gère le passage de références d''objets entre les contextes JavaScript du sandbox et de l''hôte. Les techniques de bypass incluent la manipulation de primitives JavaScript internes : __lookupGetter__, Buffer.apply, util.inspect, Promise species, SuppressedError, ainsi que l''instruction try_table de WebAssembly. La diversité des vecteurs démontre que l''isolation par instrumentation JavaScript pure, telle qu''implémentée par vm2, ne peut pas être considérée comme une frontière de sécurité fiable face à un attaquant déterminé.

Parmi les CVE notables : CVE-2026-43997 (CVSS 10.0) est une injection de code permettant d''obtenir l''objet host Object et d''échapper au sandbox via util.inspect et la traversée de prototype, affectant les versions ≤ 3.10.5 et corrigée en 3.11.0 ; CVE-2026-44005 (CVSS 10.0) permet à du JavaScript contrôlé par l''attaquant d''échapper au sandbox et d''effectuer une prototype pollution, affectant les versions 3.9.6 à 3.10.5 ; CVE-2026-44006 (CVSS 10.0) abuse également de util.inspect et de la traversée de prototype ; CVE-2026-43999 atteint 9.9 ; CVE-2026-24781 (9.8) exploite la fonction inspect pour s''échapper du sandbox et exécuter du code arbitraire sur l''hôte ; CVE-2026-44009 (9.8) exploite une exception de null proto.

De manière particulièrement préoccupante, CVE-2026-44008 et CVE-2026-44009 demeurent non corrigées dans la version 3.11.1, la plus récente avant la divulgation. Ces deux failles abusent du traitement des array species et de la logique des exceptions pour exposer des objets côté hôte et regagner un accès non restreint au constructeur Function de l''hôte. Endor Labs et Semgrep, qui ont participé à l''analyse, recommandent dès lors aux opérateurs de cesser de considérer vm2 comme une isolation de sécurité, et de migrer dès que possible vers des alternatives offrant une vraie isolation au niveau du processus ou du système.

La version 3.11.2 publiée par les mainteneurs corrige une partie des vulnérabilités mais pas toutes. Cette mise à jour reste recommandée comme mesure de réduction de risque immédiate, mais ne constitue pas une solution complète. Les alternatives suggérées incluent isolated-vm (qui s''appuie sur les Isolates de V8 pour une isolation au niveau du moteur), l''exécution dans un processus enfant Node.js avec un cgroup ou seccomp, l''utilisation de runtimes WebAssembly comme Wasmtime ou Wasmer, ou pour les cas critiques, le déport vers des sandboxes système (Firecracker microVMs, gVisor, conteneurs durcis).

vm2 est utilisée par un grand nombre de produits et services qui acceptent et exécutent du code JavaScript fourni par des utilisateurs : plateformes low-code/no-code, moteurs de règles métier, intégrations type Zapier ou Make, serveurs d''automatisation, plateformes de notebook, services SaaS exposant des fonctions personnalisables. Dans ces contextes, un attaquant qui peut soumettre du code arbitraire — même s''il s''agit d''un utilisateur authentifié sur un compte limité — peut désormais s''échapper du sandbox et exécuter du code sur le serveur hôte.

L''historique de vm2 est marqué par une succession de sandbox escapes, dont CVE-2023-29017 et CVE-2023-37466 en 2023, CVE-2024-22709 et plusieurs autres en 2024-2025, et désormais cette série de douze vulnérabilités en mai 2026. Cette répétition reflète un constat technique : le modèle d''isolation de vm2, basé exclusivement sur de l''instrumentation JavaScript, ne peut pas refermer toutes les voies de contournement offertes par la richesse du langage et de ses bibliothèques internes. À chaque correction d''un bypass, un nouveau apparaît, ce qui pousse Endor Labs à parler d''insuffisance fondamentale du modèle.

Aucune exploitation in-the-wild n''a été confirmée publiquement à la date du 7 mai 2026, mais plusieurs PoC ont été publiés simultanément à la divulgation par les chercheurs, ce qui réduit drastiquement le délai entre la connaissance de la vulnérabilité et l''émergence d''attaques opportunistes. Les organisations exposant un service où des utilisateurs peuvent soumettre du code JavaScript exécuté via vm2 doivent considérer l''exploitation comme imminente et appliquer des mitigations dans les heures qui suivent, pas dans les semaines.

Impact et exposition

Les organisations directement exposées sont celles qui exécutent du code JavaScript fourni par des utilisateurs dans un sandbox vm2 : plateformes SaaS d''automatisation et de workflow, moteurs de règles, plateformes éducatives proposant des éditeurs de code, services de prévisualisation ou de transformation de contenu, environnements de développement collaboratifs, certains plugins de CMS et systèmes de templating avancés. Les conséquences d''une exploitation incluent la prise de contrôle complète du processus Node.js hôte, l''accès à toutes les variables d''environnement et secrets en mémoire, l''accès aux bases de données et services internes accessibles depuis le serveur, et potentiellement le pivot vers d''autres systèmes du réseau interne.

Le fait que deux vulnérabilités (CVE-2026-44008 et CVE-2026-44009) restent non corrigées en 3.11.1 et que la 3.11.2 ne couvre pas l''ensemble des bypass connus signifie qu''une simple mise à jour ne ramène pas le risque à zéro. Les organisations doivent accepter que vm2 ne fournit plus une frontière de sécurité, et adapter leur architecture en conséquence : restreindre les fonctionnalités JavaScript accessibles, ajouter des couches d''isolation système (conteneurs, microVMs), ou migrer vers des solutions d''isolation plus robustes.

L''écosystème npm et le code Node.js d''entreprise reposent significativement sur vm2 dans des composants intermédiaires, parfois sans que les développeurs en soient pleinement conscients. Une revue des dépendances transitives via npm ls vm2 ou des outils de software composition analysis (SCA) est nécessaire pour identifier toutes les surfaces d''exposition.

Pour les fournisseurs SaaS, la divulgation pose également un problème de communication client : les architectures multi-tenants où un client peut soumettre des règles JavaScript pourraient permettre à un client malveillant de compromettre l''instance partagée et donc d''accéder aux données d''autres clients. Une analyse forensique rétroactive est recommandée, en plus du patch et de la migration.

Recommandations immédiates

• Mettre à jour vm2 vers la version 3.11.2 dès que possible, conscients que cette version ne corrige pas l''ensemble des sandbox escapes connus (CVE-2026-44008 et CVE-2026-44009 demeurent non patchées).
• Inventorier les usages de vm2 dans le parc applicatif via npm ls vm2, yarn why vm2 ou un scanner SCA (Snyk, Dependabot, OWASP Dependency-Check) pour identifier tous les composants concernés, y compris en dépendance transitive.
• Planifier une migration vers une isolation plus robuste : isolated-vm (V8 Isolates), processus Node.js enfant avec restrictions seccomp/cgroup, runtimes WebAssembly (Wasmtime, Wasmer), ou Firecracker/gVisor pour les cas les plus sensibles.
• Restreindre temporairement les API JavaScript accessibles depuis le sandbox : désactiver l''accès à require, à Buffer, aux promesses spécifiques, et limiter l''utilisation de util.inspect — sans considérer ces restrictions comme suffisantes face à un attaquant déterminé.
• Surveiller les exécutions suspectes : processus enfants inattendus du processus Node.js, accès au système de fichiers ou au réseau depuis un thread de sandbox, et auditer les logs d''application pour repérer d''éventuelles tentatives d''exploitation depuis la divulgation publique.