CVE-2026-34971: CWE-125: Out-of-bounds Read in bytecodealliance wasmtime
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.
AI Analysis
Technical Summary
Wasmtime's Cranelift backend on aarch64 contains a bug in versions >=32.0.0 and <36.0.7, >=37.0.0 and <42.0.2, and >=43.0.0 and <44.0.1 that causes incorrect address computation during certain heap accesses. This bug arises from a miscompile of a load instruction pattern involving a shifted index, where an incorrect mask leads to loading from an unintended address. When combined with explicit bounds checks, this discrepancy allows a guest WebAssembly module to pass bounds checks but access different memory addresses, enabling arbitrary read/write access to host memory and sandbox escape. The issue only manifests on 64-bit WebAssembly linear memories or when wasm_memory64 is enabled, and requires Spectre mitigations or signals-based traps to be disabled. The vulnerability is resolved in Wasmtime versions 36.0.7, 42.0.2, and 43.0.1.
Potential Impact
This vulnerability allows a guest WebAssembly module to bypass sandbox restrictions and perform arbitrary reads and writes to host memory, potentially leading to host compromise. The impact is critical due to the ability to escape the sandbox and manipulate host memory arbitrarily. However, exploitation requires specific conditions including use of 64-bit WebAssembly memory, disabled Spectre mitigations or signals-based traps, and running on affected Wasmtime versions.
Mitigation Recommendations
A fix for this vulnerability is available in Wasmtime versions 36.0.7, 42.0.2, and 43.0.1. Users should upgrade to one of these versions or later to remediate the issue. If upgrading is not immediately possible, ensure that Spectre mitigations and signals-based traps are enabled, as these prevent the vulnerable code pattern from being generated. Patch status is confirmed fixed in the specified versions; no other official remediation level is indicated.
CVE-2026-34971: CWE-125: Out-of-bounds Read in bytecodealliance wasmtime
Description
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.
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
Wasmtime's Cranelift backend on aarch64 contains a bug in versions >=32.0.0 and <36.0.7, >=37.0.0 and <42.0.2, and >=43.0.0 and <44.0.1 that causes incorrect address computation during certain heap accesses. This bug arises from a miscompile of a load instruction pattern involving a shifted index, where an incorrect mask leads to loading from an unintended address. When combined with explicit bounds checks, this discrepancy allows a guest WebAssembly module to pass bounds checks but access different memory addresses, enabling arbitrary read/write access to host memory and sandbox escape. The issue only manifests on 64-bit WebAssembly linear memories or when wasm_memory64 is enabled, and requires Spectre mitigations or signals-based traps to be disabled. The vulnerability is resolved in Wasmtime versions 36.0.7, 42.0.2, and 43.0.1.
Potential Impact
This vulnerability allows a guest WebAssembly module to bypass sandbox restrictions and perform arbitrary reads and writes to host memory, potentially leading to host compromise. The impact is critical due to the ability to escape the sandbox and manipulate host memory arbitrarily. However, exploitation requires specific conditions including use of 64-bit WebAssembly memory, disabled Spectre mitigations or signals-based traps, and running on affected Wasmtime versions.
Mitigation Recommendations
A fix for this vulnerability is available in Wasmtime versions 36.0.7, 42.0.2, and 43.0.1. Users should upgrade to one of these versions or later to remediate the issue. If upgrading is not immediately possible, ensure that Spectre mitigations and signals-based traps are enabled, as these prevent the vulnerable code pattern from being generated. Patch status is confirmed fixed in the specified versions; no other official remediation level is indicated.
Technical Details
- Data Version
- 5.2
- Assigner Short Name
- GitHub_M
- Date Reserved
- 2026-03-31T19:38:31.616Z
- Cvss Version
- 4.0
- State
- PUBLISHED
- Remediation Level
- null
Threat ID: 69d7f88c1cc7ad14da0c1700
Added to database: 4/9/2026, 7:05:48 PM
Last enriched: 4/17/2026, 11:52:37 AM
Last updated: 5/25/2026, 12:22:41 PM
Views: 108
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
External Links
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.