TL;DR: A critical vm2 flaw in versions 3.10.1 and earlier lets attackers bypass Promise sanitisation and execute arbitrary code on the host, with StepSecurity citing a CVSS 9.8 severity and urging immediate upgrade to 3.10.2 or later. The real lesson is that sandbox boundaries are only as strong as their object handling and dependency governance.
At a glance
What this is: StepSecurity says a critical vm2 sandbox escape lets attackers bypass Promise sanitisation and run arbitrary code on the host.
Why it matters: It matters because teams using sandboxed execution for untrusted code need to treat dependency trust, object handling, and transitive package exposure as governance issues, not just patching tasks.
Context
A JavaScript sandbox only works if it consistently contains untrusted code across every object path and callback pattern. In vm2, the control failure sits in Promise handling, where sanitisation does not apply evenly to all promise objects, so the isolation boundary can collapse even though the library is intended to enforce it.
For IAM and NHI practitioners, the governance lesson is broader than application security: any platform that executes untrusted code inside a controlled boundary depends on trustworthy dependencies, precise runtime enforcement, and clear ownership of upgrade decisions. The article is a reminder that containment assumptions are often weaker than teams believe until a single library flaw turns them into host-level execution.
The issue is therefore not only a software defect but a trust boundary defect. Once the sandbox boundary fails, the surrounding access model no longer matters because the attacker has moved from constrained execution to host compromise.
Key questions
Q: What breaks when a JavaScript sandbox fails to sanitise all Promise paths?
A: The entire containment model breaks, because untrusted code can cross from restricted execution into host-level execution through the unsanitised path. In practice, that means the sandbox no longer limits what attacker-controlled code can access, and the issue becomes arbitrary code execution rather than a confined runtime error.
Q: Why do sandbox escapes create risk even when the vulnerable package is only a dependency?
A: Because the security boundary is enforced by the dependency itself. If that library is present anywhere in the execution path, a flaw in its isolation logic can affect the application regardless of whether developers imported it directly or inherited it through a transitive package.
Q: What signs suggest an untrusted-code execution control is failing in practice?
A: The clearest signs are inconsistent behaviour across runtime object types, unexpected access outside the intended sandbox, and package inventories that cannot confirm which projects still depend on the vulnerable library. If the control cannot be verified at runtime and in the bill of materials, it is not trustworthy.
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
Promise sanitisation bypass in vm2
vm2 is designed to wrap untrusted JavaScript so code can run with restricted access to the host. In the vulnerable versions, Promise.prototype.then and Promise.prototype.catch are not sanitised consistently across local and global Promise objects. Because async functions return a globalPromise, an attacker can use that mismatch to pass an unsanitised callback through the sandbox boundary. The result is not a logic bug in the script being executed, but a failure in the isolation mechanism that should contain it.
Practical implication: Treat sandbox boundary enforcement as a security control that needs direct validation, not just a dependency version check.
Why object handling is the real attack surface
Sandbox escapes often succeed where framework assumptions about object identity, prototype chains, or callback wrapping do not hold uniformly. vm2 shows how a small difference between local and global object handling can undo the intended isolation model. That makes object handling a governance issue as much as a code issue, because the security outcome depends on every path through the runtime behaving the same way. If one path is missed, the sandbox no longer provides the trust separation it claims.
Practical implication: Review any runtime that executes untrusted code for inconsistent object wrapping, especially around promises, callbacks, and async returns.
Dependency trust and transitive exposure
A sandbox library sits inside the application supply chain, so trust in the execution boundary is partly trust in the library version, patch state, and usage pattern. When a dependency like vm2 is embedded in multiple projects, the exposure extends beyond direct package installs to indirect and transitive usage. That creates a different control problem from ordinary vulnerability management: teams need to know where the sandbox is used, whether it is still needed, and whether the patched version has actually replaced every vulnerable instance.
Practical implication: Map every direct and transitive use of the sandbox library before assuming the patch has fully closed the exposure.
Threat narrative
Attacker objective: The objective is to break out of the sandbox and execute attacker-controlled code on the host system.
- Entry occurs when an attacker supplies untrusted JavaScript to an application that relies on vm2 for containment.
- Credential_harvested is not the issue here; instead, the attacker abuses inconsistent Promise sanitisation to cross the sandbox boundary.
- Escalation follows when the escaped code executes with host-level privileges outside the intended isolation layer.
- Impact is arbitrary code execution on the host system, defeating the sandbox's core security purpose.
Breaches seen in the wild
- tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Dependency trust collapses the moment a sandbox library stops enforcing boundaries uniformly. vm2 is meant to isolate untrusted code, but inconsistent Promise sanitisation shows how a single missed object path can invalidate the whole trust model. For practitioners, the key point is that containment controls must be validated at the runtime boundary, not inferred from the library's purpose.
Sandbox escape is a governance failure before it is a code defect. Teams that rely on untrusted-code execution often treat the sandbox as a technical detail owned by application developers. In reality, it is a shared security boundary with supply-chain, patching, and ownership implications, so the control failure is unmanaged trust in a dependency that can no longer be assumed safe.
Promise boundary inconsistency is the named failure mode this vulnerability exposes. The article shows that local and global Promise handling do not receive identical sanitisation, which means security depends on object provenance inside the runtime. That is a precise failure mode practitioners should track because it explains why some sandbox escapes survive even when the sandbox appears to be in place.
Transitive dependency exposure turns a single sandbox flaw into a programme-level risk. If vm2 appears through indirect package use, security teams may not see it in their primary bill of materials or review cycle. That makes discovery and ownership as important as patching, because a control that is not inventory-aware will miss the very library that enforces the boundary.
This vulnerability reinforces that untrusted code execution needs explicit containment assurance, not just intent. If a team cannot prove where sandboxing is used, how it is patched, and whether runtime behaviour matches the design, then the boundary is only nominal. Practitioners should treat sandbox libraries as high-risk trust anchors and govern them accordingly.
What this signals
Promise boundary inconsistency should be treated as a class of control failure, not a one-off bug. Security teams that run untrusted code inside application processes need to assume that the weakest object path defines the effective boundary. That means runtime validation must accompany package patching, because version hygiene alone does not prove containment.
Sandbox governance now belongs in dependency risk management. The practical question is no longer whether a package can isolate untrusted code in theory, but whether the organisation can locate every instance, confirm the patched version, and retire unnecessary use. That makes inventory fidelity and ownership the deciding controls for this class of exposure.
Containment assurance must move closer to execution time. If a sandbox can be bypassed through object handling, then architectural trust in the library is insufficient on its own. Practitioners should pair dependency governance with runtime tests that validate the exact execution paths their applications depend on.
For practitioners
- Inventory every vm2 deployment and transitive dependency Locate all direct and indirect uses of vm2 across repositories, build pipelines, and runtime images, then confirm whether any instance remains on 3.10.1 or earlier.
- Upgrade to the patched vm2 release immediately Move affected systems to vm2 3.10.2 or later and verify the installed version after deployment rather than assuming the package manager resolved every instance.
- Review whether sandboxing is still necessary Remove vm2 from workflows that no longer require execution of untrusted code, because every unused sandbox expands the attack surface and patch burden.
- Test isolation assumptions in runtime code paths Validate that Promise handling, async returns, and callback wrapping behave consistently under the exact execution patterns your application uses for untrusted inputs.
Key takeaways
- Vm2's sandbox escape shows that untrusted-code containment fails when Promise handling is inconsistent across runtime object types.
- The exposure matters because a sandbox flaw turns dependency trust into host-level execution risk, even when the package is only indirectly used.
- The most effective control is to inventory every instance, upgrade the vulnerable version, and validate that the sandbox still enforces isolation in practice.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 and MITRE ATT&CK address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP API Security Top 10 | API8 — Security Misconfiguration | The article centres on a runtime security boundary failing through inconsistent sanitisation. |
| Recommendation — Review sandbox runtimes for misconfiguration and inconsistent enforcement paths before treating them as trustworthy controls. | ||
| MITRE ATT&CK | TA0001;TA0004;TA0008 — Initial Access; Privilege Escalation; Lateral Movement | The flaw enables code execution outside the intended boundary and movement into the host environment. |
| Recommendation — Map sandbox escape scenarios to ATT&CK and hunt for code paths that cross from restricted execution into host control. | ||
| CIS Controls v8 | CIS-2 — Inventory and Control of Software Assets | The article emphasises finding every direct and transitive vm2 instance before remediation. |
| Recommendation — Maintain accurate software inventories so vulnerable sandbox dependencies can be identified and upgraded quickly. | ||
| NIST CSF 2.0 | PR.DS-01 — Data-at-rest is protected | Although the article is about code execution, the broader control concern is protecting assets from runtime compromise. |
| Recommendation — Use protective controls that assume runtime compromise is possible and limit the assets exposed through untrusted execution. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | The article explicitly calls for immediate upgrade of the vulnerable dependency. |
| Recommendation — Track vulnerable sandbox dependencies through flaw remediation workflows and verify patched versions after deployment. | ||
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.
- Transitive dependency exposure: Security exposure that arrives through an indirect software dependency rather than a package a team selected directly. It matters because the vulnerable code can exist in runtime paths that are easy to miss if governance only tracks top-level frameworks.
- Runtime Isolation: A containment pattern that separates risky execution from the main application so compromise has limited blast radius. For AI systems, it is the practical control that keeps a manipulated model response from inheriting full application or infrastructure privileges.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. Explore nhimg.org for resources that connect identity governance to the broader security disciplines your programme depends on.
Published by the NHIMG editorial team on August 19, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org