GHSA-8686-vhfx-7r3j: Critical severity npm/vm2 vulnerability

Summary

NodeVM normalizes node:-prefixed builtin specifiers during require() resolution, but it does not normalize user-provided negative builtin entries in wildcard policy.

As a result, this configuration:

js new NodeVM({ require: { builtin: ['', '-node:childprocess'] } });

does not deny the canonical childprocess builtin. Sandboxed code can require both childprocess and node:childprocess, and receives the host module with process-spawning APIs such as execSync and spawn.

The safe proof below only checks module and function reachability. It does not execute any OS command.

Affected Mode

NodeVM.

Affected Configuration

js new NodeVM({ require: { builtin: ['', '-node:childprocess'] } });

This affects users who deny builtins using their node:-prefixed spelling, expecting -node:childprocess to deny require('node:childprocess') and require('childprocess').

Affected Files / Functions

- lib/builtin.js - makeBuiltinsFromLegacyOptions - wildcard builtin expansion - exact negative entry check: builtins.indexOf(\-${name}\) - addDefaultBuiltin - lib/resolver.js - Resolver.resolve - lib/setup-node-sandbox.js - requireImpl - node: prefix stripping before builtin load

Root Cause

lib/setup-node-sandbox.js strips the node: prefix from resolved builtin filenames before loading the builtin:

js if (localStringPrototypeStartsWith(filename, 'node:')) { id = localStringPrototypeSlice(filename, 5); let nmod = cacheBuiltins[id]; if (!nmod) { nmod = loadBuiltinModule(id); if (!nmod) throw new VMError(Cannot find module '${filename}', 'ENOTFOUND'); cacheBuiltins[id] = nmod; } return nmod; }

But lib/builtin.js checks wildcard negative entries by exact string match against the names in BUILTINMODULES:

js if (builtins.indexOf(-${name}) === -1) { addDefaultBuiltin(res, name, hostRequire); }

BUILTINMODULES contains the canonical name childprocess, not node:childprocess. Therefore -node:childprocess does not exclude childprocess, and addDefaultBuiltin() registers the host builtin.

Security Boundary Crossed

Sandboxed code reaches a host builtin that the embedder attempted to deny.

Boundary crossed:

- sandbox -> host childprocess builtin - sandbox -> host process-spawning function references

Impact

Confirmed impact:

- require('childprocess') succeeds inside the sandbox. - require('node:childprocess') succeeds inside the sandbox. - The returned module exposes execSync and spawn as functions.

Worst confirmed impact is access to host process-spawning APIs. The proof does not execute any command.

The proof does not execute a command, but it confirms access to the host childprocess module and its process-spawning APIs. For untrusted sandbox code, this is equivalent to command execution capability.

Safe Local Reproduction

Tested on Node.js v24.14.0.

This proof only checks whether the module and dangerous functions are reachable. It does not spawn a process and does not run OS commands.

js 'use strict';

const { NodeVM } = require('./');

function probe(builtin) { const vm = new NodeVM({ require: { builtin } });

return vm.run( const out = {};

for (const spec of ['childprocess', 'node:childprocess']) { try { const cp = require(spec); out[spec] = { loaded: true, execSyncType: typeof cp.execSync, spawnType: typeof cp.spawn, moduleToStringTag: Object.prototype.toString.call(cp) }; } catch (e) { out[spec] = { loaded: false, name: e && e.name, code: e && e.code, message: e && e.message }; } }

module.exports = out; ); }

console.log(JSON.stringify({ nodeVersion: process.version, denyNodePrefixed: probe(['', '-node:childprocess']), denyCanonical: probe(['', '-childprocess']) }, null, 2));

Observed result:

json { "nodeVersion": "v24.14.0", "denyNodePrefixed": { "childprocess": { "loaded": true, "execSyncType": "function", "spawnType": "function", "moduleToStringTag": "[object Object]" }, "node:childprocess": { "loaded": true, "execSyncType": "function", "spawnType": "function", "moduleToStringTag": "[object Object]" } }, "denyCanonical": { "childprocess": { "loaded": false, "name": "VMError", "code": "ENOTFOUND", "message": "Cannot find module 'childprocess'" }, "node:childprocess": { "loaded": false, "name": "VMError", "code": "ENOTFOUND", "message": "Cannot find module 'node:childprocess'" } } }

Expected Secure Behavior

-node:childprocess and -childprocess should be equivalent.

If either spelling is denied, both of these should fail:

js require('childprocess') require('node:childprocess')

Suggested Fix

1. Canonicalize builtin names before allow/deny comparison: - Strip node: from user-provided builtin entries. - Preserve whether an entry is negative (-...) before canonicalizing. - Store and compare one canonical builtin key.

2. Apply the same normalization to: - wildcard negative entries - explicit allowlist entries - object-form builtin entries - mock/override keys if they are intended to support node: spelling

3. Add regression tests: - builtin: ['', '-node:childprocess'] blocks childprocess. - builtin: ['', '-node:childprocess'] blocks node:childprocess. - builtin: ['', '-node:fs'] blocks fs and node:fs. - builtin: ['', '-node:fs/promises'] and -fs/promises behave consistently. - Canonical dangerous builtins remain denied even if explicitly requested with node: spelling.