Exactly. It is entirely a misconception to believe that WASM is this silver bullet on sandboxing and it is not that great security-wise I’m afraid.

It is only now being inspected by researchers and attackers who have found sandbox escapes [0] (chrome 0day), out-of-bounds [1] / use-after-free [2] and many other [3] flaws [4] in WebAssembly which I also agree that it is not enough for sandboxing at all.

[0] https://nvd.nist.gov/vuln/detail/CVE-2026-11645

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=2009901

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=2013741

[3] https://www.miggo.io/vulnerability-database/cve/CVE-2026-269...

[4] https://github.com/bytecodealliance/wasm-micro-runtime/secur...

There's no reason to believe that [0] has anything to do with WASM, [1] and [2] are runtime implementation bugs, [3] is a vulnerability in a "weak" sandboxing library VM2 - it has nothing to do with WASM as such, and [4] is another implementation bug in an experimental WASI feature of that specific runtime which is gated behind a build flag.

------

[Re: 3] https://github.com/patriksimek/vm2

> vm2 attempts to sandbox untrusted JavaScript code within the same Node.js process as your application. It does this through a complex network of Proxies that intercept and mediate every interaction between the sandbox and the host environment.

> JavaScript is an extraordinarily dynamic language. Objects can be accessed through prototype chains, constructors can be reached via error objects, symbols provide protocol hooks, and async execution creates timing windows. The sheer number of ways to traverse from one object to another in JavaScript makes building an airtight in-process sandbox extremely difficult.

[Re: 4] https://github.com/search?q=repo%3Abytecodealliance%2Fwasm-m...

Those are not flaws in WASM itself, but in different WASM runtimes.