Description

vm2 3.11.6 is vulnerable to a sandbox escape leading to remote code execution in the host Node.js process. The fix for GHSA-m283-3h24-438v is incomplete: the bridge gate at lib/bridge.js:1624 identity-checks only the direct call target when deciding whether to rebuild/sanitise a rejected host Promise value. Registering the rejection handler through Function.prototype.call or .apply indirection (e.g., p.then.call(p, undefined, cb)) makes the intercepted target host Function.prototype.call, so the sanitiser never runs and the raw host error reaches sandbox code with its own properties intact. If an embedder exposes a host-realm Promise to the sandbox (an async host function bridged via the sandbox option, or a NodeVM external module's async method) and that Promise rejects with an Error carrying a non-primitive own property referencing a host object (for example err.detail = process), untrusted code in the sandbox obtains a fully functional proxy to that host object and can execute arbitrary commands with the privileges of the host process (e.g., e.detail.mainModule.require('child_process').execSync(...)). The direct p.then(undefined, cb), bind, and Reflect.apply forms are correctly sanitised. Fixed in vm2 3.11.7.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "10.0",
  "pubDate": "2026-09-17T14:17:58.517Z",
  "pubdate": "2026-09-17T14:17:58.517Z",
  "executiveSummary": "The vm2 library version 3.11.6 is affected by a critical sandbox escape vulnerability resulting in Remote Code Execution (RCE) on the host Node.js process.\nThis vulnerability stems from an incomplete fix for GHSA-m283-3h24-438v, specifically within the identity-checking mechanism of the bridge gate.\nBy leveraging Function.prototype.call or .apply indirection when handling rejected host Promises, an attacker within the sandbox can bypass security sanitizers.\nSuccessful exploitation allows an attacker to leak host-realm objects—such as the process object—attached to Error properties, granting the ability to execute arbitrary commands with the privileges of the host Node.js process.\nThis vulnerability is critical because it compromises the isolation boundary provided by the vm2 sandbox, potentially leading to a full system compromise depending on the host process privileges.",
  "technicalDetails": "The root cause of this vulnerability lies in the insufficient sanitization logic implemented at lib/bridge.js:1624. The vm2 sandbox attempts to intercept and sanitize rejected host Promise values to prevent host-realm objects from leaking into the sandbox environment.\nHowever, the existing identity-checking mechanism only evaluates the direct call target. An attacker can circumvent this check by invoking the Promise rejection handler through indirect methods such as p.then.call(p, undefined, cb) or p.then.apply(p, [undefined, cb]).\nIn these scenarios, the intercepted target is identified as Function.prototype.call or Function.prototype.apply rather than the intended Promise handler. Consequently, the sanitization routine is bypassed, allowing the raw, unsanitized host Error object to be passed into the sandbox context.\nThe attack flow requires the embedder to expose a host-realm Promise to the sandbox, which can occur via asynchronous host functions bridged through the sandbox configuration or through asynchronous methods in NodeVM external modules.\nIf the exposed Promise rejects with an Error object that carries a non-primitive property referencing a host object (e.g., err.detail = process), the sandboxed code can access that reference. Because the security boundary failed to intercept the Error object, the sandbox gains a functional proxy to the host object.\nBy accessing this host-realm reference, the attacker can traverse the object graph to reach powerful built-in Node.js modules. For instance, the attacker could execute process.mainModule.require('child_process').execSync(...) to achieve arbitrary code execution on the host machine.\nThe vulnerability is specific to scenarios where indirection is used to register callbacks. Standard direct calls like p.then(undefined, cb), bind, or Reflect.apply are correctly handled by the existing sanitization logic, as they do not obfuscate the call target from the bridge gate's inspection mechanism."
}