WasmtimeApplication · Bytecodealliance
CVE-2026-34971
Official description Straight from the sourceThe vendor's or NVD's own wording, published unedited. Authoritative, but often terse — it says what broke, rarely what to do.
NVD · uneditedWasmtime 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.
Technical summary Written by usOur analysis, written from the advisory, the CVSS vector and the affected-version data. It adds context the advisory leaves out, and never invents facts that are not in the source.
dbcve analysis · high confidenceWasmtime's Cranelift compilation backend on aarch64 contains a miscompile bug where heap accesses use the wrong address due to incorrect masking of a constant in the pattern load(iadd(base, ishl(index, amt))). This allows guest WebAssembly modules to bypass sandbox restrictions and read/write arbitrary host memory when spectre mitigations and signals-based-traps are disabled on 64-bit linear memories.
Verify against the referenced sources before acting — the references below are authoritative for this CVE, this summary is not.
Affected products & versions What the vendor confirmedThe version ranges the vendor confirmed as vulnerable. If your version sits inside a range here, treat yourself as exposed until you have upgraded.
NVD · CPE data
WasmtimeApplication
>= 32.0.0, < 36.0.7>= 37.0.0, < 42.0.2= 43.0.0CVSS breakdown How the score is builtThe industry scoring standard. It rates how the flaw is reached, what it takes to exploit, and what an attacker gains — the score is derived from those, not the other way round.
From the vector- Attack vector
- Local
- Complexity
- High
- Privileges
- Low
- User interaction
- None
- Scope
- Changed
- Confidentiality
- High
- Integrity
- High
- Availability
- High
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
Am I affected? How to checkSteps we derive from the advisory and the affected-version data, so you can decide whether this CVE reaches your setup. They are a guide, not a scan — your own configuration is the authority.
dbcve checksWork through these to decide whether this CVE applies to you.
-
Check system architectureRun 'uname -m' or 'arch' to confirm the system is aarch64/arm64. This vulnerability only affects Wasmtime on aarch64.Affected if The system architecture is aarch64 and Wasmtime is running on it.
-
Determine installed Wasmtime versionRun 'wasmtime --version' or check the package manager for the installed wasmtime package version.Affected if The installed version matches: >= 32.0.0 and < 36.0.7; OR >= 37.0.0 and < 42.0.2; OR exactly 43.0.0.
-
Verify Cranelift JIT is in useCheck Wasmtime configuration or logs for use of the Cranelift compilation backend. Wasmtime uses Cranelift by default; verify no alternate compiler (like Lightbeam) is explicitly configured.Affected if Cranelift is the active compilation backend (default configuration).
-
Check if Spectre mitigations are enabledInspect Wasmtime command-line flags or environment variables for '--spectre' or 'WASMTIME_SPUTTER' settings. Alternatively, check if the runtime was compiled with Spectre mitigations enabled.Affected if Spectre mitigations are NOT enabled, leaving the vulnerable code shape exposed.
A user is affected if they are running Wasmtime on aarch64 with a vulnerable version (32.0.0 through 36.0.6, 37.0.0 through 42.0.1, or exactly 43.0.0) using the Cranelift backend without Spectre mitigations enabled.
Generated from the published advisory. Verify against your own configuration.
Remediation Closing itWhat it takes to close this. Where a vendor fix exists we point at it; where none exists we say so plainly, and can build one. Effort estimates are scoped from the advisory, not from your codebase.
dbcve · scoped36.0.742.0.2
Upgrade Wasmtime to version 36.0.7, 42.0.2, or 43.0.1. If immediate upgrading is not feasible, enable spectre mitigations as a workaround, though this may impact performance.
43.0.1
- Upgrade Wasmtime to version 36.0.7, 42.0.2, or 43.0.1 (recommended: 43.0.1 as the latest fixed version)
Generated from the published advisory — verify against the referenced sources before acting.
Fix this in Wasmtime
Scoped from the published advisory
- Consultation3.0 h
- Implementation4.0 h
- Testing6.0 h
- Review / QA3.0 h
An estimate, not a bill — we confirm scope with you before any work starts. Need it this week? Rush from $4,416.
Scan for this in your stack
Free · runs locallyCheck whether your project pulls in CVE-2026-34971 — or any other known-vulnerable package — straight from your lock files. Free and open source; it runs locally and uploads nothing.
References Go to the primary sourcePrimary sources — vendor advisories, patches and trackers. Where our summary and a reference disagree, the reference wins.
Primary sourcesPractitioner notes
ContributedPeer-ranked notes from engineers who’ve handled CVE-2026-34971 in production — separate from our analysis above.
The advisory tells you what broke. It rarely tells you what actually worked. If you’ve dealt with this one, that detail is what the next engineer is searching for.
- The version that genuinely resolved it — not the one the vendor claimed
- A config change or rule that shut the vector down
- A gotcha in the upgrade path that cost you an afternoon
No notes yet
Be the first to add a field note for this CVE — a mitigation you’ve verified, a version caveat, or a link to a working fix. Sign in above to contribute.
A place for practitioners to share what actually worked: a mitigation you’ve tested, a configuration change, a version- or environment-specific caveat, or a link to a verified patch. The most useful notes rise to the top as peers upvote them, so the signal stays high.
- Verified mitigations, workarounds, and config changes
- Version or environment caveats, and links to real fixes
- No weaponised exploit code, or anything meant to cause harm
- No spam, self-promotion, credentials, or personal data