Wasmtime miscompiled guest heap access enables sandbox escape on aarch64 Cranelift
Key facts
- Attack vector
- Network
- Privileges required
- Low
- User interaction
- None
- Attack complexity
- Low
- Attack requirements
- Present
- Impact type
- Code execution
- Confidentiality · integrity · availability
- High · High · High
- Fix status
- Partial Red Hat: 1 without a fix
Attack profile from CVSS 4.0 · CNA. Fix status from CNA, GitHub and Red Hat. Impact type from CWE-787 and the CVSS impact.
Summary
Wasmtime is a runtime for WebAssembly. From 32.0.0 to before 36.0.7, 42.0.2, and 43.0.1, 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_memory64 is 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. This vulnerability is fixed in 36.0.7, 42.0.2, and 43.0.1.
Why it matters now
SSVC decision points
CISA ADP · SSVC 2.0.3
- Exploitation
- None
- Automatable
- No
- Technical impact
- Total
The decision (Track, Attend, Act) also depends on your mission and well-being impact; see CISA's SSVC guide.
Affected products
| Vendor | Product | Affected versions | Fixed in | Status | Source |
|---|---|---|---|---|---|
| bytecodealliance | wasmtime | 32.0.0 to before 36.0.7; 37.0.0 to before 42.0.2; 43.0.0 to before 44.0.1 | 36.0.7, 42.0.2, 44.0.1 | Patch available | CNA |
| — | wasmtime (crates.io) | 32.0.0 to before 36.0.7 | 36.0.7 | Patch available | GHSA-jhxm-h53p-jm7w |
| — | wasmtime (crates.io) | 37.0.0 to before 42.0.2 | 42.0.2 | Patch available | GHSA-jhxm-h53p-jm7w |
| — | wasmtime (crates.io) | 43.0.0 to before 43.0.1 | 43.0.1 | Patch available | GHSA-jhxm-h53p-jm7w |
- wasmtime Vendorbytecodealliance Affected 32.0.0 to before 36.0.7; 37.0.0 to before 42.0.2; 43.0.0 to before 44.0.1 Fixed in 36.0.7, 42.0.2, 44.0.1 Patch available CNA
- wasmtime (crates.io) Vendor— Affected 32.0.0 to before 36.0.7 Fixed in 36.0.7 Patch available GHSA-jhxm-h53p-jm7w
- wasmtime (crates.io) Vendor— Affected 37.0.0 to before 42.0.2 Fixed in 42.0.2 Patch available GHSA-jhxm-h53p-jm7w
- wasmtime (crates.io) Vendor— Affected 43.0.0 to before 43.0.1 Fixed in 43.0.1 Patch available GHSA-jhxm-h53p-jm7w
CPE configurations NVD · 2
| CPE | Versions | Role | Vendor |
|---|---|---|---|
| cpe:2.3:a:bytecodealliance:wasmtime:*:*:*:*:*:rust:*:* | 32.0.0 to before 36.0.7; 37.0.0 to before 42.0.2 | Vulnerable | bytecodealliance |
| cpe:2.3:a:bytecodealliance:wasmtime:43.0.0:*:*:*:*:rust:*:* | 43.0.0 | Vulnerable | bytecodealliance |
- cpe:2.3:a:bytecodealliance:wasmtime:*:*:*:*:*:rust:*:* Versions 32.0.0 to before 36.0.7; 37.0.0 to before 42.0.2 Vulnerable ·bytecodealliance
- cpe:2.3:a:bytecodealliance:wasmtime:43.0.0:*:*:*:*:rust:*:* Versions 43.0.0 Vulnerable ·bytecodealliance
Remediation
- Fix · CNA wasmtime (bytecodealliance) Fixed in 36.0.7, 42.0.2, 44.0.1
- Fix · GHSA-jhxm-h53p-jm7w wasmtime (crates.io) Fixed in 36.0.7 Advisory →
- Fix · GHSA-jhxm-h53p-jm7w wasmtime (crates.io) Fixed in 42.0.2 Advisory →
- Fix · GHSA-jhxm-h53p-jm7w wasmtime (crates.io) Fixed in 43.0.1 Advisory →
Vendor assessments
Red Hat
Red Hat rating: Important. Red Hat's page for this CVE →
| Product | Status | Plan or fix |
|---|---|---|
| Red Hat Connectivity Link 1 | Affected | No fix yet |
Not affected: 1 product
- Red Hat Enterprise Linux 10
Timeline
- 2026-10-02 Threatist record created from CVE-2026-34971
- 2026-10-03 Alias added: GHSA-jhxm-h53p-jm7w
References
More bytecodealliance Wasmtime vulnerabilities
- TI-2026-21632 Wasmtime is vulnerable to panic when dropping a `[Typed]Func::call_async` future CVSS 4.0MEDIUM 6.9
- TI-2023-11636 Guest-controlled out-of-bounds read/write on x86_64 in wasmtime CVSS 3.1CRITICAL 10.0
- TI-2022-18765 Wasmtime vulnerable to data leakage between instances in the pooling allocator CVSS 3.1HIGH 8.6
- TI-2022-08604 Use after free in Wasmtime CVSS 3.1CRITICAL 9.8
- TI-2022-18766 wasmtime_trap_code C API function has out of bounds write vulnerability CVSS 3.1CRITICAL 9.8
- TI-2026-27209 Wasmtime with Winch compiler backend on aarch64 may allow a sandbox-escaping memory access CVSS 4.0CRITICAL 9.0
Sources
- CVE-2026-34971 · CVE Program
- CVE-2026-34971 · NVD
- FIRST EPSS
- GHSA-jhxm-h53p-jm7w · GitHub Advisory Database · CC BY 4.0
- CVE-2026-34971 · Red Hat security data · CC BY 4.0
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences