All articles
Threat IntelligenceMay 2026·3 min read

vm2 Sandbox Escape Flaw Threatens Agentic Code Execution

A critical vulnerability in the popular vm2 sandboxing library allows untrusted code to escape and execute commands, posing a severe risk to AI agent platforms.

vm2 Sandbox Escape Flaw Threatens Agentic Code Execution
Illustration generated by Helixar Research Labs. Not a depiction of a real system, attack, or affected product.

At a Glance

CVE-2026-44007

Identifier

Critical

Severity

Local Code Execution

Attack Vector

vm2

Affected Product

A critical vulnerability in the vm2 Node.js sandboxing library allows untrusted code to bypass security restrictions and execute arbitrary commands on the host operating system. The flaw, tracked as CVE-2026-44007, represents a full sandbox escape. It affects any application that runs untrusted code inside a NodeVM with the `nesting: true` option enabled [1].

The Agentic Threat Surface

This vulnerability poses a significant threat to the growing ecosystem of AI-powered agentic systems. These systems often rely on sandboxes like vm2 to safely execute code generated by Large Language Models or fetched from external tools. The security of the entire agentic platform depends on the integrity of this sandbox boundary.

A successful exploit means an attacker can break an agent out of its intended confines. A malicious prompt or a compromised tool in an agent's workflow could be used to trigger the vulnerability. This would allow the agent to gain control of the underlying host, exfiltrate data, and move laterally across the network.

Attack Chain: From Sandbox to Shell

The attack exploits a logical flaw in how vm2 handles configuration options. An attacker's goal is to execute code within a NodeVM that was configured by a host application. The host developer may have set `require: false` to prohibit module loading, believing this creates a secure environment.

The exploit begins when the sandboxed code executes `require('vm2')`. Despite the `require: false` configuration, this call succeeds when `nesting: true` is also active. This happens because the nesting feature incorrectly injects the `vm2` module itself into the sandbox's scope, overriding the broader security policy.

Once the sandboxed code has access to the `vm2` module, it can act as a host itself. The code then creates a new, inner `NodeVM` instance. Crucially, this inner sandbox is configured with the attacker's desired permissions, such as enabling access to the `child_process` module.

The final step is to run code inside this new inner sandbox. The attacker executes a command, such as `id` or a reverse shell, using `child_process.execSync`. The command runs with the permissions of the original host process, achieving a complete sandbox escape and host compromise.

OPERATOR ACTION

Review all vm2 instances for the use of 'nesting: true' and update to a patched version or disable the option.

Root Cause: A Flawed Logic Override

The technical root cause is an unsafe interaction between the `nesting: true` option and the module resolution logic. When nesting is enabled, the library injects a special `NESTING_OVERRIDE` object into the resolver. This object is meant to facilitate creating nested VMs, but it unconditionally adds `vm2` as an available module.

This override takes precedence over other security settings. The code path that should enforce `require: false` by returning a `DENY_RESOLVER` is never reached when `nesting: true`. Instead, a resolver is created that explicitly allows `require('vm2')`, silently defeating the developer's expressed intent to block all modules [2].

The mental model mismatch is the core danger. A developer setting `require: false` has a reasonable expectation that no modules can be loaded. The existing documentation for the nesting feature did not sufficiently warn that it would completely invalidate this fundamental security control.

Mitigation and Defense-in-Depth

The vm2 maintainers have released a patch addressing the vulnerability. Administrators and developers should upgrade to version 3.11.1 or a later release to fix the issue. This is the most effective and recommended mitigation [3].

If updating immediately is not feasible, a thorough code audit is necessary. Search for all `NodeVM` instantiations that use the `nesting: true` option. If this option is used to run untrusted code, it must be disabled as a temporary workaround.

This incident underscores the fragility of software-based sandboxing. Teams building agentic systems must adopt a defense-in-depth posture. Do not rely solely on a single library for containment. Consider running high-risk agentic workloads in hardened, OS-level containers or micro-VMs with strict network policies and minimal privileges.

References

  1. GitHub Security Advisory (GHSA-8hg8-63c5-gwmx). https://github.com/advisories/GHSA-8hg8-63c5-gwmx (accessed 2026-05-07).
  2. Vendor security advisory (github.com). https://github.com/patriksimek/vm2/security/advisories/GHSA-8hg8-63c5-gwmx (accessed 2026-05-07).
  3. github.com. https://github.com/patriksimek/vm2/releases/tag/v3.11.1 (accessed 2026-05-07).

About Helixar Research Labs

Helixar is an AI-native software R&D lab focused on agentic governance, compliance, and security for enterprises and enterprise agents.

Helixar Research Labs publishes briefings on the agentic and AI threat surface, including autonomous agents, LLM tooling, MCP servers, model supply chains, and prompt injection. The goal is to surface the gap between traditional defenses and agentic attacks before it shows up in your incidents.

If you run agents in production, this is for you. Learn more at helixar.ai.

Back to Press