WASM, famous from web browsers, regularly sees breaking out of sandbox issues. For example, see WebAssembly notes here:


Often these issues may lead to arbitrary code execution, the most dangerous kind of issue. These are especially prone with just-in-time WASM code interpretation, as the attacker has a lot of control over produced binary code. In the case of EOS, this would be malicious smart contract code. Also, we have similar cases over the history of Java JVM that allowed executing sandboxed Java code to allow to escape into host OS.

Now 360 (Chinese Internet company) claims that they have found arbitrary code execution in EOS:


What safety measures, like process isolation, EOS takes to ensure that the future arbitrary code execution or sandbox escapes in WASM don't allow taking over the block producer?


2 Answers 2


The Web Assembly Website has information on the potential security issues for both users and developers when coding in WASM.

With regards to arbitrary code execution in EOS, @confused00 points out that these bugs were fixed before the report was even published.

EOS has a very quick turn around for serious bugs. If a vulnerability is found it can be fixed very quickly, as has already happened recently with the RAM problem.


EOS 2.0 adds a protection mechanism via CPU/OS paging, as stated in this article:


There are no details available yet, but it seems that sandboxes VM processes get their own memory space and can't get out of it.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.