This isn't about escaping the vm. It is about changing how the program works inside. Wasm also does not have the concept of read only memory which is another massive security hole.
"even if" you can change the program (and like some other comments indicated, I'm fairly certain that's not how linear memory in WASM works), WASM still runs on a "capability model": It has access to only certain file handles, sockets, etc. that are provided declaratively.
I was once a huge detractor and naysayer of WASM, but now I'll readily admit that this is the way security "always should have been done".
In this case we aren't talking about changing some code in a .js file through a RFI attack. We are talking about changing the behavior of how the node.js interpreter would run the .js file because at the end of the day the interpreter itself is what is getting ran by the os.
No, you would be changing how the wasm module operates in its own address space. You aren't changing how the VM runs. As far as I know wasm never made any promise against self-modifying code and I don't even understand the threat model you think exists since everything is isolated.
If you have specific security concerns, you should be showing actual attacks against wasm runtimes or somehow show that the security model of wasm as a whole will always reduce to an insecure configuration. What you have shown is something that is "exploitable" on pretty much every architecture I know of.
I really don't know how to parse this comment but I'll try to be charitable.
How do you propose WASM code is able to change the WASM interpreter behavior?
Could you be misunderstanding WASM's memory model? Are you aware that WASM code can only access explicitly instantiated userspace JS linear memories? Are you aware these memories are just ArrayBuffers in JS userspace?
Again, apologies for the bluntness, but the people who have linked those very links as responses to your ranting are pointing out that you are incorrect about a lot of things.
