Notifications
Clear all
Topic starter
19/08/2026 3:57 pm
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.
NHIMG editorial — based on content published by StepSecurity: CVE-2026-22709 critical sandbox escape vulnerability in vm2
By the numbers:
- The vulnerability affects vm2 version 3.10.1 and earlier, with patched versions beginning at 3.10.2.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read StepSecurity's analysis of CVE-2026-22709 in vm2 →
vm2 sandbox escape: what it means for untrusted code execution?
Explore further
19/08/2026 4:35 pm
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.
A few things that frame the scale:
- 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.
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
A question worth separating out:
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.
👉 Read our full editorial: vm2 sandbox escape shows how dependency trust can collapse
