Summary
NodeVM blocks several dangerous Node.js builtins such as module, worker_threads, cluster, vm, repl, and inspector.
However, the denylist misses process and inspector/promises. Both can be used from sandboxed code to reach host-side execution primitives.
This allows sandboxed code to bypass the intended builtin restrictions and execute code in the host process.
Details
The dangerous builtin denylist is defined in lib/builtin.js. This list does not include:
process
inspector/promises
Non-denied builtins are exposed to the sandbox through:
builtins.set(key, special ? special : vm => vm.readonly(hostRequire(key)));
Because of this, sandboxed code can bypass the expected restrictions in two ways:
require('process').getBuiltinModule('child_process')reloadschild_process, even whenchild_processis excluded.require('inspector/promises')exposes the Inspector protocol and can callRuntime.evaluatein the host process.
PoC
Tested on:
vm2: 3.11.2
Node.js: v25.9.0
Run from the vm2 repository root:
node poc/dangerous-builtin-denylist-rce.js
dangerous-builtin-denylist-rce.js
The PoC first confirms the intended restrictions work:
require("inspector"): BLOCKED
require("child_process"): BLOCKED
Then it bypasses them:
require("process").getBuiltinModule("child_process").execFileSync(...)
This spawns a host child process. It also confirms:
require("inspector/promises").Session().post("Runtime.evaluate", ...)
This evaluates JavaScript in the host process.
Impact
An attacker who can run untrusted JavaScript inside NodeVM with affected builtin settings can escape the sandbox and execute arbitrary code in the host process.
This can lead to full compromise of the application process, including reading files, writing files, spawning processes, and accessing host environment secrets.
(This is not reachable with the default NodeVM configuration where require is disabled or no affected builtins are allowed. It affects applications that allow process, inspector/promises, or the wildcard "*" in require.builtin.)
CVE-2026-47140 has a CVSS score of 10.0 (Critical). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (3.11.4); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Remediation advice
Add process and inspector/promises to the dangerous builtin blocklist.
Also consider blocking dangerous builtin families by prefix, for example blocking both:
inspector
inspector/*
instead of only exact module names.
Frequently Asked Questions
- What is CVE-2026-47140? CVE-2026-47140 is a critical-severity security vulnerability in vm2 (npm), affecting versions <= 3.11.3. It is fixed in 3.11.4.
- How severe is CVE-2026-47140? CVE-2026-47140 has a CVSS score of 10.0 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of vm2 are affected by CVE-2026-47140? vm2 (npm) versions <= 3.11.3 is affected.
- Is there a fix for CVE-2026-47140? Yes. CVE-2026-47140 is fixed in 3.11.4. Upgrade to this version or later.
- Is CVE-2026-47140 exploitable, and should I be worried? Whether CVE-2026-47140 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-47140 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-47140? Upgrade
vm2to 3.11.4 or later.