Description

vm2 through 3.11.6 contains a builtin-module denylist bypass in NodeVM. When the embedder uses the builtin wildcard together with negative entries (e.g. require: { builtin: ['*', '-fs', '-child_process'] }), negative entries are matched by exact module name in lib/builtin.js, so -fs removes only the builtin named fs and does not remove builtin subpaths such as fs/promises. Sandboxed code can therefore call require('fs/promises') or require('node:fs/promises') and reach the promise-based filesystem API despite fs being denied; node: prefix handling is likewise inconsistent (a -node:fs/promises entry does not block require('fs/promises')). Host file creation and writing were confirmed via fsp.writeFile(), and other fs/promises operations (cp, mkdir, rename, rm, rmdir, truncate, read operations, etc.) are also reachable. This issue is fixed in vm2 3.11.7.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.5",
  "pubDate": "2026-09-17T14:18:01.970Z",
  "pubdate": "2026-09-17T14:18:01.970Z",
  "executiveSummary": "The vm2 sandbox environment exhibits a security vulnerability involving the bypass of builtin module restrictions within NodeVM. This flaw exists in versions 3.11.6 and earlier.\nThe vulnerability arises from an inadequate denylist implementation in lib/builtin.js, where negative entries defined in the require configuration fail to account for subpath imports and node: prefix aliases.\nBy leveraging this logic error, an attacker can access restricted modules, such as fs/promises, even when the primary module (fs) is explicitly blocked in the sandbox configuration.\nThe impact is critical, as it allows for unauthorized host file system access, including arbitrary file creation, modification, and deletion. This effectively breaks the process isolation provided by the sandbox.\nExploitation requires the embedder to utilize the builtin wildcard configuration with negative module entries, a common pattern for sandboxing untrusted code. No specific authentication is required if the sandbox is exposed to malicious user-provided input.",
  "technicalDetails": "The vulnerability resides in the way NodeVM handles builtin module filtering logic within the library's internal configuration processing, specifically in lib/builtin.js. When a user defines a restricted environment using a configuration object like { builtin: ['*', '-fs', '-child_process'] }, the intention is to grant access to all builtin modules except those explicitly prefixed with a negative sign.\nThe root cause is an exact-match comparison logic applied during the resolution phase. When the sandbox checks if a module (e.g., fs/promises) should be allowed, it performs a check against the denylist. The current implementation interprets the '-fs' entry to mean that the exact identifier 'fs' is prohibited, but it fails to recursively resolve or normalize subpaths. Consequently, while the sandbox successfully blocks require('fs'), it ignores requests for require('fs/promises') or require('node:fs/promises').\nFurthermore, the logic for handling the 'node:' protocol prefix is inconsistent with standard Node.js module resolution. A negative entry defined as '-node:fs/promises' does not correctly correlate with a request for the non-prefixed 'fs/promises', leading to a scenario where attackers can pivot between different aliasing methods to evade the filter.\nThe attack flow proceeds as follows: 1. The embedder initializes NodeVM with a configuration that denies access to sensitive modules using the wildcard and negative entry syntax. 2. A malicious actor provides sandboxed code intended to interact with host resources. 3. The code calls require('fs/promises'), bypassing the denylist filter because the exact string does not match the restricted 'fs' entry. 4. Once the module is loaded into the sandbox context, the attacker gains access to the promise-based filesystem API. 5. Using functions like fsp.writeFile(), cp, or rm, the attacker performs unauthorized host file system operations.\nThis vulnerability effectively renders the NodeVM module denylist mechanism unreliable for enforcing security boundaries. The exposure of fs/promises allows an attacker to execute operations with the privileges of the Node.js process, potentially leading to remote code execution (RCE) via file manipulation or full system compromise."
}