The applet sandbox didn't merely leak; it was non-existent. Java applets had built-in access to the complete filesystem, network, shared memory etc. A java app

The applet sandbox didn't merely leak; it was non-existent. Java applets had built-in access to the complete filesystem, network, shared memory etc. A java applet could read cookies, credentials etc stored on disk and transmit them elsewhere - this was not "hacking", it was merely "write the code to do it". By contrast, the WASM standard offers no access to anything - no IO of any kind. The only documented way to do IO is to have the hosting code (eg javascript) pass in a function pointer to perform IO on behalf of the WASM. You could definitely go looking for a vulnerability in a particular WASM engine which let you escape the sandbox on that engine - and I have real concerns about JIT type-confusion vulnerabilities, and the GPU as an attack vector. However, "find a vulnerability to exploit" and "call an officially-documented method" are very different approaches to performing IO.