vm2 sandbox escape shows how dependency trust can collapse

At a glance

What this is: This is an analysis of CVE-2026-22709 in vm2, a critical sandbox escape that lets attackers bypass Promise sanitisation and execute code on the host system.

Why it matters: It matters because application security teams, platform engineers, and IAM-aligned governance owners need to treat untrusted-code execution paths as high-risk trust boundaries, especially where third-party packages mediate runtime privilege.

By the numbers:

• The vulnerability affects vm2 version 3.10.1 and earlier, with patched versions beginning at 3.10.2.

👉 Read StepSecurity's analysis of CVE-2026-22709 in vm2

Context

A sandbox is supposed to contain untrusted code so it cannot reach the host runtime, file system, or network controls beyond its intended boundary. CVE-2026-22709 shows how that boundary can fail when callback sanitisation is incomplete and dependency-specific object behaviour is not consistently handled.

For identity and access governance, the deeper issue is trust delegation inside application runtimes. When code execution escapes a sandbox, the attacker inherits whatever permissions the host process already holds, which turns an application security bug into a privilege and exposure problem that identity teams also need to understand.

This pattern is not unusual for JavaScript supply-chain and runtime isolation failures, where object wrappers and asynchronous flows create subtle control gaps that are hard to reason about without tight dependency management.

Key questions

Q: What fails when a JavaScript sandbox escape vulnerability is present?

A: The containment model fails, which means untrusted code can move from an isolated runtime into the host process context. Once that happens, the attacker may inherit access to secrets, environment variables, files, and internal services that were never intended for the sandboxed code. The key failure is not just code execution, but loss of the trust boundary that the sandbox was supposed to enforce.

Q: Why do browser extensions matter to identity and access governance?

A: Browser extensions matter because they are delegated software identities operating inside a user trust context. They can influence what the user sees, what they download, and what code reaches the endpoint. That makes them part of the access plane, especially when browser activity is tied to business systems and sensitive workflows.

Q: How do security teams know whether sandbox controls are actually working?

A: They know by testing for alternate expressions of the same action, not by checking whether one blocked syntax case still fails. A sandbox is weak if template literals, reflective APIs, indirect property writes, or call arguments can still produce the same privileged effect. The right signal is whether equivalent behaviour is contained across different language forms.

Q: What should teams do when a sandbox library is found vulnerable in production?

A: Contain the affected workloads, upgrade the library version, and verify that no transitive dependency reintroduces the vulnerable code path. Then review the runtime privileges of the affected service so a future escape cannot immediately reach sensitive data or control planes. That sequence limits blast radius before the patch is fully absorbed across environments.

Technical breakdown

How Promise sanitisation breaks sandbox containment

vm2 is designed to run untrusted JavaScript inside a constrained execution context. In this case, the flaw sits in how Promise callbacks are sanitised. The library sanitises the callback on localPromise.prototype.then, but the async function return path produces a globalPromise object that does not receive equivalent treatment. That mismatch creates a bypass path. Once the attacker can influence Promise.prototype.then or catch behaviour through the unsanitised object path, the sandbox loses its ability to prevent host-level execution.

Practical implication: treat sandbox libraries as part of your trust boundary and test object-handling edge cases before allowing untrusted execution.

Why sandbox escape becomes host-level code execution

A sandbox escape matters because the sandbox is not the security objective by itself. The objective is preventing untrusted code from inheriting host privileges. When an escape succeeds, the attacker is no longer limited to the package’s internal guardrails. They can execute arbitrary code in the host process context, which may include access to environment variables, local files, secrets, internal APIs, and downstream build or deployment workflows. In other words, the sandbox stops being a control and becomes only a speed bump.

Practical implication: assume host secrets and runtime permissions are exposed the moment sandbox containment fails.

Dependency governance for runtime isolation libraries

Sandbox libraries create a hidden dependency on precise versioning, patch discipline, and transitive package visibility. Because vm2 is often embedded deep inside application stacks, teams may not know where it is present until a vulnerability lands. The control challenge is not only upgrading one package. It is establishing inventory, transitive dependency discovery, and policy around where untrusted-code execution is allowed at all. That is a classic governance problem, even when the technical failure is in application code.

Practical implication: maintain transitive package inventory and restrict untrusted-code execution to explicitly approved, monitored environments.

Threat narrative

Attacker objective: The attacker wants host-level code execution inside an environment that was supposed to be isolated for safe untrusted-code handling.

