CVE-2026-34944: 
Rust vulnerability analysis and mitigation

CVE-2026-34944 is a memory access flaw in Wasmtime's Cranelift compiler affecting the f64x2.splat WebAssembly instruction on x86-64 platforms with SSE3 disabled. When compiling this instruction, Cranelift incorrectly generates code that loads 128 bits (16 bytes) instead of the expected 64 bits (8 bytes), potentially reading 8 bytes beyond the intended memory boundary. Affected versions include all Wasmtime releases prior to 24.0.7, 25.0.0–36.0.6, 37.0.0–42.0.1, and 43.0.0. Disclosed on April 9, 2026, it carries a CVSS v3.1 score of 5.7 (Medium) and a CVSS v4.0 score of 4.1 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is classified under CWE-248 (Uncaught Exception) and CWE-466 (Return of Pointer Value Outside of Expected Range). The Cranelift backend on x86-64 without SSE3 compiles the f64x2.splat operator — when operating on a value loaded from memory (e.g., via f64.load) — to a 128-bit load instead of the correct 64-bit load, overreading by up to 8 bytes. The behavior varies by configuration: with guard pages enabled and signals-based-traps disabled, the overread hits an unmapped guard page and causes an uncaught segfault that terminates the host process (the security-relevant case); with guard pages enabled and signals-based-traps enabled (Wasmtime's default), the segfault is caught and handled as a WebAssembly trap (not a security issue); with guard pages disabled, out-of-sandbox data may be loaded into a register's upper bits, but this data is not accessible to WebAssembly guests (GitHub Advisory).

The primary security impact is a denial-of-service (DoS) condition: a malicious WebAssembly guest can trigger an uncaught segmentation fault that aborts the host process when Wasmtime is configured with signals-based-traps disabled and guard pages enabled. There is no confidentiality or integrity impact — out-of-sandbox data that may be incidentally loaded is not visible to WebAssembly guests and would require an additional, currently unknown Cranelift bug to be exposed. Wasmtime's default configuration is not affected by the security-relevant case (GitHub Advisory, Red Hat Bugzilla).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of disclosure (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.006%, reflecting very low probability of exploitation in the near term. Exploitation requires low privileges, active user interaction, and a non-default Wasmtime configuration (signals-based-traps disabled), significantly limiting the practical attack surface.

1. Identify a target: Locate a service or application running a vulnerable version of Wasmtime (prior to 24.0.7, 36.0.7, 42.0.2, or 43.0.1) on an x86-64 host where SSE3 is disabled and signals-based-traps are disabled in the Wasmtime configuration.
2. Craft a malicious WebAssembly module: Create a .wasm binary that uses the f64x2.splat instruction operating on a value loaded from near the boundary of a WebAssembly linear memory segment (e.g., using f64.load at an address close to the end of allocated memory).
3. Submit the module for execution: Deliver the crafted WebAssembly module to the target Wasmtime runtime — for example, by uploading it to a service that accepts and executes user-supplied Wasm modules.
4. Trigger the overread: When Wasmtime's Cranelift backend compiles and executes the f64x2.splat instruction, it generates a 128-bit load instead of a 64-bit load, reading 8 bytes beyond the intended address into an unmapped guard page.
5. Achieve DoS: With signals-based-traps disabled, the resulting segfault is not caught, causing the host process to terminate and achieving denial of service (GitHub Advisory).

• Process: Unexpected termination of the Wasmtime host process with a segmentation fault (SIGSEGV) signal, particularly when processing WebAssembly modules containing f64x2.splat instructions.
• Logs: Crash reports or core dumps from the Wasmtime process referencing memory access violations; operating system logs (e.g., /var/log/syslog, dmesg) showing segfault entries for the Wasmtime process.
• File System: Unexpected core dump files (e.g., core, core.<pid>) generated in the working directory of the Wasmtime process following a crash.
• Network: Repeated submission of WebAssembly modules to a Wasmtime-backed service followed by service unavailability or restarts, potentially indicating DoS attempts.

Upgrade Wasmtime to one of the patched versions: 24.0.7, 36.0.7, 42.0.2, or 43.0.1 depending on the currently deployed version (GitHub Advisory). As interim mitigations: ensure signals-based-traps remain enabled (Wasmtime's default), which causes the erroneous load to be caught as a WebAssembly trap rather than an uncaught segfault; alternatively, use a non-x86-64 host or ensure SSE3 is enabled on the x86-64 host, as the bug only affects x86-64 with SSE3 disabled. There are no other known workarounds for configurations where SSE3 is unavailable (GitHub Advisory).

The Bytecode Alliance published a security advisory blog post covering this and related Wasmtime vulnerabilities shortly after disclosure (Bytecode Alliance). The Zed editor project issued a dependency update commit to address the vulnerability in their use of Wasmtime. openSUSE issued a security announcement covering the fix for their packages. No significant broader media coverage or notable researcher commentary beyond standard vulnerability tracking has been observed.