CVE-2026-35186: 
Rust vulnerability analysis and mitigation

CVE-2026-35186 is a type confusion vulnerability in Wasmtime's Winch compiler backend, titled "Improperly masked return value from table.grow with Winch compiler backend." It affects Wasmtime versions 25.0.0 through 36.0.6, 37.0.0 through 42.0.1, and 43.0.0 — all for the Rust ecosystem. The vulnerability was published on April 9, 2026, by the Bytecode Alliance via GitHub Security Advisory GHSA-f984-pcp8-v2p7. It carries a CVSS v4.0 base score of 6.1 (Medium) from the CNA (GitHub), and a CVSS v3.1 score of 7.5 (High) as assessed by CISA-ADP (Github Advisory, Red Hat Advisory).

The root cause is a type confusion bug (CWE-843) in Winch's translation of the WebAssembly table.grow operator: for 32-bit tables, the operator's return value is internally tagged as a 64-bit value instead of a 32-bit value. When this mistyped value is subsequently used as the address of a load or store operation, the final memory address is calculated incorrectly, potentially pointing to the 16 bytes immediately before the start of linear memory in the host's address space. The only significant return value of table.grow that can be misinterpreted is -1 (indicating failure), which when sign-extended to 64 bits produces an address just before linear memory. Exploitation requires the attacker to supply a crafted WebAssembly module that uses the table.grow result as a memory address, and the host must be configured to use the Winch compiler backend (non-default); disabling guard pages before linear memory is additionally required to achieve information disclosure beyond a crash (Github Advisory, Red Hat Bugzilla).

The primary impact is a denial-of-service: when the miscalculated address falls in unmapped memory (the default configuration with guard pages enabled), Wasmtime detects the illegal access and aborts the host process, causing service disruption. Under non-default configurations where guard pages before linear memory are disabled, up to 16 bytes of host address space data immediately preceding linear memory may be read or written by the WebAssembly guest, constituting a limited information disclosure. Wasmtime's default compiler (Cranelift) and default guard page settings are not affected, so the blast radius is limited to deployments explicitly using the Winch backend (Github Advisory, Red Hat Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the time of publication (Github Advisory). The EPSS score is approximately 0.042–0.054%, placing it in the 17th percentile for exploitation likelihood within 30 days. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported. Exploitation requires the attacker to control or supply a WebAssembly module to a target running Wasmtime with the Winch backend explicitly enabled, which is a non-default and less common configuration.

1. Identify target: Locate a service or application running Wasmtime with the Winch compiler backend explicitly configured (non-default), ideally with guard pages before linear memory disabled for maximum impact.
2. Craft malicious WebAssembly module: Write a .wasm module that calls table.grow on a 32-bit table and uses the return value directly as the address operand of a load or store memory instruction.
3. Trigger type confusion: When table.grow fails (returns -1), the Winch backend incorrectly tags the result as a 64-bit value. When used as a memory address, this causes the address calculation to reference memory before the start of linear memory.
4. Achieve DoS or information disclosure: If guard pages are present (default), Wasmtime detects the out-of-bounds access and aborts the host process (DoS). If guard pages are disabled, up to 16 bytes of host memory before linear memory may be read or written by the wasm guest, potentially leaking sensitive data (Github Advisory).

• Logs: Unexpected process abort or crash logs from the Wasmtime host process, particularly with signals indicating illegal memory access (e.g., SIGSEGV or similar fault signals) when executing WebAssembly modules.
• Process: Abnormal termination of the Wasmtime runtime process triggered by execution of a WebAssembly module using table.grow with the Winch backend.
• Configuration: Presence of explicit Winch compiler backend configuration in Wasmtime deployment settings, combined with disabled guard pages before linear memory — a prerequisite for the more severe information disclosure variant.

Patches are available in Wasmtime versions 36.0.7, 42.0.2, and 43.0.1; users should upgrade to the appropriate patched release for their version branch. There are no in-place workarounds within the Winch compiler backend for affected versions. As an alternative mitigation, users who cannot immediately upgrade should switch to the Cranelift compiler backend (Wasmtime's default), which is not affected by this issue. Ensuring guard pages before linear memory remain enabled (the default) will limit the impact to DoS only, preventing any potential information disclosure (Github Advisory, Red Hat Advisory).

The Bytecode Alliance published a security advisory and blog post covering this and related Wasmtime security issues at the time of disclosure (Bytecode Alliance Blog). Red Hat tracked the issue via Bugzilla and assessed it as medium severity (Red Hat Bugzilla). OpenSUSE issued security announcements for affected package updates in their distributions. No significant independent researcher commentary or social media discussion has been identified beyond standard vulnerability aggregator coverage.