The bounds checking story is only on the external limits of linear memory segments.
If memory gets corrupted inside a linear memory segment, it can equally well be exploited to change execution behaviour, which for many scenarios is already good enough for the attacker.
Yet these kind of attack vectors usually are dropped from blog posts selling WebAssembly as a revolutionary bytecode.
It is only yet another one since various others that came and went since UNCOL became an idea.
Why /s? That does massively reduce the exposure
As much as an OS process, on a modern OS that is.
The bounds checking story is only on the external limits of linear memory segments.
If memory gets corrupted inside a linear memory segment, it can equally well be exploited to change execution behaviour, which for many scenarios is already good enough for the attacker.
Yet these kind of attack vectors usually are dropped from blog posts selling WebAssembly as a revolutionary bytecode.
It is only yet another one since various others that came and went since UNCOL became an idea.