External risk intelligence

Attacker can gain full control of applications using vm2, a Node.js sandbox

CVE advisorySeverity: CRITICAL (CVSS 9.1)

CVE-2026-44007

A critical flaw in the vm2 Node.js sandbox allows attackers with privileged access to run any command on your system. Update vm2 to version 3.11.1 immediately to prevent full system compromise.

3Halo Surface Signal

Vm2 Project Vm2

before 3.11.1

External exposure likelihood

Halo Surface Signal score for CVE-2026-44007

vm2 is a backend Node.js library for isolating untrusted code. It is not an inherently internet-facing service or appliance. Its network exposure depends entirely on the parent application. While often used in web-based environments that process untrusted user input, it remains a library component rather than a standalone network service with a default public-facing deployment pattern.

Horizon Alert

Summary of the vulnerability and why it matters

A critical vulnerability in the vm2 Node.js sandbox allows untrusted code to execute arbitrary commands on the host system. This issue arises when the sandbox is configured for nesting and can bypass security restrictions. Any application using vm2 with this configuration is fully compromised and should be updated immediately.

  • Allows arbitrary code execution.
  • Affects applications running untrusted code.
  • Requires existing access to the sandbox.

Attack Path

How an attacker could exploit the issue

An attacker with privileged access to a Node.js application using a vulnerable version of `vm2` can exploit this by creating nested virtual machines. The inner sandbox then bypasses security restrictions, allowing it to execute arbitrary operating system commands on the host. This effectively grants the attacker full control over the compromised system.

  • Requires privileged access.
  • Targets `vm2` sandbox with nesting enabled.
  • Unrestricted `require` in inner VM.

Live Threat

Current exploitation, exposure, and threat context

This vulnerability is highly concerning for applications using vm2 to sandbox untrusted code, as it allows for full host command execution by bypassing sandbox restrictions. Attackers would be motivated to weaponize this because it provides a direct path to compromise the underlying operating system. Exploitation requires authenticated access to the vulnerable application.

  • No public exploit code.
  • Vendor advisory exists.
  • KEV status is unknown.

Priority actions

Operational Fix

Recommended remediation, mitigation, and detection steps

Prioritize patching or upgrading vm2 to version 3.11.1 for any application running untrusted code within a NodeVM with nesting enabled. If immediate patching is not feasible, isolate affected services to prevent arbitrary OS command execution and potential host compromise.

  • Upgrade vm2 to 3.11.1.
  • Isolate services if patching is delayed.
  • Monitor for suspicious command execution.

Frequently asked questions

What is the primary function of the vm2 Node.js sandbox and what versions are affected by the vulnerability?

The vm2 Node.js sandbox is an open-source tool designed for isolating untrusted code. The vulnerability specifically affects versions of vm2 prior to 3.11.1 when a NodeVM is created with nesting enabled.

How does the vm2 vulnerability allow for arbitrary code execution, and what is the weakness class involved?

The vulnerability, classified as CWE-284 (Improper Access Control), allows sandbox code to unconditionally require 'vm2' even when outer VM require settings are restricted. This enables the sandbox to construct a new, unrestricted inner NodeVM and execute arbitrary OS commands on the host.

What is the trigger path for exploitation, and does it involve scope negation?

The trigger path involves creating a NodeVM with `nesting: true`. The sandbox code then bypasses the outer VM's `require` configuration to instantiate an inner NodeVM with its own unrestricted `require` settings, effectively negating the intended scope limitations.

What is the relevance of the vm2 vulnerability concerning the Halo Surface Signal, and what are the exploitation conditions?

The vm2 vulnerability has a 'Possible' relevance score from Halo Surface Signal because vm2 is a backend Node.js library and not inherently internet-facing. Exploitation requires authenticated access to a vulnerable Node.js application that uses vm2 with nesting enabled to execute arbitrary OS commands on the host.

What is the recommended practical response to mitigate the vm2 vulnerability, and what are the immediate actions if patching is delayed?

The practical response is to upgrade vm2 to version 3.11.1 or later for any application running untrusted code within a nested NodeVM. If immediate patching is not possible, isolate the affected services to prevent arbitrary OS command execution and monitor for any suspicious command activity.

References