Summary
Workarounds
This bug only affects users of Cranelift on aarch64. Cranelift on other platforms is not affected. Additionally this only affects 64-bit WebAssembly linear memories, so if Config::wasm_memory64 is disabled then hosts are not affected. Note that Config::wasm_memory64 is enabled by default. If spectre mitigations are enabled, which are enabled by default, then hosts are not affected by this issue.
Impact
Wasmtime's Cranelift compilation backend contains a bug on aarch64 when performing a certain shape of heap accesses which means that the wrong address is accessed. When combined with explicit bounds checks a guest WebAssembly module this can create a situation where there are two diverging computations for the same address: one for the address to bounds-check and one for the address to load. This difference in address being operated on means that a guest module can pass a bounds check but then load a different address. Combined together this enables an arbitrary read/write primitive for guest WebAssembly when accesssing host memory. This is a sandbox escape as guests are able to read/write arbitrary host memory.
This vulnerability has a few ingredients, all of which must be met, for this situation to occur and bypass the sandbox restrictions:
- This miscompiled shape of load only occurs on 64-bit WebAssembly linear memories, or when
Config::wasm_memory64is enabled. 32-bit WebAssembly is not affected. - Spectre mitigations or signals-based-traps must be disabled. When spectre mitigations are enabled then the offending shape of load is not generated. When signals-based-traps are disabled then spectre mitigations are also automatically disabled.
The specific bug in Cranelift is a miscompile of a load of the shape load(iadd(base, ishl(index, amt))) where amt is a constant. The amt value is masked incorrectly to test if it's a certain value, and this incorrect mask means that Cranelift can pattern-match this lowering rule during instruction selection erroneously, diverging from WebAssembly's and Cranelift's semantics. This incorrect lowering would, for example, load an address much further away than intended as the correct address's computation would have wrapped around to a smaller value insetad.
A read operation accesses a memory location beyond the intended buffer boundary. Typical impact: sensitive data disclosure or crash.
CVE-2026-34971 has a CVSS score of 7.8 (Critical). The vector is requires local access, low privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (36.0.7, 42.0.2, 43.0.1); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
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. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Remediation advice
Wasmtime 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update to these patched versions of Wasmtime.
Frequently Asked Questions
- What is CVE-2026-34971? CVE-2026-34971 is a critical-severity out-of-bounds read vulnerability in wasmtime (rust), affecting versions >= 32.0.0, < 36.0.7. It is fixed in 36.0.7, 42.0.2, 43.0.1. A read operation accesses a memory location beyond the intended buffer boundary.
- How severe is CVE-2026-34971? CVE-2026-34971 has a CVSS score of 7.8 (Critical). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of wasmtime are affected by CVE-2026-34971? wasmtime (rust) versions >= 32.0.0, < 36.0.7 is affected.
- Is there a fix for CVE-2026-34971? Yes. CVE-2026-34971 is fixed in 36.0.7, 42.0.2, 43.0.1. Upgrade to this version or later.
- Is CVE-2026-34971 exploitable, and should I be worried? Whether CVE-2026-34971 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
- What actually determines whether CVE-2026-34971 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.
- How do I fix CVE-2026-34971?
- Upgrade
wasmtimeto 36.0.7 or later - Upgrade
wasmtimeto 42.0.2 or later - Upgrade
wasmtimeto 43.0.1 or later
- Upgrade