WASM provides enough memory safety so that memory corruption errors in the WASM heap can't be used to escape the sandbox (assuming there's no exploitable bug in the sandbox itself of course). It doesn't protect from memory corruption inside the WASM heap of course.
A fun exercise would be compiling the Heartbleed version of OpenSSL into WASM.
Exploits can escape the sandbox, via functions exported from WASM that change their behaviour due to internal memory corruption, or callbacks that get called with unexpected parameters from the WASM code due to the internal memory corruption that changed the execution logic.
For example, a security system that would grant higher credentials than it was supposed to.
Yes it follows Harvard architecture, still you can produce exploits by corrupting memory, no need to rewrite code, it just becomes harder to achieve them.
Basically by corrupting memory, you can achieve that the executing path changes and what was false is now true, thus influencing the outcome of what gets called and their parameters, without having to change any byte of the code.
