CVE-2026-34987: Wasmtime Winch Compiler RCE Vulnerability

CVE-2026-34987 Overview

CVE-2026-34987 is a critical Out-of-Bounds Read vulnerability affecting Wasmtime, a runtime for WebAssembly. The vulnerability exists in the Winch (baseline) compiler backend, which is a non-default compiler option. When using the Winch compiler, properly constructed guest WebAssembly code can access host memory outside of its designated linear-memory sandbox, potentially leading to denial of service, arbitrary data leakage, or remote code execution.

Critical Impact

This vulnerability allows WebAssembly guests using the Winch compiler to escape sandbox boundaries and access up to 32KiB before or ~4GiB after the linear-memory region, potentially enabling arbitrary memory access, host process crashes, data exfiltration, or remote code execution.

Affected Products

• Wasmtime versions 25.0.0 to before 36.0.7
• Wasmtime versions 42.0.0 to before 42.0.2
• Wasmtime versions 43.0.0 to before 43.0.1

Discovery Timeline

• 2026-04-09 - CVE CVE-2026-34987 published to NVD
• 2026-04-09 - Last updated in NVD database

Technical Details for CVE-2026-34987

Vulnerability Analysis

This vulnerability stems from an incorrect assumption in the Winch compiler backend regarding 32-bit memory offset handling within 64-bit registers. The Winch compiler incorrectly assumes that when a 32-bit memory offset is stored in a 64-bit register, the upper 32 bits will always be cleared. However, this assumption does not always hold true, creating a condition where the upper bits may contain residual data.

The impact is severe: an attacker controlling a WebAssembly guest can craft specific Wasm code that exploits this assumption to read or write memory outside the intended linear-memory sandbox. The proof-of-concept demonstrates access to 32KiB before the start of memory and approximately 4GiB after the start of memory. Since the underlying bug involves uncleared upper bits in 64-bit registers, closely related variants could potentially access truly arbitrary memory within the host process.

This vulnerability affects both aarch64 and x86-64 architectures theoretically, though the aarch64 case has a working proof-of-concept while the x86-64 case remains theoretical and may not be reachable in practice.

Root Cause

The root cause is a memory safety flaw in the Winch compiler's code generation (CWE-125: Out-of-bounds Read). The compiler generates code that assumes 32-bit memory offsets stored in 64-bit registers will have their upper 32 bits zeroed out. When this assumption fails, the resulting memory address calculation can point to locations outside the WebAssembly linear memory sandbox, bypassing both pre-guard and post-guard memory protections regardless of their configuration or size.

Attack Vector

The attack vector is network-accessible, requiring an attacker to deploy malicious WebAssembly code to a Wasmtime runtime configured to use the Winch compiler (-Ccompiler=winch). The attack requires:

1. A Wasmtime instance using the non-default Winch compiler backend
2. The ability to execute attacker-controlled WebAssembly code on the target system
3. Crafted Wasm bytecode that manipulates memory offset values to trigger the incorrect register handling

The vulnerability enables sandbox escape where the WebAssembly guest can:

• Read arbitrary host process memory (information disclosure)
• Cause segmentation faults in the host process (denial of service)
• With write primitives, potentially achieve arbitrary code execution

For detailed technical information, refer to the GitHub Security Advisory.

Detection Methods for CVE-2026-34987

Indicators of Compromise

• Unexpected segmentation faults or crashes in Wasmtime host processes
• Anomalous memory access patterns from WebAssembly modules
• Wasmtime instances configured with -Ccompiler=winch flag running untrusted Wasm code
• Unusual memory reads targeting addresses outside expected linear-memory boundaries

Detection Strategies

• Monitor for Wasmtime process crashes with memory access violations in production environments
• Audit Wasmtime configurations to identify instances using the Winch compiler backend
• Implement runtime monitoring for WebAssembly modules accessing memory outside expected boundaries
• Review application logs for unusual behavior from WebAssembly guest execution

Monitoring Recommendations

• Enable detailed crash logging for Wasmtime processes to capture memory access violations
• Implement host-level memory access monitoring for WebAssembly runtime processes
• Set up alerts for unexpected process terminations in systems running Wasmtime with Winch
• Monitor for signs of data exfiltration from hosts running WebAssembly workloads

How to Mitigate CVE-2026-34987

Immediate Actions Required

• Upgrade Wasmtime to patched versions 36.0.7, 42.0.2, or 43.0.1 immediately
• Switch from Winch compiler to the default Cranelift backend if upgrade is not immediately possible
• Audit all Wasmtime deployments for use of the -Ccompiler=winch flag
• Restrict execution of untrusted WebAssembly code until patches are applied

Patch Information

Bytecode Alliance has released security patches to address this vulnerability. The fixes are available in the following versions:

• Wasmtime 36.0.7 - Fixes the vulnerability for the 36.x release branch
• Wasmtime 42.0.2 - Fixes the vulnerability for the 42.x release branch
• Wasmtime 43.0.1 - Fixes the vulnerability for the 43.x release branch

Organizations should upgrade to the appropriate patched version for their deployment. For additional details, consult the GitHub Security Advisory.

Workarounds

• Switch to the default Cranelift compiler backend by removing the -Ccompiler=winch configuration option
• Avoid running untrusted WebAssembly code on systems using the Winch compiler
• Implement additional process isolation for Wasmtime instances executing third-party Wasm modules
• Consider using container or VM-based isolation as an additional defense layer for WebAssembly workloads

# Switch from Winch to Cranelift compiler (default)
# Remove or replace the -Ccompiler=winch flag
wasmtime run --config-option compiler=cranelift your_module.wasm

# Verify compiler backend in use
wasmtime compile --help | grep compiler