CVE-2026-92933 in vm2
Summary
by MITRE • 09/17/2026
vm2 is a sandbox for running untrusted Node.js code. In versions <= 3.11.7, NodeVM exposes the host `util` module to the sandbox as an unfiltered shallow copy (`Object.assign({}, util)` in `defaultBuiltinLoaderUtil`), and the deprecated `sys` builtin (an alias of host `util`) is exposed through the generic builtin loader. On Node.js >= 22.9 this hands sandboxed code `util.getCallSites()`, a programmatic stack-introspection API that returns the host process's full call stack, including absolute file paths, function names, and line numbers for vm2 bridge internals and the embedding application's entrypoint. This bypasses the host-frame redaction introduced for GHSA-v27g-jcqj-v8rw, which only applies to the `Error.prepareStackTrace` formatting channel. The issue is fixed in vm2 3.11.8.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in versions of vm2 up to and including 22.9 represents a significant bypass of sandbox isolation mechanisms through improper handling of stack introspection APIs. Vm2 functions as a Node.js sandbox, designed to execute untrusted code within an isolated context that prevents access to the host environment's sensitive resources, such as file systems, network interfaces, and internal process data. The core security model relies on restricting what information can leak from the sandboxed execution context back into the host or other sandboxes. In this specific instance, the flaw lies in the exposure of the util.getCallSites() function to code running inside the sandbox. This API provides programmatic access to stack traces, which are critical for debugging but pose severe security risks when exposed to untrusted environments because they reveal internal implementation details and file system paths that should remain hidden from external actors.
The technical flaw stems from a gap in the redaction logic previously implemented to address earlier disclosure issues like GHSA-v27g-jcqj-v8rw. That prior fix focused exclusively on formatting channels, specifically targeting how Error.prepareStackTrace formats output for display purposes. However, it failed to account for programmatic access via util.getCallSites(). Consequently, when untrusted code invokes this API within the vm2 sandbox, it receives a full call stack from the host process rather than a sanitized or empty trace. This includes absolute file paths of internal bridge components and the entry point of the embedding application, along with function names and precise line numbers. By obtaining these details, an attacker can map the architecture of the hosting environment, identify specific modules loaded by the host, and potentially locate other vulnerabilities within those identified files based on their known characteristics or versions.
The operational impact of this vulnerability is substantial as it facilitates information disclosure that undermines the fundamental premise of sandboxing. An adversary exploiting this flaw gains visibility into the internal structure of the application running vm2. This intelligence can be used to craft more targeted attacks, such as path traversal exploits if relative paths are inferred from absolute ones, or logic bugs in specific modules identified by name and location. Furthermore, knowledge of line numbers allows for precise debugging of the host environment during exploitation attempts, increasing the reliability and speed of subsequent attack vectors. This level of access effectively breaks the isolation boundary, allowing code that should be confined to observe and potentially interact with the broader system context through indirect means derived from the leaked metadata.
This issue aligns with CWE-200, which covers Exposure of Sensitive Information to an Unauthorized Actor, as well as CWE-749, related to Exposed Dangerous Method or Function within a Sandbox Context. From a threat modeling perspective using MITRE ATT&CK techniques, this vulnerability supports the Reconnaissance phase by enabling information gathering about the target environment and potentially aids in Lateral Movement if the disclosed paths reveal other accessible services or configuration files on the host system. The remediation strategy involves upgrading to vm2 version 3.11.8 or later, where developers have corrected the oversight by ensuring that stack introspection APIs are properly sanitized regardless of whether they are accessed through error formatting channels or direct programmatic calls. Organizations relying on vm2 for executing untrusted scripts must prioritize this update to maintain the integrity of their sandboxing strategy and prevent potential information leakage attacks.