External risk intelligence

vm2 Sandbox Escape via Stale Promise Protector in Node.js

CVE advisorySeverity: CRITICAL (CVSS 9.3)

CVE-2026-92944

The vulnerability exists in vm2, a sandboxing library used within Node.js applications to execute untrusted code. While the library itself is not inherently internet-facing, it is frequently integrated into web applications, APIs, or server-side services that process external user input. Exposure is dependent on how developers implement the sandbox within their specific application architecture.

Halo Surface Signal: 3 out of 5 — possibly public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

A vulnerability has been identified in the vm2 sandboxing library used in Node.js environments. This issue could allow for the escape of the sandbox, potentially leading to unauthorized code execution. The primary concern is to confirm if this technology is in use and exposed to untrusted input.

  • Code can escape sandbox protections.
  • Affects applications using vm2 for sandboxing.
  • Confirm relevance and exposure of the library.

Attack Path

How an attacker could exploit the issue

An attacker could leverage a sandbox escape in the vm2 library to execute arbitrary code on a Node.js system. This is achieved by exploiting a flaw in how `Promise.prototype.finally()` interacts with V8's PromiseThenLookupChain protector, allowing the attacker to bypass sandbox restrictions and gain access to host functions.

  • No authentication required for entry.
  • Triggered by crafting a specific asynchronous function.
  • Risk of arbitrary code execution on the host.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability could allow attackers to escape the sandbox environment in Node.js applications that use the vm2 library. When processing untrusted code, certain asynchronous operations might bypass security protections, enabling arbitrary code execution on the host system.

  • Host system code execution.
  • Exploits asynchronous function with controlled constructor.
  • Compromise of the Node.js application.

Operational Fix

Recommended remediation, mitigation, and detection steps

Teams responsible for Node.js applications and their underlying infrastructure should address this critical vulnerability. The first practical step is to identify all deployments of the affected library, confirm if they process untrusted input or are exposed externally, and then assign ownership for remediation.

  • Confirm application owner and scope.
  • Verify external reachability and business impact.
  • Plan remediation based on risk assessment.

Supplementary metadata

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Frequently asked questions

What is the vm2 library used for in Node.js?

vm2 is a sandboxing library designed to execute untrusted JavaScript code safely by isolating it from the main application. Developers use it to run third-party code, scripts, or plugins within a restricted environment, preventing that code from accessing sensitive host system resources or critical functions of the Node.js runtime.

How does CVE-2026-92944 cause a sandbox escape?

This vulnerability, classified as CWE-693 (Protection Mechanism Failure), occurs because vm2 fails to properly handle specific asynchronous operations. When Promise.prototype.finally() is called, a flaw in how the V8 engine protects promise chains allows the code inside the sandbox to bypass security wrappers. This ultimately grants the code the ability to reach host-level functions, breaking the isolation boundary designed to contain it.

What triggers this sandbox escape?

An attacker triggers the vulnerability by providing a specially crafted asynchronous function to the sandbox. This function returns a Promise containing an attacker-controlled constructor symbol. If the environment is running Node.js 26, this manipulation forces the sandbox to leak host-level objects. Note that simply having the library installed is not enough; the application must actively execute untrusted input that invokes these specific promise patterns.

Is my application at risk from this vulnerability?

Halo Surface Signal indicates that while vm2 is not inherently internet-facing, it is commonly integrated into APIs or web services that process user-supplied code. If your service takes external input and passes it to a vm2 sandbox for processing, it may be reachable by attackers. The actual risk depends on your specific architecture and whether you allow potentially malicious actors to provide the asynchronous JavaScript code that vm2 executes.

What is the first step to address this issue?

Begin by auditing your dependency tree to confirm if your Node.js applications use vm2 versions 3.10.2 through 3.11.6. Once identified, map these instances to determine which ones process external, untrusted input versus internal-only data. Assign ownership for these components and evaluate the business necessity of the current sandboxing implementation to plan the appropriate update or architectural change.

References