Worth remembering: Wasm on browsers is sandboxed by origin and can't do anything the JS cannot already do.
However, Wasm on computers with a full set of syscalls available is isomorphic to native code. Worse, because programs in C/C++ and other unsafe languages can compile to Wasm, any security bugs in those codebases will be present when compiled to Wasm. Wasm programs can still have buffer overflows, use-after-frees, and all the other fun memory safety issues; threads will add data races and memory ordering bugs to the mix.
The only benefit of Wasm in this space seems to be that you don't have to recompile your programs for a new architecture - kind of like a lower-level Java. But as soon as your program needs to interact with OS features or existing native libraries, this benefit is going to go out the window...
You are right about mostly everything except all the flaws of C/C++ making it into Wasm. Wasm still has CFI (Control Flow Integrity) and if you don't take the address of a stack variable, no C stack entry will be made, so much of the stack is invisible to user code (C/C++ code).
You can still corrupt memory, you can't implement ROP or subvert control flow in a non data-dependent way.
However, Wasm on computers with a full set of syscalls available is isomorphic to native code. Worse, because programs in C/C++ and other unsafe languages can compile to Wasm, any security bugs in those codebases will be present when compiled to Wasm. Wasm programs can still have buffer overflows, use-after-frees, and all the other fun memory safety issues; threads will add data races and memory ordering bugs to the mix.
The only benefit of Wasm in this space seems to be that you don't have to recompile your programs for a new architecture - kind of like a lower-level Java. But as soon as your program needs to interact with OS features or existing native libraries, this benefit is going to go out the window...