CVE-2026-115889: 
Rust vulnerability analysis and mitigation

CVE-2026-115889 is a critical sandbox escape vulnerability in Wasmtime, a WebAssembly runtime developed by the Bytecode Alliance, caused by a numeric truncation error in the Cranelift compiler backend. The Cranelift backend bit-packs SSA (Static Single Assignment) value indices into a u64 using only 24-bit fields, which can silently overflow in release builds when compiling sufficiently large or specially crafted Wasm functions with many SSA values. This overflow causes Cranelift to reference incorrect IR values, enabling arbitrary miscompilation, type confusion, and WebAssembly sandbox escape on any architecture using the default Cranelift backend. Affected versions are all Wasmtime releases prior to 36.0.19 and versions 37.0.0 through 42.x (prior to 43.0.0). The vulnerability was published on October 23, 2026, and carries a CVSS v3.1 base score of 9.9 (Critical) (GitHub Advisory).

The root cause is a numeric truncation error (CWE-197) in Cranelift's ValueDataPacked struct, which previously encoded SSA value indices (x and y) as 24-bit fields within a packed u64. When a Wasm function contains more SSA values than fit in 24 bits, the index silently overflows in release builds (where debug_assert! checks are disabled), causing Cranelift to reference wrong IR values — a form of type confusion (CWE-843). An attacker can craft or submit a Wasm module with a very large function body or many SSA values to trigger this overflow, leading to arbitrary miscompilation of the Wasm code. The fix, implemented in PR #12613, expands the ValueDataPacked layout from | tag:2 | type:14 | x:24 | y:24 | in a u64 to | tag:2 | type:14 | in a u16 with separate full u32 fields for x and y, supporting the complete Value (u32) index range with explicit bounds checks (GitHub Advisory, PR #12613).

Successful exploitation allows an attacker who can supply a crafted Wasm module to a Wasmtime engine to escape the WebAssembly sandbox and achieve arbitrary code execution on the host system. The impact spans full confidentiality, integrity, and availability compromise of the host process and potentially the underlying system, since the sandbox isolation guarantee — Wasmtime's primary security boundary — is completely broken. Any service or platform that accepts and executes untrusted Wasm modules using Wasmtime with default settings (Cranelift backend) on any architecture is at risk, including cloud functions, plugin systems, and server-side Wasm runtimes (GitHub Advisory).

There is no public proof-of-concept exploit and no confirmed in-the-wild exploitation as of the time of disclosure (Feedly). The EPSS score is 0.0, reflecting the current absence of observed exploitation activity. The vulnerability requires low privileges (an authenticated or low-privilege user able to submit Wasm modules) and no user interaction, with network-accessible attack vectors, making it attractive for future exploitation in multi-tenant Wasm hosting environments. It has not been added to the CISA KEV catalog at this time (GitHub Advisory).

1. Identify a target: Locate a service or application running Wasmtime versions prior to 36.0.19 or between 37.0.0 and 42.x that accepts and executes user-supplied Wasm modules (e.g., a cloud function platform, plugin host, or Wasm-as-a-service endpoint).
2. Craft a malicious Wasm module: Construct a Wasm function body that generates an extremely large number of SSA values — exceeding the 24-bit field limit (more than ~16 million SSA values) — or is specially crafted to cause the ValueDataPacked index fields to overflow when compiled by Cranelift in release mode.
3. Submit the Wasm module: Upload or send the crafted .wasm file to the target Wasmtime engine via whatever interface is exposed (API endpoint, file upload, RPC call, etc.).
4. Trigger miscompilation: When Wasmtime compiles the module using the Cranelift backend, the SSA value index overflow causes Cranelift to reference incorrect IR values, resulting in arbitrary miscompilation of the generated native code.
5. Achieve sandbox escape: The miscompiled native code executes with attacker-influenced behavior outside the Wasm sandbox constraints, potentially enabling arbitrary code execution in the host process context (GitHub Advisory, PR #12613).

• File System: Presence of unusually large .wasm files submitted to the application, particularly those with function bodies containing an abnormally high number of local variables or SSA values.
• Logs: Application or runtime logs showing Wasmtime compilation of Wasm modules with very large function bodies; unexpected panics or errors from Cranelift IR processing in debug builds (note: overflow is silent in release builds).
• Process: Unexpected child processes or system calls originating from the Wasmtime host process following Wasm module compilation; anomalous memory access patterns or crashes in the Wasmtime runtime process.
• Network: Unusual or oversized Wasm module uploads to endpoints that accept Wasm input, especially from untrusted or external sources.

The primary remediation is to upgrade Wasmtime to version 36.0.19 (for users on the 36.x release branch) or 43.0.0 or later (recommended for all users), both of which contain the fix (GitHub Advisory, PR #14818). In Wasmtime v43+, Cranelift was updated to use a full u32 index with explicit overflow checks, permanently eliminating the vulnerable code path. As a temporary workaround if upgrading is not immediately possible, restrict the ability to load untrusted or externally-supplied Wasm modules into Wasmtime engines, and apply strict input validation on Wasm module size and complexity. There is no configuration option to disable the vulnerable Cranelift backend without replacing the entire compilation pipeline.

The advisory was published by Bytecode Alliance maintainer pchickey on October 19, 2026, with credit to reporter jaydns, and was included as part of a broader security release (36.0.19) that also addressed two other CVEs (GitHub Advisory). The vulnerability was picked up by security aggregators including The Hacker Wire, VulDB, and OSV, and generated discussion on Mastodon and Bluesky within hours of disclosure. The RUSTSEC advisory database (RUSTSEC-2026-0380) also tracked the issue, prompting dependency update PRs across several downstream Rust projects including risingwave, smoldot, and krustlet (PR #12613).