CVE-2026-92944: critical sandbox escape in vm2 for Node.js 26

CVE-2026-92944: critical sandbox escape in vm2 for Node.js 26

In short

A critical vulnerability (CVE-2026-92944, CVSS 9.3) has been published in the vm2 library, used to execute code in isolated environments ("sandboxes") within Node.js applications [1]. The flaw allows untrusted code to escape the sandbox and take control of the host process when running on Node.js 26 [1][2]. If your company develops or uses applications that run third-party or user code via vm2, the first step today is to identify where this library is used and check the installed version.

What it is and why it matters

vm2 is a tool widely used by developers to run JavaScript code of untrusted origin within an environment supposedly isolated from the rest of the application: user plugins, custom scripts, code exercise graders, rule engines, etc. The idea is that, whatever happens inside that code, it cannot "get out" or touch the real system.

According to the official description of the flaw, in vm2 versions between 3.10.2 and 3.11.6, an internal V8 engine mechanism (the protector called PromiseThenLookupChain) becomes outdated on Node.js 26, and this allows an asynchronous function carefully crafted by an attacker to bypass the sandbox protections via the Promise.prototype.finally() method [1]. The result is that the "isolated" code can reach internal system functions and execute arbitrary code with the privileges of the main process [1][2].

OCIRIA radar's own intel, which monitors vulnerabilities relevant to development and production infrastructures, classifies this case within the remote code execution category and notes that its importance lies precisely in the fact that it breaks the isolation premise: if the sandbox fails, the entire application —and potentially other data and services within the same process— is exposed [2].

As for whether there is evidence of active exploitation in the real world, as of this publication the CVE does not appear in the Known Exploited Vulnerabilities (KEV) catalog maintained by the US agency CISA [3]. This does not mean it is harmless —its score of 9.3 places it among the most severe [1]— but rather that there is no documented evidence of active attack campaigns at this time.

Who it affects

This vulnerability affects organizations that:

• Develop or maintain Node.js applications that use the vm2 library to isolate the execution of third-party or user code.
• Have updated or are deploying environments on Node.js 26, since the flaw specifically manifests in that runtime version due to a change in the V8 engine [1].
• Operate "code as a service" type platforms: online editors, test sandboxes, automation engines, plugins or extensions run on the server, automatic graders, etc.

The structured intel that OCIRIA maintains does not identify specific affected vendors beyond the vm2 package itself, so we recommend not assuming that a specific vendor is or is not exposed without verifying it directly.

How to know if you are vulnerable

There is no generic way to "see it at a glance": it depends on which dependencies your code uses and in what environment it runs. We recommend:

1. Reviewing the dependency inventory of your Node.js applications (package.json / package-lock.json) looking for vm2 and checking the exact installed version.

2. Confirming which Node.js version each service runs in production, paying special attention to those already running on Node.js 26.

3. Checking the exposed surface of your services and development environments, especially those that accept or execute external code, to detect points of exposure that are not controlled or inventoried.

How to protect yourself

• Update vm2 to a patched version as soon as the project maintainer publishes it; in the meantime, consider limiting or temporarily disabling the features that execute untrusted code if the risk is high [2].
• Review the use of sandboxes in general: since this family of flaws (sandbox escape) tends to recur, evaluate whether your architecture relies excessively on a single process-level isolation mechanism, or whether it should be reinforced with additional isolation (containers, lightweight virtual machines, restricted operating system permissions).
• Audit the sandboxed code coming from untrusted sources: external users, third-party plugins, or poorly controlled integrations.
• Monitor security alerts for the critical libraries that are part of your software supply chain, not just the main frameworks.
• Prioritize by real exposure: if your services do not run third-party code in a sandbox or you do not use Node.js 26, the immediate risk is lower, but it is worth documenting for future reviews.

Frequently asked questions

How severe is this vulnerability?

According to NVD, it has a CVSS score of 9.3, rated as critical [1].

Is this vulnerability being actively exploited?

As of this publication, it does not appear in CISA's Known Exploited Vulnerabilities (KEV) catalog, so there is no documented evidence of active exploitation [3].

Does it affect any Node.js application?

No. It specifically affects applications that use the vm2 library (versions 3.10.2 to 3.11.6) to run code in a sandbox, and the described escape occurs in the context of Node.js 26 [1].

What should I do if I don't know whether I use vm2?

Review the dependency inventory of your Node.js projects and, if you have doubts about the real exposure of your systems, it is worth conducting a broader review of your exposed surface.

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