CVE-2026-115889: Wasmtime: Bit-packing in Cranelift compiler causes silent overflow and miscompilation

Cranelift refers to SSA values by index inside its IR. Before Wasmtime 43, those indices were bit-packed, and release builds did not check for overflow. A Wasm function body that is huge, or built to use many SSA values, pushes an index past the packed limit. The index wraps and points at the wrong value. The compiler then emits code that treats one value as another.

The advisory calls the result arbitrary miscompilation: type confusion or other arbitrary side effects that break out of the sandbox. The CWEs are numeric truncation (CWE-197) and type confusion (CWE-843).

The affected setup is any Wasmtime engine with default settings, which means the Cranelift backend, on any architecture or platform. An attacker needs to get a crafted module compiled by your engine. That fits plugin systems, serverless and edge runtimes, and any service that runs user-supplied Wasm. The CVSS vector has low privileges and changed scope: a tenant who can upload a module can reach the host process and whatever it holds.

Precompiled code is a separate concern. A module compiled by a vulnerable engine carries the miscompiled output with it.

Affected: the wasmtime crate below 36.0.19, and 37.0.0 up to but not including 43.0.0. This covers embedders that link Wasmtime as a Rust crate and users of the wasmtime CLI. Applications that bundle Wasmtime through other language bindings inherit the engine version they ship.

Check a Rust project:

cargo tree -i wasmtime

Check the CLI:

wasmtime --version

Upgrade to 36.0.19 if you are on the 36.x line, or to 43.0.0 otherwise. In a Rust project:

cargo update -p wasmtime

Adjust the version requirement in Cargo.toml first if it pins an older release. Wasmtime 43 changed Cranelift to use a full u32 index and to check when that limit is exceeded. The advisory and RustSec entry list no workarounds. Rebuild and redeploy every binary that embeds Wasmtime, and recompile any cached or precompiled modules with the patched engine.

The sources give no log signature for this bug. A miscompiled module may crash or behave oddly, but a successful escape could leave no trace. Review which Wasm modules your service accepted from untrusted parties and flag unusually large functions. Inventory every deployed Wasmtime version with cargo tree or your SBOM. Treat hosts that ran untrusted modules on an affected engine as potentially compromised.

Summary

In Wasmtime prior to v43, the Cranelift compiler backend bit-packs its SSA value indices in a way that can result in silent overflow in release builds, and result in incorrect value references in the IR resulting in arbitrary miscompilation. A very large Wasm function body, or one that is specially crafted to use many SSA values, can use this to force type-confusion or other arbitrary side-effects and escape the sandbox.

Cranelift was changed in Wasmtime v43 to use a full u32 index, with checks if that limit is exceeded, and so is no longer susceptible to this bug.

Impact

A Wasmtime engine with default settings (using the Cranelift backend) on any architecture/platform could experience a sandbox escape from a specially-crafted Wasm module.

Patches

Wasmtime v36.0.19 has been released which fixes this issue.