Une faille critique du sandbox vm2 permet à du code non fiable de s'échapper vers l'hôte

Les mainteneurs de vm2, une bibliothèque de sandbox Node.js largement utilisée, ont révélé une vulnérabilité critique pouvant permettre à du JavaScript non fiable de sortir de son sandbox et d'exécuter du code sur la machine hôte. La faille est suivie sous l'identifiant CVE-2026-26956, touche vm2 version 3.10.4 et s'accompagne d'un code exploit de preuve de concept déjà disponible publiquement.

Cela compte parce que vm2 est l'un des outils standards vers lesquels les développeurs se tournent lorsqu'ils doivent exécuter du JavaScript fourni par des utilisateurs dans un environnement supposé restreint. On le retrouve dans des plateformes de codage en ligne, des produits d'automatisation, des outils d'AI et des applications SaaS permettant aux clients d'exécuter des scripts. Lorsqu'un escape de sandbox apparaît dans ce type de logiciel, le problème n'est pas un joli bug théorique. C'est une question directe de savoir si du code locataire non fiable peut se transformer en compromission au niveau de l'hôte.

Selon l'advisory du mainteneur et les informations de BleepingComputer, le bug est lié à la manière dont vm2 gère les exceptions qui traversent la frontière entre le sandbox et l'hôte. Dans la configuration affectée, le WebAssembly exception handling peut contourner les protections de vm2 au niveau JavaScript dans le moteur V8. Cela peut permettre à un objet d'erreur côté hôte de refluer dans le sandbox, où des attaquants peuvent exploiter la chaîne de constructor pour retrouver l'accès à des composants internes de Node.js comme le process object et, au final, exécuter des commandes arbitraires sur l'hôte.

L'exposition n'est pas universelle dans tous les déploiements Node.js. L'advisory indique que le problème a été confirmé sur Node.js 25.6.1 dans des environnements où WebAssembly exception handling et le support de JSTag sont activés. Cette portée technique est importante, mais elle ne doit pas créer un faux sentiment de sécurité. vm2 est téléchargé plus d'un million de fois par semaine sur npm, et des bibliothèques comme celle-ci sont souvent enfouies profondément dans de plus gros produits, des outils internes ou des fonctions d'extensibilité client que les équipes n'inventorient pas avec assez de rigueur.

Le détail le plus urgent est que le code exploit est déjà public. Dès qu'un escape de sandbox dispose à la fois d'un CVE et d'une preuve de concept publique, l'écart entre la divulgation et l'exploitation opportuniste tend à se réduire rapidement, surtout dans les services exposés sur internet qui exécutent des workflows utilisateurs, des extraits de code ou des étapes d'automatisation. Si une entreprise utilise vm2 pour isoler une logique non fiable, elle doit partir du principe que des attaquants vont tester cette frontière dès maintenant, pas plus tard.

Le chemin de patch est simple. Les utilisateurs doivent quitter immédiatement vm2 3.10.4 et passer à la version 3.10.5 ou ultérieure, la version 3.11.2 étant actuellement disponible. Mais appliquer le patch ne constitue pas à lui seul toute la réponse. Les équipes devraient aussi identifier où vm2 est embarqué, confirmer si des configurations affectées de Node.js 25 sont utilisées et revoir toutes les surfaces produit où des utilisateurs externes peuvent soumettre du code qui finit par atteindre un sandbox vm2.

Cette divulgation s'inscrit aussi dans une tendance plus large. vm2 a été touché par plusieurs bugs graves d'escape de sandbox au cours des dernières années, ce qui soulève une question d'ingénierie difficile mais de plus en plus importante : quel niveau d'isolation réel un sandbox JavaScript offre-t-il une fois que les attaquants commencent à trouver des chemins pour contourner les défenses au niveau du langage ? Pour les équipes qui construisent des plateformes reposant sur du code exécuté par les utilisateurs, cette question devient architecturale plutôt qu'accessoire. Comme l'a d'abord rapporté BleepingComputer, la réponse la plus sûre ici n'est pas seulement de patch rapidement, mais aussi de réévaluer le niveau de confiance accordé à vm2 dès le départ.