Notifications
Clear all
Topic starter
02/08/2026 11:27 am
TL;DR: Vm2 has a critical 9.8 CVSS vulnerability that lets attackers bypass promise sanitization and execute arbitrary code inside the Node.js process, affecting versions 3.10.1 and earlier, according to Semgrep. The case reinforces that code sanitization is not a substitute for real isolation when untrusted input can reach execution paths.
NHIMG editorial — based on content published by Semgrep: vm2 sandbox escape critical vulnerability analysis
By the numbers:
- Anyone who uses 3.10.1 or earlier should consider themselves affected.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
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
👉 Read Semgrep's analysis of the vm2 sandbox escape and remediation path →
Vm2 sandbox escapes: what it means for Node.js isolation controls?
Explore further
02/08/2026 12:43 pm
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.
A few things that frame the scale:
- 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.
A question worth separating out:
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.
👉 Read our full editorial: Vm2 sandbox escapes expose the limits of promise sanitization
