Earlier quoted context omitted.
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 credential…
I'm no expert but I believe in wasm memory and code are separate.
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.