While I've only briefly examined the WebAssembly (WASM) security model, it seems like a recurrence of vx32 and NaCL. One inherent issue is the "glue" code enabling the WASM runtime to invoke necessary operating system (OS) primitives, such as memory allocation, file system and network access.

The appeal of vx32/NaCL/WASM lies in its bytecode (or verified x86 asm stream), which cannot operate independently due to its lack of access to syscalls or other inter-process communication (IPC). However, a program without syscall access is essentially futile, limited to using the CPU's arithmetic logic unit, reading/writing memory, and potentially handling input/output buffers.

Soon enough, developers will require access to modern amenities offered by OSes such as memory mapping, file descriptors, and async IO. Consequently, OS bridge creators will supply proxies to the kernel, some of which will be improperly implemented. Given their complexity and size, these proxies may essentially become exploitable mini OSes.

There's no perfect sandboxing, some forms appear more trustworthy (or more thoroughly scrutinized by researchers) than others. WASM may seem safer than vx32/NaCL because it lacks bytecode verification issues; the bytecode is fully understood, unlike verifying x86 instructions (which are prone to erratas). However, the bridge/glue/proxy/broker problem remains unavoidable.