Somehow, I suspect that WebAssembly will eventually have most of the problems of Java in the browser.
* Language-based security model. Hopefully not an issue, browsers have been pretty good at sticking with same origin policy and not trying to mix code from different providers in the same address space.
* sun.misc.unsafe. As long as the APIs available to WebAssembly are the same as the Javascript APIs, not an issue.
* Slow startup times. For a decent loader / JIT infrastructure this is not an issue regardless of the language. In other words, an implementation detail and not a systemic issue.
* AWT / Java2D. There is a chance non-DOM widget toolkits will make a comeback, but that's less of a WebAssembly issue and more of a Canvas issue. Canvas has been around for a while, but most people still use the DOM.
"programs which invoke undefined behavior at the source language level may be compiled into WebAssembly programs which do anything else, including corrupting the contents of the application heap, calling APIs with arbitrary parameters, hanging, trapping, or consuming arbitrary amounts of resources (within the limits)." [1]
So now it's possible to hammer on the entire JavaScript API with invalid parameters. How long before someone finds a hole?
People already "hammer on the entire JavaScript API with invalid parameters". That's what fuzzing is, and yes, it does find implementation errors which can lead to security problems.