CVE-2026-34987 is a critical flaw in Wasmtime's Winch compiler backend. NVD scores it 9.9. Specially built guest WebAssembly can reach host memory outside its sandbox. Only builds using Winch are affected. Upgrade to Wasmtime 36.0.7, 42.0.2 or 43.0.1. Check for Winch use before you rank this in your queue.
What's affected
Wasmtime from 25.0.0 up to 36.0.6, from 37.0.0 up to 42.0.1, and 43.0.0. Patched versions are 36.0.7, 42.0.2 and 43.0.1.
The flaw needs the Winch baseline compiler, selected with the compiler option set to winch. By default Wasmtime uses Cranelift, so default configurations are not affected, according to the advisory.
How to check if you're exposed
Find the Wasmtime version you use:
cargo tree -i wasmtime
wasmtime --version
Then check whether anything selects Winch. Search your code and configuration for the compiler strategy setting and for the command line flag. Embedding applications may set it through the Config API.
If Winch is not selected anywhere, the advisory says the issue does not apply to you, though upgrading remains sensible.
What to do now
- Upgrade Wasmtime to 36.0.7, 42.0.2 or 43.0.1, matching your current major line, and rebuild.
- Until then, switch from Winch to the default Cranelift backend if your performance needs allow.
- Do not run untrusted guest modules on builds that use Winch and are not patched.
- Check language bindings and tools that embed Wasmtime, since they carry their own copy.
Why it matters
The weaknesses are CWE-125 (out of bounds read) and CWE-787 (out of bounds write). The advisory says the compiler made an incorrect assumption when it generated code, so a guest could access memory before or after the linear memory region, whatever guard region settings were in use.
The advisory notes an observed working proof of concept on aarch64, while the x86-64 case is theoretical and may not be reachable in practice. A WebAssembly runtime exists to contain untrusted code, so a hole in that wall is serious wherever you run third party modules.
The record does not flag this CVE as listed in CISA's Known Exploited Vulnerabilities catalog.
If you run third party WebAssembly modules, the sandbox is the product you rely on. Keep a list of the services that embed Wasmtime, which compiler they use, and who owns the upgrade. Reachability matters here: a service that never selects Winch has a very different risk from one that does, and the list lets you answer that quickly.
Try it yourself
Whether a code path is used decides how urgent a fix is. This demo shows how reachability changes the ranking.
Click through it at your own pace, or open it full screen.
Quick check
Am I affected if I use the default compiler?
The advisory says Wasmtime uses Cranelift by default and the bug requires Winch, so default setups are not affected.
How do I find embedded copies?
Look at lock files for the wasmtime crate and at language bindings that bundle it. A dependency scan lists them for you.
Sources
Last reviewed: 19 October 2026.
