Wasmtime fixes two critical sandbox escapes in its Cranelift compiler

Wasmtime fixes two critical sandbox escapes in its Cranelift compiler

19 October 2026: The Bytecode Alliance has fixed two critical flaws in Wasmtime, the WebAssembly runtime used to run untrusted code in serverless platforms, plug-in systems and edge services, that let a crafted WebAssembly module break out of its sandbox. Both are rated 9.9 under CVSS 3.1 and both sit in Cranelift, the compiler Wasmtime uses to turn WebAssembly into machine code. Versions 36.0.19, 48.0.7 and 49.0.4 carry the fixes.

Not yet independently verified. Both advisories come from the Bytecode Alliance itself; we have not found an independent analysis, and only the first has a CVE number so far. No exploitation has been reported. We will update this when it can be confirmed, and remove this note.

The project published the two advisories on 19 October. Neither reports exploitation.

How the two flaws work

The first, CVE-2026-115889 (GHSA-897f-g5gm-fmxm), affects Wasmtime before version 43 on every architecture with default settings. Cranelift packed the index of each value into a limited number of bits, and in release builds a very large or deliberately crafted function could overflow that field without any error. The compiler then confused one value with another, which the advisory classes as type confusion leading to a sandbox escape. Cranelift moved to full 32-bit indexes with checks in version 43.

The second (GHSA-mghf-wjfp-p5xm) is specific to 64-bit Arm. A module with more than about 256,000 targets in a single br_table instruction made the aarch64 back end compute the wrong branch target, so the program could jump to code at an offset the attacker chose. The advisory says every Wasmtime version with aarch64 support is affected, going back to 2020.

Which versions to install

• 49.x: update to 49.0.4
• 48.x: update to 48.0.7
• 36.x (long-term support): update to 36.0.19
• 50.0.0: released after the advisories, also fixed

Releases older than these lines get no fix, so anyone on another branch needs to move to one of them.

Who should move first

The exposure is greatest where Wasmtime runs modules that someone else wrote: function-as-a-service platforms, CDN and edge runtimes, plug-in hosts and blockchain-style execution engines. Services that only run their own compiled modules are at lower risk, but the overflow can be triggered by size alone, so a large legitimate module is not proof of safety. Where an update has to wait, the aarch64 flaw can be avoided by running on x86-64 hosts, while the index overflow has no configuration workaround in the advisory. The same advisory list carries lower-rated fixes from 14 and 19 October, including a moderate filesystem sandbox escape through symlinks with a trailing slash, which the same releases address.

Sources

• Bytecode Alliance: Wasmtime advisory GHSA-897f-g5gm-fmxm (CVE-2026-115889), Cranelift value index overflow, 19 October 2026
• Bytecode Alliance: Wasmtime advisory GHSA-mghf-wjfp-p5xm, aarch64 br_table miscompilation, 19 October 2026
• Wasmtime releases on GitHub (read 27 October 2026), 27 October 2026