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 versions >=32.0.0 and <36.0.7, >=37.0.0 and <42.0.2, and >=43.0.0 and <44.0.1 contain a critical vulnerability in the Cranelift compilation backend on aarch64. The bug involves a miscompile of a load instruction pattern (load(iadd(base, ishl(index, amt)))) where an incorrect mask causes the load address to diverge from the bounds-checked address. This discrepancy allows a guest WebAssembly module to pass bounds checks but access arbitrary host memory, enabling sandbox escape via arbitrary read/write primitives. The vulnerability only manifests with 64-bit WebAssembly linear memories or wasm_memory64 enabled, and when Spectre mitigations or signals-based traps are disabled. The issue is resolved in versions 36.0.7, 42.0.2, and 43.0.1.
Potential Impact
This vulnerability enables a guest WebAssembly module running in Wasmtime to bypass sandbox restrictions and perform arbitrary read and write operations on host memory. This compromises the isolation guarantees of the runtime, potentially exposing sensitive host data or allowing code execution outside the intended sandbox. The impact is critical due to the ability to escape the sandbox and manipulate host memory arbitrarily.
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. Until upgraded, ensure that Spectre mitigations and signals-based traps are enabled, as these prevent the vulnerable load pattern from being generated. Patch status is not explicitly stated beyond these fixed versions; users should consult the official Wasmtime release notes or vendor advisories for the latest remediation guidance.
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 versions >=32.0.0 and <36.0.7, >=37.0.0 and <42.0.2, and >=43.0.0 and <44.0.1 contain a critical vulnerability in the Cranelift compilation backend on aarch64. The bug involves a miscompile of a load instruction pattern (load(iadd(base, ishl(index, amt)))) where an incorrect mask causes the load address to diverge from the bounds-checked address. This discrepancy allows a guest WebAssembly module to pass bounds checks but access arbitrary host memory, enabling sandbox escape via arbitrary read/write primitives. The vulnerability only manifests with 64-bit WebAssembly linear memories or wasm_memory64 enabled, and when Spectre mitigations or signals-based traps are disabled. The issue is resolved in versions 36.0.7, 42.0.2, and 43.0.1.
Potential Impact
This vulnerability enables a guest WebAssembly module running in Wasmtime to bypass sandbox restrictions and perform arbitrary read and write operations on host memory. This compromises the isolation guarantees of the runtime, potentially exposing sensitive host data or allowing code execution outside the intended sandbox. The impact is critical due to the ability to escape the sandbox and manipulate host memory arbitrarily.
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. Until upgraded, ensure that Spectre mitigations and signals-based traps are enabled, as these prevent the vulnerable load pattern from being generated. Patch status is not explicitly stated beyond these fixed versions; users should consult the official Wasmtime release notes or vendor advisories for the latest remediation guidance.
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/9/2026, 7:21:11 PM
Last updated: 4/10/2026, 8:15:52 AM
Views: 10
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.