CVE-2026-34971 — wasmtime
CVE-2026-34971 is a Out-of-bounds Read vulnerability in wasmtime. A fix is available for wasmtime — see the affected versions and patch details below.
Wasmtime miscompiled guest heap access enables sandbox escape on aarch64 Cranelift
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-34971.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
wasmtime🦀wasmtime🦀wasmtimeReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
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.
Patches
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.
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | wasmtime | ≥ 32.0.0&&< 36.0.7 | 36.0.7cargo update -p wasmtime --precise 36.0.7 |
| 🦀crates.io | wasmtime | ≥ 37.0.0&&< 42.0.2 | 42.0.2cargo update -p wasmtime --precise 42.0.2 |
| 🦀crates.io | wasmtime | ≥ 43.0.0&&< 43.0.1 | 43.0.1cargo update -p wasmtime --precise 43.0.1 |
Affected Products
wasmtimebytecodeallianceDetection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for wasmtime, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update wasmtime to 36.0.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-34971 is resolved across your whole dependency graph.
Workarounds
Constrain what reaches the vulnerable code: limit the size and shape of untrusted input, isolate the affected component in a sandboxed or least-privileged process, and enable the platform's memory-safety mitigations (ASLR, stack protector, hardened allocator) so an out-of-bounds access is more likely to fail closed than to be exploitable.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
The requirement that Spectre mitigations be disabled is a non-default state for Red Hat products and is highly discouraged. No Red Hat product in its default configuration is vulnerable to this flaw.
Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base or stability.Source: Red Hat security advisory for CVE-2026-34971 (CC BY 4.0)
Frequently Asked Questions
Is CVE-2026-34971 in your dependencies?
Find it across crates.io, including transitive dependencies.