Les développeurs sont invités à mettre à niveau vers la dernière version de la bibliothèque vm2 pour corriger toutes les vulnérabilités.
Treize vulnérabilités critiques ont été découvertes dans le package sandbox JavaScript vm2 qui pourraient permettre au code d’un attaquant de s’échapper du conteneur et de faire des choses désagréables aux environnements informatiques. Par conséquent, les développeurs utilisant cette bibliothèque dans leurs applications sont invités à mettre à jour le logiciel vers la dernière version, qui est actuellement la 3.11.2.
Les avertissements proviennent des avis du responsable de vm2, Patrik Simek.
vm2 est une machine virtuelle/sandbox open source qui peut exécuter du code non fiable avec les modules intégrés de Node.js sur liste blanche.
L’une des 13 vulnérabilités les plus graves est CVE-2026-26956, une évasion complète de sandbox avec exécution de code arbitraire. Le code de l’attaquant qui se trouve à l’intérieur peut obtenir l’objet du processus hôte et exécuter les commandes de l’hôte sans aucune coopération de la part de l’hôte.
Cependant, les chercheurs de Socket nous ont indiqué dans un e-mail que l’avis concernant cette évasion indique qu’elle n’a été confirmée que sur Node.js 25.6.1 et nécessite une version Node.js avec gestion et prise en charge des exceptions WebAssembly.
Le scénario le plus risqué, selon eux, serait une application utilisant vm2 version 3.10.4 sur le nœud 25, dans laquelle le JavaScript contrôlé par l’attaquant serait transmis à .
« Il s’agit d’une vulnérabilité limitée mais à fort impact », a déclaré Wenxin Jiang, ingénieur de recherche chez Socket, dans un e-mail. « Cela ne semble pas affecter chaque déploiement de vm2, car l’avis indique une version vulnérable spécifique et une combinaison spécifique Node 25/WebAssembly. Mais lorsque ces conditions s’alignent, la limite de sécurité échoue complètement : le code qui était censé être confiné au bac à sable peut atteindre le processus hôte et exécuter des commandes. C’est pourquoi les équipes utilisant vm2 pour le JavaScript fourni par l’utilisateur doivent appliquer rapidement des correctifs et vérifier à quoi le processus en bac à sable peut accéder. «
MISE À JOUR: Un jour après la publication de cet article, Socket a publié de nouvelles directives indiquant que la portée du package et de l’exécution de cette vulnérabilité particulière est plus large que ne le suggère l’avis initial. Cela signifie, a déclaré Socket, que certains scanners de dépendances peuvent marquer à tort les déploiements vulnérables comme non affectés. Les tests de socket ont révélé que la vulnérabilité affecte toutes les versions de vm2 antérieures à 3.10.5 sur les environnements d’exécution Node.js qui exposent, y compris Node.js 24.x.
Bien qu’il ne s’agisse pas d’un responsable de vm2, Socket a déclaré qu’il publiait un correctif pour les développeurs qui ne peuvent pas immédiatement mettre à niveau vers la dernière version corrigée.
Une autre faille sérieuse est CVE-2026-44007, une vulnérabilité de contrôle d’accès inapproprié dans la bibliothèque vm2 Node.js qui permet l’échappement du bac à sable et l’exécution de commandes arbitraires du système d’exploitation sur l’hôte sous-jacent. Son avis indique que la vulnérabilité réside dans la manière dont l’option interagit avec le résolveur de module existant. Cela a été corrigé dans la version 3.11.1 de vm2.
Selon les chercheurs de Socket, ces deux failles peuvent transformer le JavaScript en bac à sable en exécution de commandes sur le système hôte. La différence réside dans le nombre d’environnements susceptibles d’être exposés. Le problème Node 25/WebAssembly semble plus restreint car il dépend d’une version spécifique de vm2 et d’un comportement d’exécution Node.js plus récent et spécifique. Le problème d’imbrication de NodeVM peut être plus large car il affecte davantage de versions et est déclenché par un modèle de configuration que certains développeurs ont pu utiliser intentionnellement.
Jiang a ajouté que les deux avis pointent vers une leçon plus large : les bacs à sable JavaScript sont difficiles à sécuriser, et de petites différences dans le comportement ou la configuration de l’exécution peuvent avoir des conséquences majeures en matière de sécurité. « Le premier problème semble lié à un chemin étroit vers Node 25/WebAssembly », a-t-il déclaré. « Ce deuxième problème est un échappement basé sur la configuration impliquant NodeVM et .
Dans les deux cas, les utilisateurs les plus à risque sont les organisations qui exécutent du JavaScript non fiable et supposent que vm2 le contient. Ces équipes (de développement d’applications) devraient appliquer des correctifs immédiatement et ajouter une isolation plus forte autour des charges de travail en bac à sable.
« Modèle de sécurité fragile »
Ces vulnérabilités d’évasion du sandbox démontrent pourquoi le sandboxing de code non fiable au sein d’un processus fiable est un modèle de sécurité fragile, a déclaré Adam Reynolds, chercheur principal en sécurité chez Sonatype, dans un e-mail. « Une fois qu’un code non fiable s’exécute dans un processus avec accès aux informations d’identification et aux secrets, au système de fichiers sous-jacent, au réseau ou avec des privilèges de déploiement, un contournement du bac à sable peut facilement conduire à une compromission complète du système », a-t-il déclaré.
Le simple fait d’avoir vm2 installé quelque part dans l’arborescence des dépendances ne suffit pas à rendre certaines de ces vulnérabilités exploitables, a-t-il ajouté. Par exemple, un attaquant a généralement besoin de pouvoir exécuter du JavaScript contrefait (et dans le cas de CVE-2026-26956, du WebAssembly contrefait) dans un bac à sable vm2 contrôlé par l’application vulnérable. Si l’application n’instancie jamais vm2, l’utilise uniquement pour des scripts internes fiables ou ne permet pas du tout l’exécution de code contrôlé par un attaquant, alors il se peut qu’il n’y ait pas de chemin d’exploitation réaliste malgré la présence de la dépendance.
Si une organisation exécute des applications impactées par vm2, elles doivent être mises à niveau immédiatement, a-t-il déclaré. Pour atténuer les risques jusqu’à ce que la mise à niveau soit terminée, les utilisateurs peuvent éviter les environnements d’exécution Node.js 25, désactiver ou bloquer entièrement WebAssembly dans des bacs à sable non fiables et empêcher la compilation/exécution WASM contrôlée par l’utilisateur.
« Étant donné que les futures mises à jour du moteur d’exécution pourraient entraîner des problèmes similaires, vm2 doit être considéré comme une couche d’isolation pratique plutôt que comme une limite de sécurité stricte », a-t-il ajouté.
En outre, Robert Enderle du groupe Enderle a déclaré que les responsables informatiques qui prennent au sérieux la sécurité devraient cesser de s’appuyer sur le sandboxing au niveau logiciel pour le code non fiable. Commencez à envisager de déplacer ces processus vers des conteneurs Docker renforcés ou des isolats V8, a-t-il conseillé.
