CVE-2026-92948: Sandbox Escape and Remote Code Execution in vm2 via node:test

The vm2 library is a widely utilized Node.js library designed to run untrusted code in a sandboxed virtual machine environment. To prevent untrusted scripts from accessing the host file system, network, or process spawning APIs, vm2 intercepts module resolution. It implements a strict blocklist of core Node.js modules, categorizing them as dangerous and preventing their import.

Historically, standard system administrative modules such as fs, child_process, and cluster were explicitly blocked. However, the introduction of the stable native test runner (node:test) in modern Node.js versions introduced a new attack surface. This testing module is capable of launching separate process-isolated host tasks, which can be manipulated to achieve host-realm code execution.

When vm2 runs on Node.js version 24 or newer, the module loading mechanism fails to correctly normalize prefixes. By providing a double-prefixed import string, an attacker can bypass the signature-based verification blocks. This exposes the unconstrained native node:test API directly inside the virtual environment.

The root cause lies in how vm2 attempts to prevent bypasses involving the node: scheme prefix. Node.js allows core modules to be imported using the node: prefix, such as require('node:fs') instead of require('fs'). To address this, the vm2 module loader in lib/setup-node-sandbox.js stripped a single instance of the node: prefix before performing validation against the list of dangerous builtins.

An attacker can supply a module specifier string with two prefixes, such as node:node:test. When parsed, the validation mechanism only removes the first prefix, leaving node:test to be processed. The validator incorrectly assumed that any remaining string after one stripping operation would either be a non-builtin or would fail native resolution.

vm2 does not process nested prefixes recursively, which is the core architectural flaw. The native Node.js resolver is highly permissive and successfully resolves node:node:test to the underlying node:test module. Because node:test was not defined within the DANGEROUS_BUILTINS blocklist in vulnerable versions, the import is allowed. The sandbox is then provisioned with a direct proxy to the host's actual test execution context.

An analysis of the vulnerability before the release of version 3.11.7 reveals that the normalization function was vulnerable to nested prefix evasion. The original code only performed a single prefix check:

// Vulnerable prefix normalization logic
function isDangerousBuiltin(key) {
	if (typeof key !== 'string') return false;
	if (key.startsWith('node:')) key = key.slice(5);
	if (DANGEROUS_BUILTINS.has(key)) return true;
	const slash = key.indexOf('/');
	if (slash > 0 && DANGEROUS_BUILTINS.has(key.slice(0, slash))) return true;
}

To remediate this, commit 415339f698f0d52d3c5ad358b12b79c8072d5b4b modified the function to run a recursive while loop. This design modification ensures that all nested or repeated instances of the node: prefix are stripped before the blocklist validation occurs:

// Patched prefix normalization logic
function isDangerousBuiltin(key) {
	if (typeof key !== 'string') return false;
	// Strip ALL leading node: prefixes recursively
	while (key.startsWith('node:')) key = key.slice(5);
	if (DANGEROUS_BUILTINS.has(key)) return true;
	const slash = key.indexOf('/');
	if (slash > 0 && DANGEROUS_BUILTINS.has(key.slice(0, slash))) return true;
}

Additionally, the developers appended test to the DANGEROUS_BUILTINS set in lib/builtin.js. This ensures that even if the prefix is bypassed, the test runner module is blocked by default.

Exploitation requires that the host application runs vm2 on Node.js version 24+ and configures the sandbox to permit the node:test module or use a wildcard allowlist. Once inside the sandbox, the attacker cannot import fs or child_process directly as those are strictly blocked. Instead, the attacker issues a request for the double-prefixed node:node:test module.

After successfully loading the node:test module proxy, the attacker invokes the test.run() method. This API supports process-isolated test execution and is executed directly within the host context, rather than the VM context. The API accepts an options object containing the execArgv array, which specifies command-line arguments to be forwarded to the child process.

By supplying the --eval command-line flag inside execArgv, the attacker instructs the spawned host Node.js process to execute arbitrary JavaScript. This execution occurs outside the sandbox boundaries, running with the full privileges of the parent process.

The security impact of CVE-2026-92948 is critical, resulting in complete host compromise. Successful exploitation bypasses all security controls implemented by the virtual machine environment. The attacker gains the ability to execute arbitrary code, modify host files, and establish reverse shells, effectively running commands as the user operating the parent Node.js application.

The vulnerability is tracked under CVSS v3.1 with a base score of 9.9. The vector string is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, highlighting that the scope has changed (S:C), meaning the exploitation of the sandbox directly affects the security of the host system.

The EPSS score is currently evaluated at 0.00654, which suggests low active exploitation in widespread campaigns, but public proof-of-concept availability raises the likelihood of targeted exploit attempts. This vulnerability represents a complete failure of the primary protection mechanism (CWE-693) of the sandbox.

The primary remediation path is to upgrade the vm2 dependency to version 3.11.7 or later. This version contains the recursive prefix stripping update and blocks the test module globally. However, because the vm2 project is officially deprecated and is no longer actively maintained, users should migrate to modern alternative sandbox architectures.

For robust isolation, applications should migrate to isolated-vm. This library runs untrusted scripts in separate V8 isolates, providing strong isolation and preventing access to Node.js builtins. Alternatively, running untrusted code in containerized environments, such as Docker or gVisor, ensures that sandbox escapes do not result in a compromise of the underlying host operating system.

If immediate software upgrading is not possible, the sandbox configuration must be modified. Explicitly remove any wildcard allowlists, such as builtin: ['*']. Ensure that only strictly necessary, non-dangerous builtins are permitted within the NodeVM instantiation parameters.