The Boundary Fuzzer

JavaScript engines are the primary defense mechanism for executing untrusted code on the web. WebAssembly runs alongside JavaScript in the same engine. Previous fuzzing tools tested each language independently — generating JavaScript programs to find JavaScript bugs, WebAssembly programs to find WebAssembly bugs. The boundary between them went untested.

Weaver targets that boundary specifically.

The challenge is type-aware generation. A variable shared between JavaScript and WebAssembly must be valid in both type systems simultaneously. JavaScript is dynamically typed; WebAssembly is statically typed. A fuzzer generating random cross-language programs will produce syntactically valid but semantically meaningless tests unless it maintains dual type representations — tracking what each variable looks like from both sides of the boundary.

Weaver maintains this dual representation and uses the UCB-1 algorithm (from the multi-armed bandit literature) to schedule which mutators and generators to apply. The scheduling is intelligent: generators that produce programs triggering new code paths are favored over those that don’t. The exploration-exploitation tradeoff, borrowed from reinforcement learning, directs the fuzzer toward unexplored regions of the cross-language interaction space.

The practical result: two new bugs in production JavaScript engines, one rated high severity and highest priority. These bugs live at the boundary — they cannot be found by testing either language alone, because they arise from the interaction between the two type systems and the shared memory model.

The attack surface exists because the boundary exists. Wherever two systems meet, the interface assumptions of each become the vulnerability of the other.