Vm2 sandbox escapes expose the limits of promise sanitization

At a glance

What this is: Vm2’s latest critical flaw lets attackers escape the sandbox and run arbitrary code in the host Node.js process.

Why it matters: For teams running user-submitted code or other untrusted inputs, this turns sandbox design into an isolation and privilege question, not just a patching exercise.

By the numbers:

• Anyone who uses 3.10.1 or earlier should consider themselves affected.

👉 Read Semgrep's analysis of the vm2 sandbox escape and remediation path

Context

Vm2 sits in a narrow but important part of the application security stack: it is used to execute untrusted JavaScript while trying to contain the blast radius inside a Node.js process. The problem is that containment built on sanitization is brittle when the runtime itself can be coerced into exposing host capabilities. For identity and access practitioners, the key issue is that execution context becomes privilege context once isolation fails.

This article is really about the failure of a security model that assumes a sandbox can safely mediate hostile code paths after the fact. In practice, that assumption breaks down when promise handling or global scope behaviour creates a route around the guardrail. The starting position described here is not unusual for developer tooling that prioritises convenience before hard isolation.

The broader lesson aligns with NHI governance as well: any runtime that can invoke tools, handle secrets, or reach infrastructure should be treated as a privileged workload with explicit boundaries, not as an internal convenience layer.

Key questions

Q: What breaks when untrusted code runs inside a vm2 sandbox that relies on sanitization?

A: The boundary breaks when attacker-controlled code reaches host process capabilities through a sanitization bypass, because the sandbox shares the same Node.js process and inherits its privileges. At that point, the attacker can execute commands, inspect memory, or pivot into internal resources that were never meant to face untrusted input.

Q: Why does PQC planning matter to IAM and PAM teams?

A: Because authentication, privileged access, and workload trust all depend on cryptographic primitives that may need post-quantum replacement. IAM and PAM teams own many of the systems that will break first if trust assumptions are not mapped early. PQC is therefore an identity architecture issue, not only a cryptography issue.

Q: How do you know whether a code-execution sandbox is actually providing isolation?

A: Look for hard separation at the process, runtime, or container boundary, not just proxy-based sanitization. If hostile input can still inherit environment variables, filesystem access, or child process capabilities from the parent application, the sandbox is not truly isolated.

Q: Should organisations keep using vm2 for untrusted code after a critical escape flaw?

A: Only if they can prove the use case is low risk, tightly internal, and not exposed to arbitrary user input. For any public or semi-public execution path, the safer choice is to move to isolation-first design because repeated bypasses show that the model itself is fragile.

Technical breakdown

How promise sanitization fails in vm2

Vm2 uses JavaScript proxies and helper logic to constrain dangerous behaviour while untrusted code runs inside a host Node.js process. The flaw described in this article sits in the promise catch path, where a fail-open condition meant the sanitizer did not apply to global promise handlers. A malicious callback could be hoisted into global scope and reach constructors that unlock process execution. Once that happens, the sandbox is no longer a boundary, only an illusion of one.

Practical implication: treat sanitizer-based sandboxes as high-risk until they are paired with process-level isolation.

Why arbitrary code execution inside Node.js is so dangerous

When sandboxed code escapes into the host process, it inherits whatever permissions, environment variables, filesystem access, and network reach that process already has. In a Node.js application, that can mean reading in-memory values, spawning child processes, or reaching internal services that were never meant to face untrusted input. The issue is not just code execution. It is privilege inheritance from the application context to attacker-controlled code.

Practical implication: map every execution path to the privileges of the process that can reach it.

Why isolation is stronger than post-hoc sanitization

The article contrasts vm2’s model with isolation approaches that separate execution at the runtime or container boundary. Sanitization tries to clean dangerous behaviour after it appears, while isolation prevents untrusted code from sharing the same trust domain in the first place. That architectural difference matters because sanitization must anticipate every bypass, whereas isolation only needs to enforce a smaller, more explicit interface. For untrusted code, the latter is the safer pattern.

Practical implication: move untrusted execution to a separate runtime or container boundary rather than relying on proxy hooks alone.

Threat narrative

Attacker objective: The attacker aims to escape the sandbox and gain host-level code execution inside the Node.js process.

1. Entry occurs when a malicious user supplies code to a vm2-protected execution path that was assumed to be safely sandboxed.
2. Credential or capability access follows when a global promise handler bypasses sanitization and reaches host process constructors and internals.
3. Impact occurs when the attacker executes arbitrary Node.js commands with the privileges of the parent application process.

Breaches seen in the wild

• MITRE ATT&CK Enterprise Matrix — MITRE ATT&CK Enterprise — adversary tactics and techniques, threat detection, attack chain mapping, credential access, lateral movement, privilege escalation.
• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Sandbox sanitization is not a trust boundary. The article shows that a promise handler bypass can defeat local scope controls even when the application believes hostile code is contained. That is a governance failure as much as a technical one, because it places trust in code transformation rather than in hard separation. For practitioners, the lesson is that execution mediation is weaker than isolation when the workload is exposed to untrusted input.

