Raw vector
CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:XSummary
CVE-2026-34971 is a critical-severity Out-of-bounds Read (CWE-125) vulnerability in Bytecodealliance Wasmtime. Its CVSS base score is 9.0 (Critical).
Operationally, exploitation aligns with the MITRE ATT&CK technique Exploitation for Privilege Escalation (T1068); ranked at the 24th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.
The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.
Deeper analysis AI-assisted summary
Synthesised by an AI model from the NVD description and linked references — a reading aid, not an authoritative source.
CVE-2026-34971 affects Wasmtime, a runtime for WebAssembly, specifically its Cranelift compilation backend on aarch64 architectures. The vulnerability impacts versions from 32.0.0 up to but excluding 36.0.7, 42.0.2, and 43.0.1. It stems from a miscompilation bug during heap accesses of the form load(iadd(base, ishl(index, amt))), where amt is a constant. Cranelift incorrectly masks the amt value during instruction selection, erroneously pattern-matching a lowering rule. This causes diverging address computations: one for bounds checking and another for the actual load/store, allowing a guest WebAssembly module to access unintended addresses despite passing explicit bounds checks. The issue is limited to 64-bit WebAssembly linear memories or when Config::wasm_memory64 is enabled; 32-bit WebAssembly is unaffected. It is classified under CWE-125 (out-of-bounds read) and CWE-787 (out-of-bounds write), with a CVSS v3.1 score of 7.8 (AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H).
A local attacker with low privileges can exploit this by running a malicious guest WebAssembly module in an affected Wasmtime instance. Exploitation requires Spectre mitigations and signals-based traps to be disabled, as enabling either prevents generation of the vulnerable load shape. Under these conditions, the attacker crafts code where the bounds-checked address wraps around (e.g., to a smaller value), passing checks, while the load/store uses an unmasked, larger offset, such as one much further away. This yields an arbitrary read/write primitive on host memory, effecting a full sandbox escape as the guest bypasses isolation to access arbitrary host resources.
The Wasmtime security advisory (GHSA-jhxm-h53p-jm7w) confirms fixes in versions 36.0.7, 42.0.2, and 43.0.1. Security practitioners should update to these releases immediately. As interim mitigations, enable Spectre mitigations or signals-based traps, which disable the vulnerable compilation pattern and automatically enforce Spectre protections when signals are active.
EU & UK References
- 🇪🇺 ENISA EUVD: EUVD-2026-21027
Vulnerability Data
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…
more
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.
- CWE(s)
Related Threats
MITRE ATT&CK Enterprise Techniques
CVEs Like This One
Affected Assets
Mitigating Controls
Mitigating Controls (NIST 800-53 r5) AI
Developer testing and evaluation directly finds out-of-bounds read flaws through static analysis, fuzzing, and dynamic bounds checks.
Requiring documented secure-development standards and tools can mandate bounds-checked coding practices that avoid the weakness.
Secure engineering principles require bounds checking and memory-safe constructs that stop out-of-bounds reads from being introduced.
Process isolation confines the effects of an out-of-bounds read to the compromised process.
Input validation rejects malformed indices or lengths that would otherwise cause reads outside buffer bounds.
Memory-protection mechanisms limit the exploitability and blast radius of a successful out-of-bounds write.
Mitigating Controls (NIST CSF 2.0) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.
Secure-development practices such as bounds checking and memory-safe languages directly prevent out-of-bounds reads.
Vulnerability scanning and recording can discover instances of out-of-bounds reads after code is deployed.
Routine patching replaces vulnerable code containing out-of-bounds read flaws.
Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI
Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.
Security testing in development and acceptance includes fuzzing and static analysis that detect out-of-bounds read defects before release.
Logging can record evidence of an out-of-bounds read but does not prevent the weakness itself.
Secure development life cycle mandates input validation and bounds checking that directly prevent out-of-bounds reads.
Application security requirements include explicit bounds and memory-safety specifications that mitigate buffer over-reads.
Secure system architecture and engineering principles require memory-safe design patterns and runtime protections against out-of-bounds access.
Secure coding standards explicitly forbid unsafe pointer arithmetic and mandate bounds-checked reads, eliminating CWE-125.