The challenge of compiling for verified architectures

Roughly, this works by calling a function typed (void*)(uint64_t) through an indirect call (function pointer). While the WASM security model prevents you from directly assigning a function fn with signature void fn(void*) to the function pointer in question, you can cause the CPU to speculate that the call through your function pointer may end up in fn (via BTB poisoning) and therefore cause speculated access to arbitrary memory locations from WASM into the host address space (similarly applies to e.g. JacaScript). This can be exploited as really reliably for as long as the JIT ever emits an indirect call (and all JITs known to me do that, but notably researchers have also found ways to use the branch cascade resulting from switch/case-like constructs to cause the required BTB confusion).

From a high level point of view, you have to assume that any "protection" offered by a languages or runtimes type system to separate pointers from arbitrary integers can be circumvented by speculative confusion of branch targets.