Execution context becomes identity context once a sandbox fails. Any process that can invoke commands, reach secrets, or talk to internal services is effectively a privileged runtime, even if it was not designed as one. That makes this topic relevant to IAM and PAM teams as well as application security. Privilege must be evaluated at the process boundary, because the host process becomes the real identity once arbitrary code runs.

Architectural debt accumulates when teams keep patching an unsafe model. The article’s history of repeated advisories shows the difference between a one-off bug and a design that keeps reopening the same class of failure. Isolation gap: this is the specific failure mode the article illustrates, where a sandbox exists but the underlying runtime still allows hostile code to inherit host authority. For practitioners, the right conclusion is to redesign execution containment, not to assume another patch will close the class forever.

Untrusted-code platforms need lifecycle controls, not just exploit fixes. When applications allow user-provided scripts, the security question extends beyond the library version to offboarding, boundary review, and runtime segregation. That is especially relevant where code execution can touch credentials or internal APIs. The practical conclusion is to govern sandboxed execution as a privileged capability with explicit ownership and review.

This vulnerability reinforces the wider NHI principle that secrets and execution must be separated. If a runtime can access API keys, tokens, or service credentials, then a sandbox escape becomes an identity compromise as well as an application compromise. That makes runtime design part of NHI governance, not just developer ergonomics. Practitioners should assume that any shared trust domain will eventually be tested by an attacker.

From our research:

• 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, according to the Ultimate Guide to NHIs.
• Only 20% have formal processes for offboarding and revoking API keys, and even fewer have procedures for rotating them, according to the Ultimate Guide to NHIs.
• For a broader view of exposure patterns, see 52 NHI Breaches Analysis for real-world compromise patterns and root causes.

What this signals

Runtime isolation is now a governance question, not just a secure-coding question. As more applications execute untrusted or semi-trusted code, teams need to decide which workloads are allowed to share a process with attacker-controlled input. Where that runtime also touches credentials, the identity boundary has already been crossed, which is why NHI governance and application isolation increasingly overlap in the same risk review.

Sandbox escapes create a hidden privileged workload problem. A service that can execute code on behalf of users may also hold tokens, service credentials, or internal connectivity that no end user should inherit. That is where identity security becomes operational: treat the runtime as an identity-bearing component and separate it from the trust domain it serves.

The operational signal to watch is not only patch cadence but boundary design. Teams should measure how many code-execution paths still depend on shared-process models, and whether those paths can reach secrets or internal APIs. The more that answer is yes, the more likely a future bypass will become an identity incident rather than a simple application defect.

For practitioners

• Upgrade affected vm2 deployments immediately Move all installations using 3.10.1 or earlier to 3.10.2 and verify that dependency resolution does not leave older versions transitively installed in build or runtime paths.
• Replace sandbox-only designs for hostile code Where applications execute untrusted JavaScript, move that execution into a separate runtime or container boundary instead of relying on promise sanitization and proxy hooks inside the host Node.js process.
• Review every path that can reach secrets or internals Inventory whether the vm2 execution context can access environment variables, internal APIs, filesystem content, or child process execution, then remove those privileges from the hosting service account.
• Add detection for post-exploitation behaviour Monitor for unexpected child process creation, shell command patterns, and unusual outbound connections from services that run untrusted code, because arbitrary code execution changes the threat model immediately.

Key takeaways

• Vm2’s critical flaw shows that sanitization alone cannot be treated as a sandbox boundary when untrusted code can still reach the host Node.js process.
• A 9.8 CVSS escape in a widely used code-execution library turns runtime design into a privilege and identity problem, not just a patching problem.
• Practitioners should move untrusted execution to isolated runtimes or containers and remove secret-bearing privileges from any process that can be attacker-influenced.

Key terms

• Sandbox Escape: A sandbox escape is when code breaks out of its intended isolation boundary and gains access to host capabilities. In identity terms, it turns a constrained non-human execution path into a privileged runtime that can touch files, secrets, or downstream systems.
• Promise sanitization: Promise sanitization is the attempt to strip or control dangerous behaviour when JavaScript promises handle errors or callbacks. In practice, it is a defensive wrapper, not a hard boundary, and it fails if runtime behaviour or scope handling lets attackers route around the guardrail.
• Host process privilege: Host process privilege is the real level of access held by the application process that runs untrusted code. If sandboxed code escapes into that process, it can act with the same permissions, which is why process design matters as much as the library used for isolation.

What's in the full analysis

Semgrep's full post covers the exploit mechanics and remediation detail this post intentionally leaves for the source:

• The exact promise-catching bypass that lets unscoped callbacks escape local sanitization in affected vm2 versions
• Proof-of-concept code showing how arbitrary JavaScript reaches process execution inside the host Node.js runtime
• Version-specific remediation guidance for 3.10.2 and later, including how Semgrep users can scan dependencies
• Guidance on when isolated-vm or containerized execution is a better fit for untrusted user-submitted code

👉 Semgrep's full post covers the exploit path, affected versions, and safer isolation options

Deepen your knowledge

NHI Mgmt Group’s NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners translate identity controls into operational boundaries across modern security programmes.