Isoler JavaScript non fiable dans le même processus Node.js est, fondamentalement, une approche fragile.
Imaginez une bibliothèque conçue pour isoler du code malveillant. Imaginez maintenant qu’elle devienne la porte d’entrée pour l’attaquant. C’était exactement ce que des chercheurs de SOC Radar viennent de révéler au sujet du vm2. Il s’agit de l’une des bibliothèques les plus utilisées de npm.
La vulnérabilité a été enregistrée sous CVE-2026-26956. Elle a reçu une note de 9,8 sur 10 dans le système CVSS. De plus, une preuve de concept publique circule déjà sur Internet.
En d’autres termes, d’abord: le problème est grave. Ensuite: l’exploit est réel. Surtout: il affecte ceux qui ont exécuté npm update récemment vers la version la plus récente du runtime.
En quoi cette CVE diffère-t-elle des précédentes du vm2 (Node.js)
Avant tout, il faut comprendre le contexte. vm2 a toujours été une bibliothèque controversée dans l’écosystème Node.js. D’une part, elle résout un problème légitime : exécuter du JavaScript non fiable dans des environnements isolés. Ce sont les fameuses sandboxes.
D’autre part, son historique de vulnérabilités est vaste. Tellement vaste que de nombreux développeurs ont déjà migré vers des alternatives comme isolated-vm.
Cependant, la version 3.10.4 est encore largement utilisée. On la retrouve sur des plateformes d’automatisation, des systèmes CI/CD et des outils de plugins. Elle est aussi courante dans tout service qui doit exécuter des scripts tiers. Par conséquent, l’impact potentiel est immense.
La nouveauté ici réside dans le vecteur d’attaque. Les failles antérieures exploitaient des proxies ou des prototypes de JavaScript. Cette fois, cependant, le problème provient d’une source inattendue : le WebAssembly.
Comment le WebAssembly est devenu la clé pour s’échapper du sandbox
La version 25 de Node.js a élargi le support pour des fonctionnalités avancées de WebAssembly. Parmi elles figurent la gestion des exceptions et l’API WebAssembly.JSTag. Théoriquement, cela est excellent pour les applications à haute performance. En pratique, toutefois, cela a ouvert une faille que vm2 n’a jamais été conçu pour combler.
Le mécanisme de protection de vm2 fonctionne comme suit. Chaque fois qu’une exception survient dans le sandbox, la bibliothèque intercepte l’erreur et la traite en interne. De cette manière, elle empêche que des objets de l’environnement extérieur ne fuient vers le code isolé. En temps normal, ce filtrage fonctionne correctement.
Cependant, avec la gestion des exceptions WebAssembly, le scénario change. Un attaquant peut capturer une erreur JavaScript avant que vm2 ne la traite. Puis, en utilisant WebAssembly.JSTag, le code malveillant manipule cette erreur. Il suit ensuite une chaîne d’appels internes et atteint finalement l’objet process de l’hôte.
À partir de ce moment-là, c’était pratiquement plié.
De l’évasion du sandbox au contrôle total du serveur
Une fois sorti de l’environnement isolé, l’attaquant dispose de l’ensemble de l’écosystème Node.js à sa disposition. Le chemin le plus courant, bien sûr, est de charger le module child_process. Avec lui, exécuter des commandes système devient trivial. En quelques lignes, l’intrus peut opérer comme s’il était sur le terminal du serveur.
À partir de là, les possibilités sont inquiétantes :
- Lecture de fichiers sensibles sur le système de fichiers
- Accès à des variables d’environnement contenant des identifiants et des jetons
- Movement latéral sur le réseau interne de l’infrastructure
- Compromission d’autres services qui font confiance à l’hôte vulnérable
- Installation de backdoors persistantes, selon les permissions
En résumé : c’est le pire scénario d’exécution de code à distance en production.
Qui doit s’inquiéter désormais pour Node.js
La combinaison exacte qui rend l’exploitation viable est assez spécifique. Il s’agit de la vm2 version 3.10.4 fonctionnant sous Node.js v25.6.1 sur Linux x64. Les chercheurs ont confirmé la preuve de concept dans cet environnement.
Cependant, il est raisonnable de supposer que d’autres builds de Node.js 25 soient également affectés. Cela vaut tant qu’ils prennent en charge activement la gestion des exceptions WebAssembly.
En revanche, ceux qui utilisent encore des versions plus anciennes de Node.js ne sont probablement pas exposés. Cela inclut les environnements 20 LTS ou 22. Cependant, attention : cela ne signifie pas que vm2 soit sûr dans ces versions. Bien au contraire. Cette bibliothèque accumule tant de vulnérabilités historiques qu’elle devrait être abandonnée.
Ce qu’il faut faire aujourd’hui pour limiter le risque
Tout d’abord, réalisez un inventaire rapide. Exécutez à la racine de votre projet :
npm ls vm2Si vm2 apparaît parmi les dépendances et que votre environnement tourne sous Node.js 25, considérez cela comme une urgence. Ensuite, quelques actions pratiques :
- Effectuez temporairement un retour à Node.js 22 LTS pendant que vous évaluez la migration
- Désactivez le support à la gestion des exceptions WebAssembly via un flag, si possible
- Passez à
isolated-vm, qui utilise un isolement réel via les isolats V8 - Évaluez des alternatives comme Cloudflare Workers pour l’exécution de code non fiable
De plus, surveillez les journaux. Recherchez des appels suspects à child_process. Surtout ceux émanant de contextes qui devraient être sandboxés. Si vous en trouvez, supposez une compromission. Puis, suivez votre plan de réponse à incident.
La leçon que le vm2 continue de nous enseigner
Pour finir, une réflexion plus profonde. vm2 est apparu comme une solution à un problème légitime. Cependant, son architecture dépend toujours de garder le sandbox un pas en avance. Cela vaut autant pour les nouveautés de JavaScript que pour Node.js. À chaque nouvelle fonctionnalité du runtime, une nouvelle surface d’attaque apparaît. En conséquence, le cycle de découverte des failles semble sans fin.
Par conséquent, si vous utilisez encore vm2 en production, il est peut-être temps d’affronter une vérité dérangeante. Des solutions basées sur l’isolation par processus ou par conteneurs offrent des garanties plus solides. Des runtimes spécialisés sont également une option robuste.
La CVE-2026-26956 n’est qu’un rappel récent. Probablement, ce ne sera pas le dernier.
Acompañe nosso perfil no Instagram!
