Two Critical Wasmtime Flaws Let Malicious WebAssembly Escape the Sandbox

The maintainers of Wasmtime — a WebAssembly runtime designed to be embedded in other software — have warned of two critical vulnerabilities. A malicious Wasm module can use them to escape the sandbox that is supposed to keep it within set limits: only its own memory, only the host functions it is given, and jumps only to checked code locations.

Both bugs live in Cranelift, the compiler Wasmtime uses by default to turn WebAssembly into machine code. The Bytecode Alliance maintainers rated each flaw 9.9 out of 10 on the CVSS scale. Fixed versions shipped on October 19 and 20, and no attacks have been reported.

Conditions for exploitation

An attack needs a vulnerable Wasmtime build through which the attacker's own module is compiled. That puts services running other people's code at the highest risk. The advisory cites Fastly's Compute platform, which runs customer code on Wasmtime, as an example. The advisories name no affected services and do not spell out what an attacker could reach after escaping.

CVE-2026-115889 affects every processor architecture; CVE-2026-115893 affects only ARM64 (aarch64). As of October 26, neither appeared in CISA's catalog of known exploited vulnerabilities.

How they work

The first bug stems from how, before version 43, Cranelift packed its internal value numbers into 24-bit fields. In release builds a number too large for its field overflowed silently, and the compiler then referred to the wrong value. A sufficiently large or carefully crafted function could trigger type confusion and a sandbox escape. The fix widening the fields to 32 bits landed in the main branch back on February 18 and shipped in version 43.0.0 — but was presented merely as a way to compile bigger functions, with no mention of security.

The second bug involves br_table, an instruction that jumps by index. On ARM64 an out-of-range index was sent to the default target via a branch that reaches only about 1 MiB. A table with more than roughly 256,000 targets grew too big for that reach, so the branch silently pointed to the wrong place, letting an attacker force the engine to jump to arbitrary code. The flaw had existed since ARM64 support was first added in 2020. Fixed versions also refuse to compile a br_table with more than 65,520 targets.

What to do

Update to the fixed release for your line — 36.0.19, 48.0.7 or 49.0.4; version 50.0.0, released October 20, fixes both. Only the 36, 48, 49 and 50 lines are still supported; the rest, including the 24.x LTS line whose support ended August 20, 2026, received no fix.

Because Wasmtime is embedded in other programs as a library, updating the command-line tool is not enough — each program must be rebuilt against a fixed version. The advisories list no workaround. Spin, a tool for serverless WebAssembly apps, moved to Wasmtime 50.0.0 in version 4.2.4 on October 21.

Source: The Hacker News