vm2 is an open source vm/sandbox for Node.js. Prior to 3.11.0, NodeVM's builtin allowlist can be bypassed when the module builtin is allowed (including via the '*' wildcard). The module builtin exposes Node's Module._load(), which loads any module by name directly in the host context, completely bypassing vm2's builtin restriction. This allows sandboxed code to load excluded builtins like child_process and achieve remote code execution. This vulnerability is fixed in 3.11.0.
Security readout for executives and security teams
Plain-English summary
Applications using vulnerable vm2 configurations may let untrusted sandboxed JavaScript escape its restrictions and run code on the host. Successful exploitation could expose data, alter systems, or disrupt services. The flaw affects vm2 versions before 3.11.0 when NodeVM permits the module builtin directly or through the '*' wildcard.
Executive priority
Treat confirmed exposed deployments as an urgent remediation item. Upgrade internet-facing or multi-tenant code-execution services first, then internal systems processing untrusted content. Where exposure prerequisites are absent, document that finding rather than assigning equal urgency. No active exploitation is established by the supplied sources.
Technical view
NodeVM's builtin allowlist is bypassed because the permitted module builtin exposes Node.js Module._load(). That loader resolves modules in the host context, allowing sandboxed code to access otherwise excluded builtins such as child_process. This breaks the sandbox boundary and can result in remote code execution with the hosting process's privileges.
Likely exposure
Exposure requires vm2 earlier than 3.11.0, use of NodeVM, permission for the module builtin explicitly or through '*', and execution of attacker-influenced JavaScript. Internet-facing services that evaluate user-supplied code have the greatest business risk. Deployments not meeting these conditions are not shown affected by the supplied evidence.
Exploitation context
The supplied record assigns CVSS 9.9 because exploitation is low-complexity, requires limited privileges, needs no user interaction, and crosses a security boundary. The bundle marks KEV false and provides no evidence of active exploitation. That absence does not prove exploitation has never occurred.
Researcher notes
The security boundary failure occurs through a host-context loader, not merely an incomplete list of allowed builtins. Assessment should therefore examine both resolved package versions and runtime NodeVM options. The record associates CWE-829 and CWE-863. The supplied material does not identify public exploitation, observed indicators, or affected downstream products beyond vm2 and referenced Red Hat packaging.
Mitigation direction
Upgrade vm2 to version 3.11.0 or later.
Prioritize systems that execute untrusted or externally supplied JavaScript.
Until upgraded, remove permission for the module builtin and avoid the '*' builtin wildcard.
Restrict affected application processes using least privilege and host-level isolation.
Follow applicable vendor guidance, including Red Hat advisories for packaged deployments.
Validation and detection
Inventory direct and transitive vm2 installations and record their resolved versions.
Confirm affected workloads use NodeVM rather than assuming every vm2 installation is exploitable.
Review NodeVM builtin configuration for module or '*' permissions.
Verify production deployments resolve vm2 version 3.11.0 or later.
Safely confirm sandboxed code cannot access excluded builtins after remediation.
Review telemetry for unexpected subprocess creation or commands originating from sandbox-hosting services.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-829: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
CWE-863: Authorization and privilege behavior lookup
Authorization weaknesses can support privilege escalation and valid-account review, depending on exploit path. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
The CVE wording references code or command execution, so execution technique review may help defensive triage. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
The CVE wording references privilege impact, so privilege escalation and authorization behavior review may help. This is a Glexia inferred lookup path, not an official MITRE, ATT&CK, or CVE Program mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
2CVSS vectors
5Timeline events
2ADP providers
6Source links
SSVC decision data
CISA-ADPCISA Coordinator
Timestamp
Version
2.0.3
Exploitation: pocAutomatable: noTechnical Impact: total
CVSS vector scores
2 official scores
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.