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.
How a Broken Promise Path Turns a Sandbox Into Host Execution
A javascript sandbox depends on every escape path being mediated. When a Promise chain is not sanitised consistently, the boundary is no longer enforced at the point where asynchronous code resumes, which is exactly where many sandboxes are weakest. That means the problem is not just a bad callback, it is a failure in the containment model itself.
The practical security issue is that Promise resolution can re-enter execution with host privileges or host objects still reachable. If the sandbox only blocks the “obvious” synchronous path and misses one asynchronous path, attacker-controlled code may regain capabilities the sandbox was meant to remove.
That is why this class of bug is best understood as a control-plane failure in runtime mediation rather than a simple input-validation issue. The sandbox is supposed to decide what untrusted code can touch after every transition, not only when code first enters the isolated context.
Why the Failure Becomes Arbitrary Code Execution
Once a Promise path is left unsanitised, the attacker may be able to pivot from restricted script execution into host-level objects, functions, or APIs. In many real-world sandboxes, the dangerous step is not direct string evaluation but reaching a privileged reference through an asynchronous continuation.
That changes the outcome from “sandbox escape in theory” to arbitrary code execution in practice because the sandbox no longer reliably constrains the execution graph. When the host can be called back through a path the policy did not intercept, the sandbox cannot guarantee that untrusted code stays confined.
The containment break is usually broad, not narrow. A single missed Promise transition can undermine assumptions about object isolation, capability filtering, and safe callback wrapping, especially when the sandbox relies on runtime patching instead of a stronger isolation boundary.
What Practitioners Should Inspect in a Promise-Sanitisation Bug
Focus first on where asynchronous control returns from the sandboxed realm to the host realm. The dangerous condition is not merely the presence of Promises, but any path where resolution, rejection, chaining, or thenable adoption can bypass the same sanitisation logic applied to synchronous entry points.
In practice, this means checking whether every Promise-related primitive is covered, including custom thenables, wrapped callbacks, exception propagation, and any API that can smuggle host references through asynchronous state. If one path remains unsanitised, assume the sandbox boundary is incomplete.
For code review, the key question is whether the sandbox enforces mediation at every handoff point. A design that sanitises only the initial function call but not the continuation is structurally unsafe, because the attacker only needs one path to re-enter with useful authority.
Risk and Threat Considerations
Broken Promise mediation creates a high-impact escape condition because attackers can abuse a single missed asynchronous path to regain host capabilities, execute arbitrary code, or reach privileged objects that were supposed to stay outside the sandbox. The exposure is especially serious when the sandbox is used to run third-party scripts, plugin code, or user-supplied automation.
Failure mechanism: An unsanitised Promise path preserves or reintroduces host references during asynchronous resumption, letting attacker-controlled code cross the isolation boundary through a transition the sandbox failed to intercept.
Impact: The sandbox loses its security value, and the compromise can expand from confined script execution to host compromise, data exposure, or broader application takeover depending on what the host objects can reach.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while OWASP ASVS, NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| MITRE ATT&CK | T1059 — Command and Scripting Interpreter | Sandbox escape can end in arbitrary code execution through script execution paths. |
| Recommendation — Map the escape path to script execution techniques and hunt for host-level interpreter abuse. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | The issue is an architectural containment failure in runtime mediation and isolation. |
| Recommendation — Verify that sandbox boundaries are enforced across all execution transitions and continuations. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Untrusted code paths require strict mediation before they can influence host execution. |
| SC-3 — Security Function Isolation | A sandbox is an isolation control that fails when host execution is reachable from untrusted code. | |
| Recommendation — Apply input and execution-path validation to untrusted sandbox transitions. Strengthen isolation so untrusted code cannot cross into host authority through one missed path. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | This is a software security defect in how runtime boundaries are implemented. |
| Recommendation — Test sandboxing logic with adversarial inputs and fix any path that bypasses containment. | ||
Practitioner Guidance
What to verify: Confirm that sanitisation covers every Promise entry and exit point, not just the first call into the sandbox. Test native Promises, chained callbacks, rejection paths, and thenable-like objects, because attackers often look for the least obvious continuation path.
Decision rule: If a sandbox cannot prove that asynchronous resumption is mediated the same way as synchronous execution, treat it as unsafe for hostile code. A partial fix is not a containment control, it is an assumption waiting to fail under adversarial input.
What good looks like: The sandbox enforces the same boundary rules across all continuation paths, and any failure to sanitise a path causes a clean, visible denial of execution rather than a silent escape.
Practitioner takeaway: For sandboxing, the real security question is not whether untrusted code starts inside the box, it is whether every possible way back into host authority is blocked with the same rigor.
Related resources from NHI Mgmt Group
- What breaks when sandbox rules only protect specific file paths in developer tools?
- What breaks when sandbox containment fails for an AI agent?
- What fails when a JavaScript sandbox escape vulnerability is present?
- What breaks when a server-side archive extractor fails to validate file paths during Git repository migration?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org