Comment by rvz
20 hours ago
This sounds like a solution looking for an unnecessary security nightmare.
Something as little as the runtime can just get exploited (which that as happened.) and cause a sandbox escape on the client side. There was a Chrome 0day at the runtime level which allowed untrusted code to run and escape the sandbox in the WASM runtime.
This complete worship of WASM (and their runtimes) as this magical silver bullet reminds me of the days and failures of Native Client (NaCL), Java Applets and Flash all over again.
You mean this one? https://theori.io/blog/a-deep-dive-into-v8-sandbox-escape-te...
I dunno, one sandbox escape in nine years is a pretty solid track record IMO.
Any reason WASM is more dangerous than regular JavaScript?
No. This one. [0].
Even before that, there are several other sandbox escapes that predated the one you posted. [1] [2] and this one [3] can be used to trivially escape its sandbox with either of these vulnerabilities.
So it is not the magical silver bullet one may easily think it is.
[0] https://nvd.nist.gov/vuln/detail/CVE-2026-11645
[1] https://blog.ret2.io/2021/06/02/pwn2own-2021-jsc-exploit/
[2] https://issues.chromium.org/issues/40091185
[3] https://phrack.org/issues/72/10_md#article
> Something as little as the runtime can just get exploited (which that as happened.) and cause a sandbox escape on the client side.
Sandbox escapes could happen in Javascript too, right? But I don't see people avoiding browsing the web because of that