We previously highlighted comments from the vm2 maintainers acknowledging that future sandbox escapes are likely and that vm2 should not be relied upon as a sole security control.
We promised a write-up. Here it is.
Using the recent vm2 escape (CVE-2026-22709) as a case study, we ask:
Can an in-process JavaScript sandbox ever be treated as a security boundary?
We examine why sandbox escapes continue to occur, the architectural challenges behind them, and why stronger isolation models are often a better investment when executing untrusted code.
The core flaw is that vm2 attempts to enforce isolation inside the same language runtime, which has no concept of privilege separation.
The approach taken to patch the vulnerability is to wrap a finite set of intrinsics and methods (e.g. Promise) that could lead to a sandbox escape. This design decision has the same failure mode as a blacklist. We disallow a finite set of items that we know can cause harm. If we miss an item, type, path, or introduce a new object, a sandbox bypass can emerge.
If application security is implemented merely by chasing exploitable scenarios, it shows a deep insecure design flaw. This approach does not guarantee safety and it remains open for future exploitation.
Read the entire article here:
👉 https://secdim.com/blog/post/why-you-should-not-use-javascript-sandbox-19165/
Top comments (0)