Wasmtime Patches Two CVSS 9.9 Flaws That Could Let WebAssembly Code Escape Its Sandbox

Two critical bugs in a widely embedded compiler

On 19 October 2026, the Bytecode Alliance published security advisories for two critical flaws in Wasmtime, the WebAssembly runtime it maintains, each rated 9.9 out of 10 on the CVSS v3.1 scale. Both sit in Cranelift, the compiler Wasmtime uses by default to turn WebAssembly modules into native machine code, and both could let a specially crafted module break out of the sandbox that is supposed to contain it, according to the advisories GHSA-897f-g5gm-fmxm and GHSA-mghf-wjfp-p5xm.

The first flaw, CVE-2026-115889, affects every processor architecture Wasmtime supports. The GitHub Advisory Database entry for it states that Cranelift's compiler backend packed SSA value indices into a field too small to hold them, which could cause "silent overflow in release builds, and result in incorrect value references in the IR resulting in arbitrary miscompilation." A module with enough internal values could trigger that overflow and push Cranelift into generating unsafe code, opening the door to type confusion and other attacker-controlled effects.

The second, CVE-2026-115893, is narrower but no less severe: it affects only 64-bit Arm (aarch64) hosts. The Bytecode Alliance's advisory explains that "when running with the Cranelift compiler backend on an aarch64 target, Wasmtime can compile a Wasm module with more than ~256k targets on one br_table instruction in a way that results in an incorrect conditional branch target." A module built with an oversized branch table could make the compiled code jump to an address the attacker chose, rather than one in the program itself.

The two bugs were fixed on different version branches: the bit-packing flaw, CVE-2026-115889, is patched in Wasmtime 36.0.19 and 43.0.0; the aarch64 branch-table flaw, CVE-2026-115893, is patched in 36.0.19, 48.0.7 and 49.0.4. Version 50.0.0, released on 20 October 2026, carries both fixes for anyone starting from a current build. The Hacker News reported on 26 October 2026 that the Fermyon Spin framework, which runs application code on Wasmtime, had already moved to Wasmtime 50.0.0 by 21 October.

How a sandbox escape like this actually happens

Wasmtime is built to run code from sources a host does not fully trust: a serverless platform executing a customer's uploaded function, a plugin system loading a third-party extension, or a browser-adjacent runtime sandboxing untrusted scripts. The entire premise is that whatever a WebAssembly module does, it stays inside the memory and instructions Wasmtime hands it. A compiler bug that miscompiles the module itself undermines that premise before the sandbox's own checks ever run, because the unsafe behavior is baked into the native code the host executes.

That is what sets these two flaws apart from a typical application bug: the vulnerability is in the compiler, not in any one WebAssembly program. The Hacker News' report notes that the risk is concentrated in "services that compile modules written by other people," since an attacker needs control over the WebAssembly module's bytecode to trigger either overflow. A host that only ever runs code it wrote itself is at far lower risk than one that compiles and runs modules submitted by outside users.

Each advisory credits an outside reporter rather than the Bytecode Alliance's own team: ilyas-mallah for the aarch64 branch-table flaw and jaydns for the bit-packing flaw. As of 26 October 2026, neither CVE had appeared in CISA's Known Exploited Vulnerabilities catalog, according to The Hacker News' report. That suggests the flaws were caught and fixed before any confirmed exploitation, though the report does not rule out undetected use.

Why this matters beyond the Wasmtime project

Wasmtime is one of the reference runtimes behind the WebAssembly System Interface (WASI) and is embedded as a library inside other platforms rather than used only as a standalone tool, which is why a compiler-level bug in it can reach further than its own user base. Anyone teaching or studying WebAssembly sandboxing, serverless isolation or compiler correctness now has a concrete, dated case study: a bit-packing limit and a branch-table size limit, each invisible in ordinary testing, each capable of turning a "sandboxed" execution model into arbitrary code execution on the host.

For developers building on Wasmtime, the practical step is straightforward: confirm which release line is in use and move to the fixed version for the applicable branch — 36.0.19 or 43.0.0 to close the bit-packing flaw, 36.0.19, 48.0.7 or 49.0.4 to close the branch-table flaw, or simply 50.0.0 or later, which includes both — per the fixed-version lists in both advisories. For anyone building or teaching compiler infrastructure, the more durable lesson is that integer field sizes and jump-table bounds are not implementation detail once a compiler is a trust boundary — they are part of the security contract a sandboxed runtime makes with everything that embeds it.