Wasmtime Cranelift Bug on aarch64 Enables Wasm Sandbox Escape via Oversized br_table

What happened

The Wasmtime project disclosed a security advisory (GHSA-mghf-wjfp-p5xm, CVE-2026-115893) affecting its Cranelift compiler backend on aarch64 targets. According to the advisory, compiling a Wasm module containing a br_table instruction with more than roughly 256,000 targets can cause Cranelift to generate an incorrect conditional branch target. A crafted module can use this to force the branch to jump to a user-controlled offset, leading to arbitrary sandbox escape.

The advisory states this affects all versions of Wasmtime/Cranelift with aarch64 support going back to 2020, before Wasmtime v1.0, under default settings. Fixes have been released in Wasmtime v36.0.19, v48.0.7, and v49.0.4. The advisory lists a CVSS of 9.9 and reports that a proof-of-concept is publicly available.

Why it matters for defenders

Wasmtime is a WebAssembly runtime used to sandbox untrusted code. The flaw is in the compiler backend rather than in any one application's use of it. Any product that embeds a vulnerable Wasmtime/Cranelift on aarch64 and executes untrusted or semi-trusted Wasm modules inherits the risk, regardless of how the embedding application validates its own inputs. The affected window goes back to 2020, and a public proof-of-concept is reported, so operators running Wasm sandboxes on arm64 should treat this as urgent.

What defenders should watch for or do now

• Inventory services and products that embed Wasmtime/Cranelift and execute third-party or untrusted Wasm modules. Pay particular attention to aarch64 deployments such as ARM-based cloud instances and edge devices.
• Upgrade to the patched releases (v36.0.19, v48.0.7, or v49.0.4) wherever Wasmtime is embedded, especially in multi-tenant or untrusted-code-execution contexts.
• Where immediate patching is not possible, consider restricting or inspecting Wasm module uploads for unusually large br_table instructions as a stopgap, and review whether a non-aarch64 compilation target is a viable interim option.
• For hunting, look for anomalous process behavior, unexpected child processes, or memory-corruption-style crashes originating from Wasm-sandboxed workloads.
• Treat any service that accepts user-supplied Wasm modules as a high-value target for this bug class, and track upstream guidance for further hardening recommendations.

Developing intel

This is a same-day advisory and details may evolve as the community analyzes exploitability and real-world impact. For authoritative details and official patch information, see the original advisory: GHSA-mghf-wjfp-p5xm.