CVE-2026-24116: 
Rust vulnerability analysis and mitigation

CVE-2026-24116 is an out-of-bounds read vulnerability in Wasmtime's Cranelift compiler affecting the f64.copysign WebAssembly instruction on x86-64 platforms with AVX support. The flaw causes Cranelift to generate machine code that loads 128 bits (16 bytes) instead of the expected 64 bits (8 bytes) from memory, potentially reading 8 bytes beyond the intended buffer. Affected versions span from 29.0.0 through versions prior to 36.0.5, 40.0.3, and 41.0.1 (specifically: >=29.0.0 <36.0.5, >=37.0.0 <40.0.3, and =41.0.0). The vulnerability was disclosed on January 27, 2026, and carries a CVSS v3.1 score of 5.5 (Medium) and a CVSS v4.0 score of 4.1 (Medium) (Github Advisory, GitHub Advisory Database).

The root cause (CWE-125: Out-of-bounds Read) lies in Cranelift's load-sinking optimization on x86-64 with AVX. The fcopysign operator is implemented using vector bitwise AND instructions (andps/andpd), which operate on 128-bit XMM registers. When load-sinking automatically folds an f64.load operand directly into the andps/andpd instruction, it incorrectly widens the 64-bit scalar load to a 128-bit vector load. The fix, applied in cranelift/codegen/src/isa/x64/lower.isle, forces operands into registers before the bitwise operation to prevent the erroneous load widening. The behavior varies by configuration: with guard pages enabled and signals-based-traps disabled, the widened load hits an unmapped guard page and causes an uncaught segfault (DoS); with guard pages disabled, out-of-sandbox data may be loaded into the high (unused) lane of an XMM register but is not directly accessible to WebAssembly guests (Github Advisory, Patch Commit 40.0).

The primary security impact is a denial-of-service condition: a malicious WebAssembly guest can craft a module using f64.copysign combined with f64.load near a memory boundary to trigger an uncaught segfault, aborting the host process. This requires Wasmtime to be configured with guard pages enabled and signals-based-traps disabled — a non-default configuration. In the default Wasmtime configuration (signals-based-traps enabled), the widened load causes an incorrect but safely caught WebAssembly trap with no security impact. There is no known path to arbitrary code execution, data exfiltration visible to the guest, or integrity compromise (Github Advisory).

No public proof-of-concept exploit code is known, and there is no evidence of in-the-wild exploitation as of the disclosure date (GitHub Advisory Database). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. The EPSS score is approximately 0.011% (1st percentile), indicating a very low probability of near-term exploitation. Exploitation requires local access, low privileges, active user interaction, and a specific non-default Wasmtime configuration (signals-based-traps disabled), significantly limiting the attack surface.

1. Identify a vulnerable target: Confirm the target is running Wasmtime on an x86-64 host with AVX support, using a version between 29.0.0 and prior to 36.0.5, 40.0.3, or 41.0.1, and that signals_based_traps is disabled in the Wasmtime configuration.
2. Craft a malicious WebAssembly module: Create a .wasm module that defines a linear memory with at least one page, then executes an f64.load from an address near the end of the accessible memory region (e.g., within 8 bytes of the guard page boundary), immediately followed by f64.copysign.
3. Trigger the widened load: When Cranelift compiles the module, the load-sinking optimization folds the f64.load into the andpd instruction, generating a 128-bit load instead of 64-bit. At runtime, this reads 8 bytes beyond the valid region into the unmapped guard page.
4. Cause process termination: Because signals-based-traps are disabled, no signal handler catches the resulting SIGSEGV, and the host process is terminated — achieving denial of service (Github Advisory, Patch Commit 40.0).

• Process: Unexpected termination of the Wasmtime host process with a segmentation fault (SIGSEGV) signal, particularly when executing WebAssembly modules containing f64.copysign combined with f64.load near memory boundaries.
• Logs: Operating system crash logs or core dumps referencing the Wasmtime process with a fault address in the guard page region (typically just beyond the WebAssembly linear memory allocation).
• File System: Presence of core dump files (core, core.<pid>) generated by the Wasmtime process in the working directory or system core dump location.
• Network: Repeated connection drops or service unavailability from applications hosting Wasmtime, consistent with process crashes triggered by specific WebAssembly inputs.

Upgrade to one of the patched Wasmtime releases: 36.0.5, 40.0.3, or 41.0.1 (all released January 26, 2026). Users on unsupported major versions (e.g., 37.x–39.x) should migrate to a supported major version that has a patch available. As an immediate workaround, enable signals-based-traps in the Wasmtime configuration (Config::signals_based_traps(true)), which ensures the erroneous load is caught as a WebAssembly trap rather than an uncaught segfault. Disabling guard pages is explicitly not recommended as a mitigation, as guard pages are a critical defense-in-depth measure (Github Advisory, GitHub Advisory Database).

The vulnerability was reported by security researcher louismerlin and credited in all patch commits and the official advisory (Github Advisory). The Bytecode Alliance published a detailed advisory authored by cfallin on January 27, 2026, clearly delineating the three behavioral scenarios based on Wasmtime configuration. The advisory was also published to the RustSec advisory database as RUSTSEC-2026-0006, reflecting the Rust ecosystem's standard vulnerability disclosure process (RustSec Advisory). Community reaction has been measured given the limited exploitability under default configurations.