All the bugs they found

Summary

All the bugs they found 2026-05-18 Last year I wrote a small WASM runtime in Go, Epsilon. As far as runtimes go, this is a pretty simple one: no JIT, just a pure instruction interpreter in ~11k lines of code. It is also very extensively tested against the official WASM testsuite. Epsilon is designed to be embeddable in other applications and provide a sandbox for potentially untrusted code. How many security vulnerabilities do you think AI agents found in it? More than 20. Most of these were somewhat simple DoS attacks, e.g. panics during parsing or validation. Some were clear API design failures that would probably have surfaced sooner with a bit more usage of the project. A few weren't exploitable on their own, but would become serious if combined with a future bug elsewhere. A handful, though, were properly interesting: sandbox escapes that let a malicious WASM module break out of its isolation and reach into another module's private state. These are my favorites. Background A single Epsilon runtime can host multiple WASM modules. In the WASM security model, modules are isolated except for explicitly exported (and imported) objects. Unexported functions, memories, etc., are private to the module that defined them. WASM is a typed stack machine, but the type checking does not happen at runtime: before execution, a validator walks the bytecode and verifies that at any point the values on the stack have the expected type. For example, a module that tried to local.set an i32 into a funcref local would be rejected before it ever started running. Epsilon then executes blindly, trusting the validator's earlier checks. Thanks to the type guarantees provided by the validator, a funcref at runtime in Epsilon is represented as an int32: -1 is the null sentinel, and any non-negative value is an index into the global function store, shared across all modules instantiated in the runtime. As a result, the constant 0 and a funcref pointing to the first function in the store are ...