La vulnérabilité d’évasion Sandbox dans vm2, utilisée par près de 900 packages NPM, permet aux attaquants de contourner les protections de sécurité et d’exécuter du code arbitraire.
Une vulnérabilité critique a été corrigée dans vm2, une bibliothèque largement utilisée pour le runtime JavaScript Node.js qui permet d’exécuter du code non fiable dans un bac à sable au sein du même processus que le code d’application fiable. La faille permet une évasion du bac à sable, ce qui est aussi grave que pour un composant logiciel dont l’objectif principal est de faire respecter une frontière de sécurité entre le code fiable et non fiable.
La bibliothèque vm2, qui est répertoriée comme dépendance par près de 900 autres packages sur NPM et de nombreux projets sur GitHub, n’est pas étrangère aux vulnérabilités d’échappement du bac à sable. En fait, en juillet 2023, son créateur a décidé d’arrêter la maintenance du projet et de le déprécier après une telle vulnérabilité.
Bien que le projet n’ait pas été maintenu, en l’absence de bonnes alternatives, les gens ont continué à l’utiliser, conduisant à des millions de téléchargements chaque mois. En octobre 2025, le responsable d’origine a décidé de ressusciter le projet après avoir corrigé toutes les vulnérabilités passées et annoncé son intention de le réécrire en TypeScript.
La nouvelle vulnérabilité corrigée cette semaine porte le numéro CVE-2026-22709 et affecte les versions antérieures à 3.10.2. Il est conseillé aux utilisateurs de mettre à niveau vers la dernière version dès que possible.
« Dans vm2 pour la version 3.10.0, Promise.prototype.then Promise.prototype.catch la désinfection des rappels peut être contournée », indique l’avis officiel. « Cela permet aux attaquants de s’échapper du bac à sable et d’exécuter du code arbitraire. »
Le sandboxing est un jeu du chat et de la souris
Les bacs à sable comme vm2 sont nécessaires au Web et à d’autres applications basées sur Node dont la fonctionnalité permet aux utilisateurs ou aux outils de télécharger et d’exécuter des scripts. Étant donné que le code contrôlé par l’utilisateur n’est pas fiable par nature, il ne peut pas être autorisé à s’exécuter dans le même contexte que l’application elle-même. Pourtant, l’application hôte doit surveiller et voir ce que fait le code.
La bibliothèque vm2 y parvient grâce à un réseau complexe de proxys qui interceptent et médiatisent les interactions entre le bac à sable et l’environnement hôte. Mais la complexité de JavaScript signifie qu’il y aura probablement toujours un moyen de tromper cette chaîne de proxys.
Le projet est honnête à ce sujet dans sa description : « Les objets sont accessibles via des chaînes de prototypes, les constructeurs peuvent être atteints via des objets d’erreur, les symboles fournissent des points d’ancrage de protocole et l’exécution asynchrone crée des fenêtres de synchronisation. Le grand nombre de façons de passer d’un objet à un autre en JavaScript rend extrêmement difficile la construction d’un bac à sable en cours de processus hermétique. »
Le responsable prévient clairement que de nouveaux contournements seront probablement découverts dans le futur et que même s’ils seront corrigés, le jeu du chat et de la souris continuera. Dans son annonce concernant la résurrection du projet en octobre, il a indiqué qu’il espérait que la détection des vulnérabilités assistée par l’IA contribuerait à détecter davantage de ces problèmes à l’avenir.
Il existe d’autres alternatives pour isoler le code qui offriraient des garanties de sécurité plus solides, telles que le sandboxing complet des processus, les machines virtuelles, les conteneurs, etc. Mais ils entraînent des coûts de performance plus élevés ou ajoutent d’autres complexités et obstacles. Sans oublier que ces approches ne sont pas non plus exemptes de vulnérabilité.
Le responsable indique que vm2 ne doit être utilisé que lorsque :
- Vous avez besoin d’une intégration étroite avec les objets hôtes et d’une communication synchrone rapide
- Le code non fiable provient d’une source relativement fiable (par exemple, des outils internes, des systèmes de plugins avec des auteurs approuvés)
- Vous combinez vm2 avec d’autres couches de sécurité (isolation du réseau, restrictions du système de fichiers, limites des ressources)
- Vous acceptez le risque et surveillez activement les mises à jour de sécurité
