Wasmtime Fixes Critical Cranelift Bug Enabling Sandbox Escape via Crafted Wasm Modules

A newly disclosed security advisory (GHSA-897f-g5gm-fmxm, CVE-2026-115889) affects Wasmtime, the WebAssembly runtime maintained by the Bytecode Alliance. According to the advisory, versions prior to v43 contain a flaw in the Cranelift compiler backend: SSA value indices are bit-packed in a way that can silently overflow in release builds. This can corrupt value references in Cranelift's internal IR, leading to arbitrary miscompilation. The advisory states that a very large Wasm function body, or one specially crafted to use many SSA values, can trigger type confusion or other unintended side effects sufficient to escape the Wasm sandbox.

Wasmtime v43 addressed the root cause by switching Cranelift to a full u32 index with overflow checks. A backport, Wasmtime v36.0.19, has also been released fixing the issue for that line. The advisory carries a reported CVSS of 9.9, and defenders should treat it as a sandbox-escape-class bug.

Why It Matters

Wasmtime is embedded in a wide range of products as a sandboxing layer for executing untrusted code, including serverless/edge platforms, plugin systems, and applications that run user-supplied Wasm modules. This bug affects the default configuration — any Wasmtime engine using the Cranelift backend (the default compiler) on any architecture is described as potentially susceptible. Because the entire value proposition of a Wasm sandbox is isolating untrusted input, a flaw that lets a crafted module break out of that isolation is high severity for anyone running untrusted or multi-tenant Wasm workloads.

What Defenders Should Do Now

• Inventory where Wasmtime is used — directly or as a dependency of another runtime/platform — and identify the version in use.
• Prioritize upgrading to Wasmtime v43+ (or the v36.0.19 backport) wherever Wasmtime executes untrusted or third-party Wasm modules.
• Until patched, consider restricting or disabling execution of untrusted Wasm modules, or isolating Wasmtime behind an additional sandboxing layer (containers, VMs, seccomp) as defense-in-depth.
• Review logging/telemetry around the Wasm host for anomalous crashes, unexpected memory-safety faults, or unusual resource consumption in processes embedding Wasmtime, which could indicate exploitation attempts against this or similar miscompilation bugs.
• Watch for unusually large or structurally unusual Wasm function bodies submitted to any service that compiles user-provided Wasm, as a potential precursor to exploitation.

This is developing, net-new intel based solely on the vendor advisory; no public exploitation has been confirmed at this time, though the advisory notes proof-of-concept exploitation is possible. For full technical detail, see the original advisory: GHSA-897f-g5gm-fmxm.