CVE-2026-92957

vm2 through 3.11.6 does not normalize node:-prefixed builtin specifiers when evaluating user-supplied negative (deny) entries in a NodeVM wildcard require policy. Although NodeVM strips the node: prefix during require() resolution, negative wildcard entries are matched by exact string comparison against the canonical builtin names, so a policy such as new NodeVM({ require: { builtin: ['*', '-node:child_process'] } }) fails to deny the canonical child_process module. Sandboxed code can therefore obtain the host child_process builtin via require('child_process') or require('node:child_process'), gaining references to process-spawning APIs such as execSync and spawn, which is equivalent to host command-execution capability for untrusted sandbox code. Fixed in vm2 3.11.7.

vm2 through 3.11.6 does not normalize node:-prefixed builtin specifiers when evaluating user-supplied negative (deny) entries in a NodeVM wildcard require policy. Although NodeVM strips the node: prefix during require() resolution, negative wildcard entries are matched by exact string comparison against the canonical builtin names, so a policy such as new NodeVM({ require: { builtin: ['*', '-node:child_process'] } }) fails to deny the canonical child_process module. Sandboxed code can therefore obtain the host child_process builtin via require('child_process') or require('node:child_process'), gaining references to process-spawning APIs such as execSync and spawn, which is equivalent to host command-execution capability for untrusted sandbox code. Fixed in vm2 3.11.7.

Duplicate Advisory

This advisory has been withdrawn because it is a duplicate of GHSA-8686-vhfx-7r3j. This link is maintained to preserve external references.

Original Description

vm2 through 3.11.6 does not normalize node:-prefixed builtin specifiers when evaluating user-supplied negative (deny) entries in a NodeVM wildcard require policy. Although NodeVM strips the node: prefix during require() resolution, negative wildcard entries are matched by exact string comparison against the canonical builtin names, so a policy such as new NodeVM({ require: { builtin: ['*', '-node:child_process'] } }) fails to deny the canonical child_process module. Sandboxed code can therefore obtain the host child_process builtin via require('child_process') or require('node:child_process'), gaining references to process-spawning APIs such as execSync and spawn, which is equivalent to host command-execution capability for untrusted sandbox code. Fixed in vm2 3.11.7. (Suggested title: "vm2 before 3.11.7: NodeVM builtin deny-list bypass via node:-prefixed specifiers exposes child_process")

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:

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

does not deny the canonical child_process builtin. Sandboxed code can require both child_process and node:child_process, 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

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

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

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:

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 BUILTIN_MODULES:

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

BUILTIN_MODULES contains the canonical name child_process, not node:child_process. Therefore -node:child_process does not exclude child_process, 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 child_process builtin
• sandbox -> host process-spawning function references

Impact

Confirmed impact:

• require('child_process') succeeds inside the sandbox.
• require('node:child_process') 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 child_process 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.

'use strict';

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

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

  return vm.run(`
    const out = {};

    for (const spec of ['child_process', 'node:child_process']) {
      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:child_process']),
  denyCanonical:…

vm2 through 3.11.6 does not normalize node:-prefixed builtin specifiers when evaluating user-supplied negative (deny) entries in a NodeVM wildcard require policy. Although NodeVM strips the node: prefix during require() resolution, negative wildcard entries are matched by exact string comparison against the canonical builtin names, so a policy such as new NodeVM({ require: { builtin: ['*', '-node:child_process'] } }) fails to deny the canonical child_process module. Sandboxed code can therefore obtain the host child_process builtin via require('child_process') or require('node:child_process'), gaining references to process-spawning APIs such as execSync and spawn, which is equivalent to host command-execution capability for untrusted sandbox code. Fixed in vm2 3.11.7.

vm2 through 3.11.6 does not normalize node:-prefixed builtin specifiers when evaluating user-supplied negative (deny) entries in a NodeVM wildcard require policy. Although NodeVM strips the node: prefix during require() resolution, negative wildcard entries are matched by exact string comparison against the canonical builtin names, so a policy such as new NodeVM({ require: { builtin: ['*', '-node:child_process'] } }) fails to deny the canonical child_process module. Sandboxed code can therefore obtain the host child_process builtin via require('child_process') or require('node:child_process'), gaining references to process-spawning APIs such as execSync and spawn, which is equivalent to host command-execution capability for untrusted sandbox code. Fixed in vm2 3.11.7.