Les évasions du bac à sable vm2 transforment l'injection de prompt en RCE hôte

De quoi s’agit-il ?

Au cours du premier semestre 2026, des chercheurs en sécurité ont divulgué une vague de vulnérabilités d’évasion de bac à sable dans vm2, une bibliothèque npm autrefois populaire pour exécuter du JavaScript non fiable sous contraintes, comme une liste blanche de modules restreinte. Une première évasion critique est apparue en janvier 2026 (documentée par StepSecurity et Semgrep), suivie d’un ensemble de plus de dix identifiants supplémentaires les 4 et 5 mai 2026, la plupart notés entre CVSS 9.0 et 10.0 (Kodem Security, 14 mai 2026).

Ce qui en fait un sujet pour un site de sécurité IA plutôt qu’un simple bug Node.js, c’est l’emplacement de vm2. De nombreux frameworks d’agents IA utilisent vm2 comme couche d’isolation pour exécuter le code que le modèle génère lui-même. Le 7 mai 2026, Microsoft Security Research a nommé le problème structurel qui en résulte : dans les frameworks d’agents où les prompts peuvent influencer la logique exécutable, une évasion de bac à sable convertit une injection de prompt en exécution de code à distance au niveau de l’hôte — « When prompts become shells ».

Comment ça marche

La chaîne comporte quatre étapes, et aucune n’exige un exploit inédit — seulement une primitive d’évasion connue et un agent câblé pour exécuter du code généré.

D’abord, du JavaScript non fiable atteint vm2. Dans un produit à plugins ou en SaaS, la source est un code soumis par l’utilisateur. Dans un agent, la source est la propre sortie du modèle : un outil qui laisse l’agent « écrire et exécuter un script » exécutera volontiers un script vers lequel un attaquant l’a orienté via des instructions injectées dans une page web, un document ou un résultat d’outil.

Ensuite, le code déclenche un abus de la frontière du bac à sable. L’isolation de vm2 est appliquée presque entièrement en JavaScript — réécriture des clauses catch, pontage par proxy des objets qui traversent la frontière, et correctifs des chemins d’évasion connus un par un. Les divulgations de 2026 défont ce modèle chacune par une voie différente : contournement de la sanitisation des rappels de promesses, abus de SuppressedError et d’autres gestions d’exceptions, astuces __lookupGetter__ et getPrototypeOf, déballage de proxy via inspect(), et chaînes de pollution de prototype. Toutes produisent le même résultat — une référence, un rappel ou une recherche de propriété qui atteint un objet dans le realm de l’hôte.

// Forme vulnérable (à titre illustratif) : un agent exécute du JS généré par le modèle dans vm2
const { VM } = require('vm2');
const result = new VM().run(modelGeneratedCode); // [REDACTED] la primitive d'évasion s'exécute ici

Vient ensuite l’accès aux capacités de l’hôte. Une fois hors du bac à sable, le code peut atteindre l’objet process de Node et, à partir de là, child_process, le système de fichiers et le réseau sortant. L’un des avis de mai est précisément un contournement de liste blanche menant directement à child_process. La quatrième étape est l’exécution de la charge : des commandes shell arbitraires s’exécutent avec les privilèges du runtime Node.js — ce qui, dans un déploiement d’agent, signifie souvent l’accès aux secrets d’environnement, aux identifiants cloud et au réseau interne.

Pourquoi c’est important

L’injection de prompt à elle seule est généralement un problème de couche de sortie : le modèle dit quelque chose qu’il ne devrait pas. Acheminée à travers un bac à sable d’exécution vulnérable, cette même injection devient un problème de couche d’infrastructure : un attaquant obtient un shell sur la machine. C’est un changement qualitatif du rayon d’impact, et c’est exactement la combinaison signalée par Microsoft et par les intervenants qui suivent la vague.

Deux propriétés font de vm2 un mauvais choix pour cette tâche. Il a un historique pluriannuel d’évasions de bac à sable, et son mainteneur a abandonné le projet — les correctifs ne constituent donc pas un flux fiable. Et le modèle d’isolation n’a aucune défense structurelle contre cette classe ; chaque CVE est un correctif ponctuel pour une nouvelle primitive, ce qui explique pourquoi 2026 a produit un ensemble plutôt qu’un seul bug. Une hypothèse réaliste est que d’autres variantes arrivent, et que le même cadrage « prompts become shells » s’étendra à d’autres bacs à sable JavaScript à mesure que les chercheurs s’y intéresseront.

