CVE-2026-34971: 
Rust vulnerability analysis and mitigation

CVE-2026-34971 is a miscompilation vulnerability in Wasmtime's Cranelift compilation backend on aarch64 that enables a WebAssembly sandbox escape, allowing guest modules to perform arbitrary reads and writes of host memory. It affects Wasmtime versions 32.0.0–36.0.6, 37.0.0–42.0.1, and 43.0.0 (Rust/cargo package). The vulnerability was published on April 9, 2026, by the Bytecode Alliance via GitHub Security Advisory GHSA-jhxm-h53p-jm7w. It carries a CVSS v4 base score of 9.0 (Critical) and a CVSS v3.1 base score of 7.8 (High) (GitHub Advisory, Wasmtime Advisory).

The root cause is a miscompilation in Cranelift's aarch64 instruction selection, classified as CWE-125 (Out-of-bounds Read) and CWE-787 (Out-of-bounds Write). Specifically, when Cranelift compiles a load of the shape load(iadd(base, ishl(index, amt))) where amt is a constant, it incorrectly masks the amt value during pattern matching for instruction lowering. This causes the compiler to select an erroneous lowering rule, producing a divergence: the address used for bounds checking differs from the address actually loaded or stored. Three conditions must all be met for exploitation: (1) the guest uses 64-bit WebAssembly linear memories (Config::wasm_memory64, which is enabled by default); (2) Spectre mitigations are disabled (they are enabled by default); and (3) signals-based traps are disabled (which also disables Spectre mitigations automatically). 32-bit WebAssembly and non-aarch64 platforms are not affected (GitHub Advisory, Wasmtime Advisory).

Successful exploitation grants a malicious guest WebAssembly module an arbitrary read/write primitive over host memory, constituting a full sandbox escape. An attacker can steal sensitive data from the host process, corrupt critical host data structures, or potentially achieve complete system compromise. The impact extends beyond the WebAssembly sandbox boundary, affecting the confidentiality, integrity, and availability of the host system and any co-located workloads (GitHub Advisory, Wasmtime Advisory).

No public proof-of-concept exploit or evidence of in-the-wild exploitation has been observed as of the time of disclosure (GitHub Advisory). The EPSS score is approximately 0.014% (2nd percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires a specific non-default configuration (Spectre mitigations and signals-based traps both disabled) on an aarch64 host running 64-bit WebAssembly, which limits the practical attack surface.

1. Identify a vulnerable target: Locate an aarch64 system running Wasmtime versions 32.0.0–36.0.6, 37.0.0–42.0.1, or 43.0.0 with Spectre mitigations disabled and signals-based traps disabled, and with 64-bit WebAssembly linear memories enabled (Config::wasm_memory64).
2. Craft a malicious WebAssembly module: Author a .wasm module using 64-bit memory instructions that generates the specific load pattern load(iadd(base, ishl(index, amt))) with a constant amt value. This triggers the miscompilation in Cranelift's aarch64 backend.
3. Submit the module for execution: Deliver the crafted WebAssembly module to the target Wasmtime instance (e.g., via a web service, plugin interface, or any mechanism that accepts and executes guest Wasm modules).
4. Exploit the bounds-check divergence: The miscompiled code passes the bounds check using one address but loads/stores a different (potentially far-away) host memory address, bypassing sandbox isolation.
5. Achieve arbitrary host memory read/write: Use the divergence primitive to read sensitive host memory (e.g., secrets, keys, process data) or write to host memory to corrupt data structures, escalate privileges, or achieve further compromise (GitHub Advisory, Wasmtime Advisory).

• Process: Wasmtime process on aarch64 exhibiting unexpected memory access patterns or crashes in host memory regions outside the WebAssembly linear memory range.
• Logs: Wasmtime runtime logs showing execution of 64-bit WebAssembly modules with Spectre mitigations and signals-based traps disabled; unexpected panics or segmentation faults in the host process.
• File System: Presence of suspicious or externally supplied .wasm files using 64-bit memory instructions (memory64 proposal) on aarch64 hosts.
• Network: Unexpected outbound connections or data exfiltration from the Wasmtime host process following execution of untrusted WebAssembly modules.

Upgrade Wasmtime to one of the patched versions: 36.0.7, 42.0.2, or 43.0.1. As a temporary workaround, ensure Spectre mitigations remain enabled (the default), which prevents the vulnerable code generation path from being triggered. Additionally, disabling Config::wasm_memory64 (if not required) removes the precondition for exploitation. Avoid running untrusted WebAssembly modules on affected aarch64 Wasmtime instances until patching is complete (GitHub Advisory, Wasmtime Advisory).

The Bytecode Alliance published a security advisory blog post covering this and related Wasmtime vulnerabilities shortly after disclosure (Bytecode Alliance Blog). The Zed editor project issued a dependency update commit in response to the advisory, indicating prompt uptake in the downstream ecosystem. The vulnerability was credited to reporter shumbo with additional acknowledgment to bholley and deian (Wasmtime Advisory).