[int_19h]

CLR sandbox should not be considered a meaningful security boundary at this point. CAS and partial trust are both officially obsolete.

The problem is always complexity. It can be difficult to reason about safety with so many features on bytecode level. There have been exploits using dynamically-generated methods, exception filters, and vararg handling - note the near-lack of any common patterns here other than they're all obscure features of the platform, the security impact of which wasn't fully analyzed.

For example, a long time ago, I reported the vararg exploit, which boiled down to the fact that you can have ArgIterator over an argument list containing another ArgIterator, allowing the latter to be mutated via the former. Thus, you can stash away an ArgIterator to the arguments of a function call that has already returned. This is basically the same as having a managed reference to a managed reference, and it's exactly why CLR prohibits this - but they forgot that ArgIterator is also a kind of a managed reference.

[pjmlp]

And WASM remains to be battle tested in the wild, as in the juicy target of millions of black hats out there.

Forcing internal corruption of code produced from C compilers (like doing a stack out of bounds data overwrite due to incorrenct params size) is perfectly viable.

Yeah the exploit doesn't leave the sandbox, so what. It can still be used to direct the sandboxed code to produce other outcome from the called functions.