CVE-2026-35186

Workaround

There are no workarounds within the Winch compiler backend while using the affected versions. Users of Wasmtime are encouraged either to upgrade to patched versions or, if that is not possible, use the Cranelift compiler backend.

Wasmtime's Winch compiler backend contains a bug where translating the table.grow operator causes the result to be incorrectly typed. For 32-bit tables this means that the result of the operator, internally in Winch, is tagged as a 64-bit value instead of a 32-bit value. This invalid internal representation of Winch's compiler state compounds into further issues depending on how the value is consumed.

One example can be seen when the result of table.grow is used as the address of a load operation. The load operation is tricked into thinking the address is a 64-bit value, not a 32-bit value, which means that the final address to load from is calculated incorrectly. This can lead to a situation where the bytes before the start of linear memory can be loaded/stored to.

The primary consequence of this bug is that bytes in the host's address space can be stored/read from. This is only applicable to the 16 bytes before linear memory, however, as the only significant return value of table.grow that can be misinterpreted is -1. The bytes before linear memory are, by default, unmapped memory. Wasmtime will detect this fault and abort the process, however, because wasm should not be able to access these bytes.

Overall this this bug in Winch represents a DoS vector by crashing the host process, a correctness issue within Winch, and a possible leak of up to 16-bytes before linear memory. Wasmtime's default compiler is Cranelift, not Winch, and Wasmtime's default settings are to place guard pages before linear memory. This means that Wasmtime's default configuration is not affected by this issue, and when explicitly choosing Winch Wasmtime's otherwise default configuration leads to a DoS. Disabling guard pages before linear memory is required to possibly leak up to 16-bytes of host data.

Kodem intelligence

Wasmtime 43.0.1, 42.0.2, and 36.0.7 have been released with fixes for this issue.

1. What is CVE-2026-35186? CVE-2026-35186 is a medium-severity security vulnerability in wasmtime (rust), affecting versions >= 25.0.0, < 36.0.7. It is fixed in 36.0.7, 42.0.2, 43.0.1.
2. Which versions of wasmtime are affected by CVE-2026-35186? wasmtime (rust) versions >= 25.0.0, < 36.0.7 is affected.
3. Is there a fix for CVE-2026-35186? Yes. CVE-2026-35186 is fixed in 36.0.7, 42.0.2, 43.0.1. Upgrade to this version or later.
4. Is CVE-2026-35186 exploitable, and should I be worried? Whether CVE-2026-35186 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether CVE-2026-35186 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix CVE-2026-35186?
   • Upgrade wasmtime to 36.0.7 or later
   • Upgrade wasmtime to 42.0.2 or later
   • Upgrade wasmtime to 43.0.1 or later