GHSA-647f-g98j-qq25: Code Injection
Summary
Untrusted JavaScript run by vm2 can escape the sandbox and execute arbitrary commands in the host Node.js process when an embedder-exposed host Promise rejects. This is an incomplete fix for GHSA-m283-3h24-438v: the advisory's capability-bearing rejection rebuild runs only through this direct Promise-handler path, so call/apply indirection bypasses the protection it introduced. The bridge sanitises host rejection values before sandbox callbacks run, but the gate at lib/bridge.js:1624 identity-checks only the direct call target. Registering the rejection handler through Function.prototype.call indirection, 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 the sandbox (lib/bridge.js:1639) without the rebuild that strips host references carried by its own properties (lib/setup-sandbox.js:2104). A rejection error whose own property references a powerful host object, for example err.detail = process, therefore reaches sandbox code as a fully functional proxy, and e.detail.mainModule.require('childprocess').execSync(...) executes with host privileges. The .apply form and a stacked call.call behave identically.
PoC
Save as poc.js and run node poc.js:
js const { VM } = require('vm2'); const vm = new VM({ sandbox: { fetchUser: async () => { const err = new Error('db connection failed'); err.detail = process; // embedder-attached host reference throw err; }, }}); vm.run( const p = fetchUser(1); // proxy of the host Promise p.then.call(p, undefined, (e) => { // .call indirection skips the sanitiser e.detail.mainModule.require('childprocess') .execSync('echo vm2-escape-proof > /tmp/poc.proof'); }); );
Observed output
shell $ cat /tmp/poc.proof vm2-escape-proof
Registering the same callback directly, p.then(undefined, cb), strips detail and no command runs; the bind and Reflect.apply forms are sanitised as well, isolating the bypass to call and apply indirection.
Impact
Any deployment that evaluates attacker-controlled code with vm2 and exposes a host-realm Promise to the sandbox is affected: an async host function bridged through the sandbox option, or a NodeVM external module's async method. If that Promise rejects with an Error carrying a non-primitive own property that references a host object, a diagnostic pattern the vm2 codebase itself documents as routine for Node libraries (lib/setup-sandbox.js:1877), a single submission yields arbitrary command execution in the host process with the host account's privileges, including file read and write, process spawning, and network access. In a multi-tenant service evaluating untrusted code, one submission compromises the worker process and every tenant it serves.
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
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments that use vm2 to run untrusted JavaScript and expose a host Promise that can reject are exposed. Exploitation depends on the rejected host error carrying an own property that references a powerful host object, such as process.
What does an attacker need to do to exploit this?
The attacker needs sandbox code that registers a Promise rejection handler through Function.prototype.call or apply indirection rather than the direct Promise-handler path. This bypasses the bridge identity check and can deliver the unsanitized host rejection value to sandbox code.
What is the impact if exploitation succeeds?
Sandbox code can access the host object carried by the rejection error and use it to execute arbitrary commands in the host Node.js process. The example provided reaches child_process through process.mainModule.require and invokes execSync.
How can I identify a potentially vulnerable integration?
Review host-to-sandbox Promise interactions for rejected Promises whose error objects have own properties referencing host-capable objects. Also look for sandbox-controlled rejection handlers registered through patterns such as p.then.call(p, undefined, cb) or equivalent apply-based indirection.