1. Entry occurs when an attacker supplies untrusted JavaScript to an application that uses vm2 to isolate execution.
2. Credential or privilege boundaries fail when Promise sanitisation is bypassed through the globalPromise path, allowing the sandbox to be escaped.
3. Impact follows as the attacker executes arbitrary code on the host system and can potentially reach secrets, internal services, or deployment tooling.

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.
• Gravity SMTP CVE-2026-4020 API Keys Exposure — CVE-2026-4020 in Gravity SMTP exposes API keys via single HTTP request across 100,000 WordPress sites.

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 escape is a trust-boundary failure, not just a library bug. When a runtime isolation layer collapses, the attacker inherits the host process context and every permission that comes with it. That means the real control failure is not only code execution, but the assumption that untrusted code can be safely contained by default. For practitioners, the lesson is to treat sandboxing as a governed trust boundary that must be validated, monitored, and limited in scope.

Runtime containment failures now intersect with identity governance because host privileges matter the moment escape succeeds. A sandbox escape can expose secrets, API keys, service tokens, and internal credentials already available to the running process. That creates an identity problem inside an application security incident, because the blast radius depends on what the workload identity can reach. Practitioners should therefore review both code-execution controls and the privilege profile of the runtime itself.

Transitive dependency visibility is the named governance gap this vulnerability exposes. Teams often know they use a package, but not where it sits in the transitive tree or which services still depend on an affected version. This is a form of hidden trust debt, where security assumptions exist longer than inventory accuracy does. The practical conclusion is to pair software composition analysis with runtime policy so containment is not assumed from package names alone.

Untrusted-code execution should be treated as a special-case architecture, not a general-purpose convenience. If an application regularly evaluates third-party code, templates, or plugins, then the security model must include explicit privilege separation, constrained host access, and rapid patch handling. Otherwise, one sandbox flaw becomes a systemic exposure path. For practitioners, the answer is to reduce where untrusted execution is allowed and raise the controls around any remaining use cases.

OWASP-style secure dependency governance should be extended into runtime isolation decisions. Package vulnerability management is necessary but not sufficient when the package itself is a containment control. The relevant question is whether the organisation can detect where sandboxing libraries exist, how quickly patching happens, and what privileges the host process holds. For practitioners, that means aligning application security and identity controls around the same trust boundary.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• From our research: 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• That visibility gap becomes more dangerous when runtime trust is already thin, which is why teams should pair application containment with The 52 NHI breaches Report and identity lifecycle controls.

What this signals

Hidden trust boundaries are now a programme-level risk. A component such as vm2 can look like a technical safeguard while still becoming the weakest control in the chain if its object handling is incomplete. Security teams should therefore assess where they are relying on library-level containment to protect workload identity, secret exposure, or runtime privilege.

A practical response is to join software inventory, runtime restrictions, and identity governance into one view of exposure. When a vulnerable sandbox can inherit host privileges, the issue is not isolated to application security, because the blast radius is shaped by what the service account or workload token can reach. Teams that cannot see that boundary will struggle to prioritise remediation effectively.

For identity-led programmes, the lesson is to stop treating host credentials as safe simply because execution is sandboxed. An escaped runtime can still reach workload secrets, and that means secret scoping, token lifespan, and process isolation all need to be reviewed together.

For practitioners

• Patch vm2 immediately Upgrade all affected installations to vm2 3.10.2 or later, then verify the deployed version in every application and container image that may embed the library.
• Inventory transitive usage of vm2 Search repositories and build outputs for vm2 as a direct or transitive dependency so you can find services that do not declare it explicitly.
• Reduce host privilege for sandboxed workloads Run untrusted-code execution paths with minimal filesystem, network, and environment access so a successful escape cannot immediately reach secrets or internal systems.
• Add runtime containment checks to security reviews Treat any component that executes untrusted code as a special review item in architecture and change management, with explicit approval for where it is allowed to run.

Key takeaways

• CVE-2026-22709 shows that a sandbox escape is a trust-boundary collapse, not a narrow code defect.
• StepSecurity rates the issue critical at CVSS 9.8, and vm2 3.10.1 and earlier are affected.
• The most effective limiters are rapid patching, transitive dependency visibility, and tighter runtime privilege scoping.

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.
• Transitive Dependency: A transitive dependency is a package that your application uses indirectly through another package. It matters because security teams may not see it in application code, yet it can still introduce critical vulnerabilities, broaden the attack surface, or carry runtime behaviour that affects trust and containment.
• Metadata Trust Boundary: A metadata trust boundary is the line between tool content that can be safely consumed and tool content that must be validated before use. For agentic systems, descriptions, examples, and schemas are security-relevant inputs because they can influence decisions and trigger actions with real-world impact.

What's in the full analysis

StepSecurity's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact Promise sanitisation path in vm2 3.10.1 and earlier that allows the bypass
• Version-specific remediation details for upgrading to 3.10.2 or later across npm-managed environments
• Practical package search guidance for finding direct and transitive vm2 usage in real repositories
• References to the GitHub Security Advisory and release commits for validation

👉 The full StepSecurity post covers the sandbox escape path, affected versions, and remediation steps.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management. It helps practitioners connect application runtime risks to the identity controls that shape blast radius.