CVE-2026-34945: Host Stack Memory Leak via Type Confusion in Wasmtime Winch Compiler

CVE-2026-34945 describes a low-severity information disclosure vulnerability within the Wasmtime runtime, specifically isolated to the Winch baseline compiler backend. The flaw is rooted in an incorrect numeric type conversion (CWE-681) triggered when evaluating table sizes under specific, non-default runtime configurations. Exploiting this vulnerability allows a guest WebAssembly module to read up to 32 bits of uninitialized host stack memory per invocation.

The vulnerability exists because the Winch compiler makes an incorrect assumption about the return type of the WebAssembly table.size instruction. The WebAssembly specification typically defines tables with 32-bit indices, making i32 the correct return type. However, when the experimental memory64 proposal is enabled, WebAssembly modules can define tables that utilize 64-bit indices, necessitating an i64 return type.

Because the Winch instruction emitter hardcoded the return type of table.size as an i32, the compiler fails to properly write the upper 32 bits of the 64-bit stack slot allocated for the operation. This failure leaves previously written, host-originating data in the upper half of the register, exposing it to the guest context.

The root cause of CVE-2026-34945 is a static typing flaw in the Winch instruction emitter. In WebAssembly, the table.size instruction returns the current size of a designated table. Under normal execution, the Winch backend evaluates this instruction and places a 32-bit integer on the host's stack representing the table size.

When a table is instantiated with an i64 index type (a feature of the memory64 proposal), ABI requirements dictate that the compiler allocate a full 64-bit register or stack slot to store the table size. The Winch compiler successfully allocates the 64-bit space but fails to recognize the semantic width of the returned data. The emitter logic blindly populates the lower 32 bits with the table size and terminates the operation.

Because the Winch backend reuses host stack slots and registers without performing zero-initialization, the upper 32 bits of the allocated slot remain populated with stale data. This data originates from previous host-side operations. When the guest module reads the i64 result, it ingests both the valid 32-bit table size and the 32 bits of uninitialized host data.

The vulnerability resides in the visit_table_size function within winch/codegen/src/visitor.rs. In the vulnerable implementation, the Winch compiler statically assigns an i32 type to the destination register, disregarding the configuration of the table being queried.

The patch implemented in commit 96dde3aa67a5c456e4091ed60a9e3e774f0efd85 resolves this by querying the table_data object for its specific index type before allocating the typed register. This ensures the full bit-width of the target table's index type is respected during code generation.

// Vulnerable Implementation (winch/codegen/src/visitor.rs)
fn visit_table_size(&mut self, table: u32) -> Self::Output {
    // Compiler mistakenly forces i32 allocation
    self.context.stack.push(TypedReg::i32(size).into());
    Ok(())
}
 
// Patched Implementation
fn visit_table_size(&mut self, table: u32) -> Self::Output {
    // Compiler dynamically queries the table's index_type
    let dst = TypedReg::new(table_data.index_type(), size);
    self.context.stack.push(dst.into());
    Ok(())
}

The Bytecode Alliance also introduced a strict regression test in tests/misc_testsuite/winch/table64.wast to prevent recurrence. The test explicitly defines a 64-bit table (table $t i64 10 funcref) and invokes table.size multiple times to assert that an i64 is correctly handled without causing type confusion or leaking adjacent stack values.

Exploiting CVE-2026-34945 requires an attacker to supply a malicious WebAssembly module to a Wasmtime host configured to use the Winch compiler with the memory64 proposal enabled. If the host uses the default Cranelift compiler or disables experimental proposals, exploitation is impossible.

The attacker begins by defining a table with an i64 index type within the malicious guest module. The module then invokes the table.size instruction on this specific table. The Wasmtime host evaluates the instruction and places the result on the stack, returning an i64 value to the guest.

To extract the uninitialized host data, the guest module applies bitwise operations on the returned value. By shifting the returned i64 value to the right by 32 bits (i64.shr_u 32), the module isolates the upper 32 bits containing the stale host stack data. The attacker can then repeatedly execute this sequence to exfiltrate contiguous or varied slices of host memory depending on the stack frame state between calls.

CVE-2026-34945 carries a CVSS v4.0 score of 2.3, accurately reflecting its status as a low-severity flaw. The impact is limited to isolated information disclosure. The attacker gains read-only access to narrow, 32-bit slices of host stack memory, with no capability to write to host memory or influence execution flow directly.

The leaked 32 bits may contain fragments of return addresses, internal host pointers, or application data originating from earlier operations in the Wasmtime host process. While this data could theoretically assist in bypassing ASLR or mapping host memory, constructing a reliable exploit chain based solely on these unpredictable 32-bit fragments is highly complex.

The strict prerequisites significantly constrain the attack surface. Wasmtime defaults to the Cranelift compiler, and the memory64 proposal must be explicitly opted into by the host environment. Environments adhering to default configurations are completely immune to this vulnerability.

The Bytecode Alliance has issued official patches in Wasmtime versions 36.0.7, 42.0.2, and 43.0.1. Organizations utilizing the Winch compiler in production environments must upgrade to one of these fixed versions immediately to remediate the vulnerability at the compiler level.

If immediate patching is not technically feasible, operators can fully mitigate the flaw through configuration changes. The primary mitigation is to disable the memory64 proposal. Alternatively, administrators can switch the compilation backend from Winch to the default Cranelift compiler, which correctly handles 64-bit table sizes and is unaffected by this bug.

Security engineers should proactively audit deployment scripts and Wasmtime engine initializations to ensure experimental features like memory64 are only enabled when strictly necessary. Static analysis tools can also be configured to flag incoming WebAssembly modules that declare 64-bit tables (i64), adding an additional layer of defense against attempted exploitation.