WebAssembly being described as a sandbox is perfectly valid. Applications with embedded sandboxes for plugins use the sandbox to protect the application from the plugin, not to protect the plugin from itself. The plugin author can protect the plugin from itself by using a memory-safe language that compiles to WebAssembly; that's on them and not on the embedding application.
Except the tiny detail that the whole application is responsible for everything it does, including the behaviour of plugins it decides to use, so if the plugin can be exposed to faulty behaviour on its outputs, that will influence the expected behaviour from the host with logic building on those outputs, someone will be very happy and write a blog post with a funny name.
Linear memory accesses aren't bound checked inside the linear memory segment, thus data can still be corrupted, even if it doesn't leave the sandbox.
Also just like many other bytecode based implementations, it is as safe as the implementations, that can be equally attacked.
https://webassembly.org/docs/security/
https://www.usenix.org/conference/usenixsecurity20/presentat...
https://www.usenix.org/conference/usenixsecurity21/presentat...
https://www.usenix.org/conference/usenixsecurity22/presentat...