CVE-2026-35186
Winch Compiler Bug in Wasmtime Causes DoS and Data Leak
Publication date: 2026-04-09
Last updated on: 2026-04-15
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| bytecodealliance | wasmtime | From 25.0.0 (inc) to 36.0.7 (exc) |
| bytecodealliance | wasmtime | From 37.0.0 (inc) to 42.0.2 (exc) |
| bytecodealliance | wasmtime | 43.0.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-789 | The product allocates memory based on an untrusted, large size value, but it does not ensure that the size is within expected limits, allowing arbitrary amounts of memory to be allocated. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability primarily causes a denial-of-service (DoS) condition by crashing the host process and may lead to a minor information leak of up to 16 bytes of host memory if guard pages are disabled. The confidentiality and integrity impacts are low, while availability impact is high.
Given the limited confidentiality impact and the small potential data leak, the vulnerability may have minimal direct effect on compliance with standards like GDPR or HIPAA, which focus heavily on protecting personal and sensitive data. However, any data leakage, even small, could be relevant under these regulations depending on the context of use.
The main compliance concern would be the availability impact due to DoS, which could affect service reliability and availability requirements under certain regulations.
Can you explain this vulnerability to me?
This vulnerability exists in Wasmtime's Winch compiler backend for WebAssembly versions from 25.0.0 up to before 36.0.7, 42.0.2, and 43.0.1. It is caused by an incorrect internal typing of the result of the table.grow operator for 32-bit tables, where the result is mistakenly treated as a 64-bit value instead of a 32-bit value.
This incorrect typing corrupts the compiler state and leads to further errors when the result is used, such as miscalculating memory addresses during load operations. This can cause access to up to 16 bytes before the start of linear memory, which are typically unmapped.
When Wasmtime detects access to these unmapped bytes, it aborts the process, resulting in a denial-of-service (DoS) condition. The vulnerability also represents a correctness flaw in the Winch backend and a potential minor information leak if guard pages before linear memory are disabled.
By default, Wasmtime uses the Cranelift compiler backend and places guard pages before linear memory, so default configurations are not affected. The issue only arises when explicitly using the Winch backend with default settings or when guard pages are disabled.
The vulnerability is fixed in Wasmtime versions 36.0.7, 42.0.2, and 43.0.1.
How can this vulnerability impact me? :
The primary impact of this vulnerability is a denial-of-service (DoS) condition caused by the host process aborting when invalid memory access is detected.
Additionally, there is a potential for a minor information leak of up to 16 bytes of host memory before linear memory if guard pages are disabled.
The vulnerability also represents a correctness issue within the Winch compiler backend, which could lead to unexpected behavior or crashes.
However, if you are using Wasmtime's default configuration with the Cranelift backend and guard pages enabled, you are not affected by this vulnerability.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability manifests as a denial-of-service (DoS) condition caused by Wasmtime aborting the process when it detects invalid memory access due to the Winch compiler backend bug.
Detection can involve monitoring for unexpected Wasmtime process crashes or aborts when running WebAssembly modules compiled with the Winch backend.
Since the issue is internal to the Wasmtime runtime and its Winch backend, there are no specific network commands or signatures to detect exploitation externally.
To detect if your Wasmtime installation uses the vulnerable Winch backend, you can check the Wasmtime version and configuration.
- Run `wasmtime --version` to determine the version; versions from 25.0.0 up to but not including 36.0.7, 42.0.2, or 43.0.1 are vulnerable.
- Check if the Winch backend is explicitly enabled in your Wasmtime configuration or command line, as the default is Cranelift.
No specific commands are provided in the available resources to detect exploitation attempts or memory leaks caused by this vulnerability.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation is to upgrade Wasmtime to a fixed version: 36.0.7, 42.0.2, or 43.0.1 or later.
If upgrading is not immediately possible, switch from the vulnerable Winch compiler backend to the default Cranelift backend, which is not affected by this issue.
Ensure that guard pages before linear memory are enabled, as disabling them can increase the risk of data leakage.
No workarounds exist within the Winch backend on affected versions, so avoiding use of Winch until patched is recommended.