CVE-2026-92944 : échappement critique du bac à sable dans vm2 pour Node.js 26

CVE-2026-92944 : échappement critique du bac à sable dans vm2 pour Node.js 26

En bref

Une vulnérabilité critique (CVE-2026-92944, CVSS 9.3) a été publiée dans la librairie vm2, utilisée pour exécuter du code dans des environnements isolés ("bac à sable") au sein d'applications Node.js [1]. La faille permet à du code non fiable de s'échapper du bac à sable et de prendre le contrôle du processus hôte lorsqu'il s'exécute sur Node.js 26 [1][2]. Si votre entreprise développe ou utilise des applications qui exécutent du code tiers ou du code utilisateur via vm2, la première étape à entreprendre dès aujourd'hui est d'identifier où cette librairie est utilisée et de vérifier la version installée.

Qu'est-ce que c'est et pourquoi est-ce important

vm2 est un outil très utilisé par les développeurs pour exécuter du code JavaScript provenant de sources non fiables dans un environnement supposément isolé du reste de l'application : plugins utilisateurs, scripts personnalisés, correcteurs d'exercices de programmation, moteurs de règles, etc. L'idée est que, quoi qu'il se passe à l'intérieur de ce code, il ne puisse pas « sortir » ni toucher le système réel.

Selon la description officielle de la faille, dans les versions de vm2 comprises entre 3.10.2 et 3.11.6, un mécanisme interne du moteur V8 (le protecteur appelé PromiseThenLookupChain) devient obsolète sous Node.js 26, ce qui permet à une fonction asynchrone bien construite par un attaquant de contourner les protections du bac à sable via la méthode Promise.prototype.finally() [1]. Le résultat est que le code « isolé » peut atteindre des fonctions internes du système et exécuter du code arbitraire avec les privilèges du processus principal [1][2].

L'intel propre au radar OCIRIA, qui surveille les vulnérabilités pertinentes pour les infrastructures de développement et de production, classe ce cas dans la catégorie exécution de code à distance et souligne que son importance réside précisément dans le fait qu'il brise le principe d'isolation : si le bac à sable échoue, toute l'application — et potentiellement d'autres données et services au sein du même processus — se retrouve exposée [2].

Quant à savoir s'il existe des preuves d'exploitation active dans le monde réel, à la date de cette publication, la CVE ne figure pas dans le catalogue des vulnérabilités activement exploitées (KEV) maintenu par l'agence américaine CISA [3]. Cela ne signifie pas qu'elle soit inoffensive — son score de 9.3 la classe parmi les plus graves [1] — mais qu'il n'existe pas de preuve documentée de campagnes d'attaque actives à ce stade.

Qui est concerné

Cette vulnérabilité concerne les organisations qui :

• Développent ou maintiennent des applications Node.js utilisant la librairie vm2 pour isoler l'exécution de code tiers ou utilisateur.
• Ont mis à jour ou déploient des environnements sur Node.js 26, car la faille se manifeste spécifiquement dans cette version du runtime en raison d'un changement dans le moteur V8 [1].
• Exploitent des plateformes de type « code en tant que service » : éditeurs en ligne, bacs à sable de test, moteurs d'automatisation, plugins ou extensions exécutés côté serveur, correcteurs automatiques, etc.

La vérité structurée gérée par OCIRIA n'identifie pas de fournisseurs concrets touchés au-delà du paquet vm2 lui-même ; nous recommandons donc de ne pas présumer qu'un fournisseur spécifique est exposé ou non sans le vérifier directement.

Comment savoir si vous êtes vulnérable

Il n'existe pas de moyen générique de « le voir à l'œil nu » : cela dépend des dépendances utilisées par votre code et de l'environnement dans lequel il s'exécute. Nous recommandons :

1. De passer en revue l'inventaire des dépendances de vos applications Node.js (package.json / package-lock.json) à la recherche de vm2 et de vérifier la version exacte installée.

2. De confirmer quelle version de Node.js exécute chaque service en production, en prêtant une attention particulière à ceux qui tournent déjà sur Node.js 26.

3. De vérifier la surface exposée de vos services et environnements de développement, en particulier ceux qui acceptent ou exécutent du code externe, afin de détecter les points d'exposition non contrôlés ou non inventoriés.

Comment vous protéger

• Mettez à jour vm2 vers une version corrigée dès que le mainteneur du projet la publiera ; en attendant, envisagez de limiter ou de désactiver temporairement les fonctionnalités qui exécutent du code non fiable si le risque est élevé [2].
• Revoyez l'usage des bacs à sable en général : cette famille de failles (échappement de bac à sable) ayant tendance à se répéter, évaluez si votre architecture dépend excessivement d'un seul mécanisme d'isolation au niveau du processus, ou s'il convient de le renforcer par une isolation supplémentaire (conteneurs, machines virtuelles légères, permissions système restreintes).
• Auditez le code exécuté en bac à sable provenant de sources non fiables : utilisateurs externes, plugins tiers ou intégrations peu contrôlées.
• Surveillez les alertes de sécurité des librairies critiques qui composent votre chaîne d'approvisionnement logicielle, pas seulement celles des frameworks principaux.
• Priorisez selon l'exposition réelle : si vos services n'exécutent pas de code tiers en bac à sable ou si vous n'utilisez pas Node.js 26, le risque immédiat est moindre, mais il convient de le documenter pour de futures revues.

Questions fréquentes

Quelle est la gravité de cette vulnérabilité ?

Selon NVD, elle a un score CVSS de 9.3, qualifié de critique [1].

Cette vulnérabilité est-elle activement exploitée ?

À la date de cette publication, elle ne figure pas dans le catalogue des vulnérabilités activement exploitées (KEV) de CISA ; il n'existe donc pas de preuve documentée d'exploitation active [3].

Affecte-t-elle toutes les applications Node.js ?

Non. Elle concerne spécifiquement les applications utilisant la librairie vm2 (versions 3.10.2 à 3.11.6) pour exécuter du code en bac à sable, et l'échappement décrit se produit dans le contexte de Node.js 26 [1].

Que dois-je faire si je ne sais pas si j'utilise vm2 ?

Passez en revue l'inventaire des dépendances de vos projets Node.js et, en cas de doute sur l'exposition réelle de vos systèmes, il convient de réaliser une revue plus large de votre surface exposée.

Sources

• [1] https://nvd.nist.gov/vuln/detail/CVE-2026-92944
• [2] https://github.com/advisories/GHSA-27g9-p43v-cw3v
• [3] https://raw.githubusercontent.com/cisagov/kev-data/develop/known_exploited_vulnerabilities.json