CVE-2026-92952: Sandbox Escape and State Corruption in vm2 via Node.js-internal Symbol Leak

The vm2 library is designed to run untrusted JavaScript code in a sandboxed V8 isolate environment within a Node.js process. To facilitate communication between the restricted sandbox and the host environment, vm2 establishes a bridge governed by JavaScript Proxies. These proxies intercept operations like property access, object definition, and function execution to ensure sandbox isolation.

An essential requirement of this architecture is the complete isolation of internal metadata from crossing the boundary. Node.js uses specific globally registered Symbol objects, such as those prefixed with nodejs., to designate internal object states across realms. If a sandboxed script can access these internal symbols, it can leverage proxy write traps to override or inject properties directly onto live objects in the host environment.

In modern Node.js runtimes (Node.js 18+), internal state indicators for Web Streams are stored on ReadableStream.prototype utilizing symbols. Due to omission in the symbol sanitization lists of vm2 versions 3.11.4 through 3.11.6, untrusted sandboxed code can extract host-realm symbols and manipulate the internal state checks of host-visible stream instances.

The root cause of this vulnerability lies in the missing sanitization of the global symbols Symbol.for('nodejs.stream.disturbed') and Symbol.for('nodejs.stream.errored') within the vm2 bridge. These specific symbols are used by Node.js internally to keep track of whether a web stream has been read, cancelled, or has entered an error state.

When standard stream operations are evaluated, the Node.js helper function stream.Readable.isDisturbed() evaluates whether a stream's content has already been consumed. It achieves this by reading the internal state accessor matching the symbol nodejs.stream.disturbed. If this property evaluates to a truthy value, the helper confirms the stream is consumed, preventing subsequent reads and enforcing single-consumption rules.

Because the vm2 proxy bridge failed to include these symbols in its static filtering list, sandboxed code could enumerate the symbols present on ReadableStream.prototype. After extracting the real symbol, the sandbox can issue a write command via Object.defineProperty on a host-realm stream instance. This defines an "own" property on the host stream instance with the value false, shadowing the prototype getter. When the host environment subsequently calls isDisturbed(), the nullish coalescing operator short-circuits on the shadowed false value, leading the host to believe the stream is unconsumed.

The vulnerability was resolved in version 3.11.7 via commit a45444d5abbdfa59055528f584df5f21cc7c42da. Instead of continuously updating a static list of dangerous symbols, the maintainers implemented a generalized namespace-based catch-all verification mechanism.

At bootstrap time, pristine references to runtime operations are cached before any untrusted sandbox code execution can compromise them. Specifically, Symbol.keyFor and String.prototype.startsWith are secured:

// In lib/bridge.js
const thisSymbolKeyFor = Symbol.keyFor;
const thisStringPrototypeStartsWith = String.prototype.startsWith;

The check function isDangerousCrossRealmSymbol was modified to intercept all registered symbols that reside within the reserved nodejs. namespace. This namespace-based approach closes the recurring maintenance gap that previously required updating explicit lists for individual Node.js versions:

function isDangerousCrossRealmSymbol(key) {
	if (typeof key !== 'symbol') return false;
 
	// Resolve the global registration key for the symbol
	const nsKey = thisSymbolKeyFor(key);
	
	// If the symbol is registered and starts with 'nodejs.', block it
	if (typeof nsKey === 'string' && thisReflectApply(thisStringPrototypeStartsWith, nsKey, ['nodejs.'])) return true;
	
	return (
		key === thisSymbolNodeJSUtilInspectCustom ||
		key === thisSymbolNodeJSRejection ||
		// ... traditional fallback checks
	);
}

A similar change was mirrored within lib/setup-sandbox.js inside the isDangerousSymbol function to ensure that extraction techniques utilizing getOwnPropertySymbols or Reflect.ownKeys are stripped of any nodejs. namespace symbols before surfacing back to the sandboxed runtime.

To execute this sandbox escape, the sandboxed environment must have access to a host-exposed stream prototype or an instance of a web stream. The attack consists of three distinct phases: symbol extraction, target instantiation, and property shadowing.

First, the attacker inspects the prototype of a web stream, extracting its symbol array:

const streamProto = ReadableStream.prototype;
const targetSymbol = Object.getOwnPropertySymbols(streamProto)
  .find(sym => sym.description === 'nodejs.stream.disturbed');

Second, the sandboxed attacker target-defines this symbol on an active, fully consumed stream exposed from the host realm. By setting the descriptor value to false, the attacker intercepts the prototype getter:

Object.defineProperty(hostStream, targetSymbol, {
  value: false,
  configurable: true
});

When the hosting environment processes the stream, checks like stream.Readable.isDisturbed(hostStream) evaluate the shadowed value and erroneously return false. This allows the sandboxed application to manipulate state-dependent application logic, bypass integrity constraints, and force the host program to reuse read-once stream bodies.

The CVSS v4.0 rating assigns this vulnerability a base score of 8.9 (High Severity), reflecting the significant integrity impact on hosting systems. The vulnerability violates core sandbox isolation boundaries, allowing low-privilege script execution layers to corrupt state validation processes of high-privilege host runtimes.

Depending on how the hosting application integrates streams, this behavior has different concrete outcomes. If the application processes sensitive transactions, payload body validations, or authentication messages using streams, the integrity check bypass can allow an attacker to replay inputs, process malformed or previously closed data channels, or induce logic errors in the host's middleware handlers.

Due to the structural difficulty in defending V8-level proxy bridges from recurring symbol and prototype leaks, the overall integrity of the vm2 sandbox boundary is compromised, making it unsuitable for processing fully untrusted code.

The primary remediation strategy is upgrading the library to version 3.11.7 or higher. This release integrates the namespace-based symbol checks that block all registered symbols prefixed with nodejs. from crossing the proxy bridge.

However, because the vm2 library is deprecated and the maintainers have officially archived the project, the recommended long-term remediation strategy is to migrate away from vm2 entirely. Applications executing untrusted scripts must transition to process-isolated architectures, such as executing scripts in separate short-lived subprocesses confined by system-level permissions (e.g., Docker, seccomp, gVisor), or utilizing V8 isolates through libraries designed with out-of-process boundaries like isolated-vm.