CVE-2026-35186: Wasmtime Winch Compiler DoS Vulnerability

CVE-2026-35186 Overview

CVE-2026-35186 is a type confusion vulnerability in Wasmtime's Winch compiler backend that affects the translation of the table.grow operator. When processing 32-bit tables, the Winch compiler incorrectly tags the operator's result as a 64-bit value instead of a 32-bit value, leading to an invalid internal representation of the compiler state. This mistyping can compound into further issues depending on how the value is consumed, potentially enabling attackers to read or write bytes in the host's address space.

Critical Impact

This vulnerability enables potential denial of service through process crashes, correctness issues within Winch compilation, and possible leakage of up to 16 bytes of host memory data preceding linear memory.

Affected Products

• Wasmtime versions 25.0.0 through 36.0.6 (fixed in 36.0.7)
• Wasmtime versions 42.0.0 through 42.0.1 (fixed in 42.0.2)
• Wasmtime versions 43.0.0 (fixed in 43.0.1)

Discovery Timeline

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

Technical Details for CVE-2026-35186

Vulnerability Analysis

The vulnerability resides in Wasmtime's Winch compiler backend, which is an alternative to the default Cranelift compiler. During the compilation process, when the table.grow WebAssembly operator is translated for 32-bit tables, the Winch compiler incorrectly assigns a 64-bit type to what should be a 32-bit return value. This type confusion creates an inconsistent internal state within the compiler.

The mistyped value affects subsequent operations that consume this result. Specifically, the only significant return value from table.grow that can be problematically misinterpreted is -1 (indicating allocation failure). When this value is incorrectly typed as 64-bit, it can lead to memory access violations affecting the 16 bytes immediately preceding linear memory in the host's address space.

By default, Wasmtime places guard pages before linear memory, meaning these memory regions are unmapped. When WebAssembly code attempts to access these protected regions due to the type confusion, Wasmtime detects the fault and aborts the process, resulting in a denial of service condition. However, if guard pages are explicitly disabled in the configuration, an attacker could potentially leak up to 16 bytes of host memory data.

Root Cause

The root cause is a type tagging error (CWE-789) in Wasmtime's Winch compiler backend. During the translation phase of the table.grow operator, the compiler's internal type system incorrectly classifies the 32-bit return value as a 64-bit value. This fundamental type mismatch propagates through the compilation pipeline, causing subsequent memory operations to use incorrect offsets and sizes.

Attack Vector

The attack is network-accessible but requires several conditions to be met. An attacker must be able to supply WebAssembly modules that will be compiled and executed using the Winch compiler backend. The attack has high complexity because:

1. The target system must explicitly be configured to use Winch instead of the default Cranelift compiler
2. For memory disclosure beyond DoS, guard pages before linear memory must be disabled
3. The attacker must craft WebAssembly code that invokes table.grow on 32-bit tables and consumes the result in a way that triggers the type confusion

When successful, the vulnerability can cause process termination (DoS) in default configurations, or potentially leak small amounts of host memory when guard pages are disabled.

Detection Methods for CVE-2026-35186

Indicators of Compromise

• Unexpected Wasmtime process crashes or terminations, particularly during WebAssembly module execution
• Memory access violation errors in logs referencing addresses near linear memory boundaries
• Abnormal behavior when processing WebAssembly modules that use table.grow operations
• Segmentation faults or access violations in Wasmtime processes compiled with the Winch backend

Detection Strategies

• Monitor Wasmtime processes for unexpected crashes or termination events, especially when processing untrusted WebAssembly modules
• Review application logs for memory access violations or segmentation faults originating from Wasmtime components
• Audit configuration files to identify systems explicitly using the Winch compiler backend
• Implement WebAssembly module scanning to detect heavy usage of table.grow operations in incoming modules

Monitoring Recommendations

• Establish baseline crash rates for Wasmtime processes and alert on anomalous increases
• Implement process restart monitoring to detect DoS exploitation attempts
• Log and analyze all WebAssembly compilation failures and runtime errors
• Monitor memory usage patterns for Wasmtime processes to detect potential memory leak exploitation attempts

How to Mitigate CVE-2026-35186

Immediate Actions Required

• Upgrade Wasmtime to patched versions: 36.0.7, 42.0.2, or 43.0.1 depending on your current version branch
• If unable to upgrade immediately, switch from Winch to the default Cranelift compiler backend
• Ensure guard pages before linear memory remain enabled (this is the default configuration)
• Audit systems to identify any Wasmtime deployments explicitly using the Winch compiler backend

Patch Information

The vulnerability has been addressed in multiple Wasmtime release branches. Users should upgrade to the following fixed versions based on their deployment:

• Version 36.0.7 for the 36.x release branch
• Version 42.0.2 for the 42.x release branch
• Version 43.0.1 for the 43.x release branch

For detailed patch information and security advisory, see the GitHub Security Advisory.

Workarounds

• Switch to the Cranelift compiler backend, which is Wasmtime's default and is not affected by this vulnerability
• Ensure guard pages before linear memory are enabled to limit the impact to DoS rather than potential memory disclosure
• Implement input validation to restrict or sandbox WebAssembly modules from untrusted sources
• Consider deploying Wasmtime processes in isolated environments to contain potential DoS impacts

# Configuration example - Use Cranelift instead of Winch
# When initializing Wasmtime, ensure you're using the default compiler:
# In your Wasmtime configuration, do not explicitly enable Winch
# The default compiler (Cranelift) is not affected by this vulnerability

# For Rust configurations:
# let config = Config::new();
# // Do NOT call config.strategy(Strategy::Winch)
# // Cranelift is used by default