By ByteBot
WebAssembly has a security story it tells well and one it mostly ignores. The well-told story: Wasm runs in a sandbox, isolated from the host system. The ignored one: that sandbox does nothing to protect the module’s own memory from itself. Any C or C++ code compiled to Wasm brings its memory unsafety along for the ride. Researchers at the University of Duisburg-Essen have now published Bento, a static binary rewriter that partitions a Wasm module’s linear memory into isolated regions using the Wasm multi-memory standard — stopping Heartbleed-style attacks, with 3% runtime overhead, and without touching a line of source code.
The Problem Wasm Doesn’t Talk About
When you run a Wasm module in a browser or a server-side runtime, the host system is well-protected. The module cannot reach outside its sandbox. That’s real and valuable.
Inside the module, though, it’s a different picture. WebAssembly uses a flat linear memory model — a single contiguous byte array where stack, heap, and global variables all live side by side, with no hardware-enforced boundaries between them. There’s no address space layout randomization (ASLR) within that memory either. The layout is deterministic: an attacker who knows the binary can predict exactly where things sit.
When C or C++ is compiled to Wasm via Emscripten, the compiler defenses that developers rely on in native builds — stack canaries, ASLR, memory tagging — don’t survive the translation. Research has documented that out of 4,469 programs tested, 1,088 behaved differently compiled to Wasm compared to x86, largely due to these missing protections. A buffer overflow that would trigger a crash on native hardware can silently corrupt adjacent memory regions in Wasm and keep running under attacker control.
This matters because most production Wasm in the wild is compiled from C or C++. ffmpeg.wasm, SQLite in the browser (sql.js), libpng, libwebp, Unity and Godot WebAssembly exports — all of them carry these properties. The Wasm sandbox protects the browser tab from the module. It does not protect the module’s heap from its own stack.
What Bento Does
Bento’s name is intentional: a bento box keeps different foods in separate compartments. The tool does the same for Wasm memory regions.
The key design decision is that Bento operates on the compiled Wasm binary, not the source. It runs a whole-program pointer analysis across the binary to identify which data lives in which logical region — stack, heap, globals — then rewrites the binary to map each region to its own isolated Wasm memory instance using the Wasm multi-memory feature. Memory access instructions get redirected to the appropriate instance. No new instructions are added. The result is a software-based memory management unit, built entirely within the Wasm standard.
Because Bento works at the binary level, it can harden commercial off-the-shelf (COTS) Wasm modules — libraries where you don’t have the source, third-party npm packages that ship compiled Wasm, legacy codebases with complex build pipelines. No toolchain changes, no recompilation.
The Heartbleed Test
The Heartbleed vulnerability (CVE-2014-0160) was a buffer over-read in OpenSSL that let attackers leak arbitrary memory — private keys, session tokens, passwords — from a running server. It became shorthand for the worst class of memory bugs: silent, exploitable, and invisible until too late.
The researchers replicated Heartbleed in a Wasm context and ran it against Bento-hardened binaries. Without Bento, the exploit worked as expected: overreading in one memory region leaked data from adjacent regions. With Bento, it stopped. The isolated memory instances mean a read that escapes one region’s bounds hits an isolated boundary, not a neighboring data structure.
The same approach was validated on real-world applications: Libpng and PDFAlto. Both were hardened successfully. The work is published in the Proceedings of the ACM Web Conference 2026 and is being presented in Dubai this month.
The Cost: 3% Overhead
Security tools that impose 30–100% overhead are academic exercises. Bento’s numbers are production-relevant: 3% average runtime overhead and 1% startup overhead. The researchers describe it as “no visible slowdown.” Since no new instructions are added — only redirected memory accesses — the overhead comes primarily from managing multiple memory instances rather than from computation.
That’s a meaningful number for teams deciding whether to integrate hardening into their Wasm pipeline.
What You Need to Use It
Bento relies on the Wasm multi-memory feature, part of the WebAssembly 3.0 spec finalized in September 2025. Browser support is mostly there: Chrome and Firefox have shipped multi-memory; Safari is still completing its implementation. Server-side runtimes — Wasmtime, WasmEdge, WAMR — fully support it, which means Bento is immediately relevant for server-side Wasm workloads running untrusted or third-party modules.
One clear scope boundary: Bento is designed for C/C++ compiled Wasm. If your Wasm is written in Rust or Swift, memory safety is handled at the language level and Bento isn’t needed. But if you’re shipping or consuming Emscripten-compiled libraries — which describes a large fraction of production Wasm today — this is directly applicable.
Bento is currently published research, not yet a packaged tool. But the approach is well-documented, the implementation is based on standard Wasm primitives, and the performance cost clears the bar for production use. Wasm is expanding beyond browsers — into microcontrollers, edge functions, and multi-tenant plugin systems where isolation guarantees matter even more. Bento’s timing is not accidental.