La question pratique de l’exposition n’est pas « vm2 est-il installé » (une analyse SCA y répond). C’est de savoir si un prompt non fiable peut atteindre un chemin d’exécution dynamique passant par vm2 avec de vrais outils attachés. Une application web qui évalue un script interne codé en dur via vm2 et un agent qui exécute du code généré par LLM dans vm2 avec accès shell sont identiques dans un manifeste de dépendances et portent des risques totalement différents.

Défenses

• Ne traitez pas vm2 (ni aucun bac à sable JS in-process) comme une frontière de sécurité. Si vous devez exécuter du code non fiable ou généré par le modèle, superposez une véritable isolation en dessous — un conteneur séparé, gVisor ou Firecracker — pour qu’une évasion atterrisse dans un environnement jetable à moindre privilège plutôt que sur votre hôte.
• Corrigez, mais prévoyez de migrer. Mettez vm2 à jour vers la dernière version corrigée pour fermer les primitives actuellement divulguées, et priorisez l’abandon de cette bibliothèque dépréciée au profit d’une approche activement maintenue pour l’exécution non fiable.
• Restreignez les outils de l’agent. Un agent qui ne peut pas appeler child_process, ne peut pas écrire hors d’un répertoire temporaire et ne peut pas atteindre de destinations réseau hors liste blanche ne peut pas transformer une évasion de bac à sable en compromission d’infrastructure. La restriction des outils se déploie plus vite qu’une refonte du modèle d’exécution.
• Retirez les identifiants du contexte d’exécution. Le processus Node.js qui exécute du code non fiable ne devrait pas porter de clés AWS/GCP, de jetons de registre ni de secrets CI. Utilisez des jetons à portée limitée et à durée de vie courte, et supprimez les identifiants ambiants.
• Surveillez à l’exécution. Traquez les processus node qui lancent des shells ou des appels child_process, les lectures inattendues de fichiers comme ~/.aws/credentials ou /proc/self/environ, et le trafic sortant d’un runtime d’agent vers des domaines hors liste blanche. L’évasion se produit à l’intérieur du processus : c’est la télémétrie comportementale — pas seulement l’analyse des dépendances — qui la détecte.
• Cartographiez vos chemins d’exécution. Inventoriez chaque service où vm2 apparaît dans l’arbre de dépendances direct ou transitif, et repérez ceux où du code non fiable ou généré par LLM peut réellement l’atteindre. Ce sous-ensemble est l’exposition réelle.

Statut

Élément	Valeur
Composant affecté	vm2 (bac à sable Node.js pour JavaScript non fiable), déprécié par son mainteneur
Nature	Multiples failles d’évasion de bac à sable → RCE hôte
Fenêtre de divulgation	Janv. 2026 (CVE-2026-22709) et un ensemble des 4–7 mai 2026 (10+ CVE, CVSS 9.0–10.0)
Pertinence IA	Les frameworks d’agents exécutent du JS généré par le modèle dans vm2 → injection de prompt vers RCE hôte
Corrigé dans	Versions corrigées de vm2 jusqu’à la branche 3.11.x (vérifiez l’avis courant avant déploiement)
CVE de référence	CVE-2026-22709, CVE-2026-24118, CVE-2026-24120, CVE-2026-24781, CVE-2026-26332, CVE-2026-26956, CVE-2026-43997, CVE-2026-43999, CVE-2026-44005 (et identifiants associés de mai 2026)

Dates clés : 26 janvier 2026 — première évasion 2026 divulguée. 4–7 mai 2026 — ensemble de 10+ évasions. 7 mai 2026 — analyse « prompts become shells » de Microsoft sur l’impact au niveau des frameworks d’agents.

Cet article couvre une classe de vulnérabilité divulguée publiquement à des fins défensives et omet volontairement tout code d’exploitation fonctionnel.