Skip to main content
VulnerabilityPublished Updated

CVE-2026-34971: bytecodealliance wasmtime · Out-of-bounds Read

Affects bytecodealliance wasmtimeSource CVE Database V5

0
Compare

Not known to be exploited · CVSS 9.0 Critical · fixed in 44.0.1 : patch bytecodealliance wasmtime as a priority.

Data as of 30 Oct 2026, 11:52 UTC

CVSS 4.0 base score
9.0Critical
How severe the flaw is on the 0–10 CVSS scale.

Contested

Critical score, yet low EPSS after six months
EPSS
0.3% chance of exploitation in 30 days – higher than 24% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
Patch
Available – fixed in 44.0.1, 42.0.2, 36.0.7 +1
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

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 9 Apr 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponized: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq Mirage: no evidence on record.

    No attack traffic recorded by OffSeq Mirage sensors

A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 30 Oct 2026.

What to do

Upgrade wasmtime to 44.0.1, 42.0.2 or 36.0.7; bytecodealliance/wasmtime to 43.0.1, 42.0.2 or 36.0.7.

Affected software

ProductAffectedFixed in
bytecodealliancewasmtimeAffected
  • >=43.0.0 <44.0.1
Fixed in
  • 44.0.1
bytecodealliancewasmtimeAffected
  • >=37.0.0 <42.0.2
Fixed in
  • 42.0.2
bytecodealliancewasmtimeAffected
  • >=32.0.0 <36.0.7
Fixed in
  • 36.0.7
crates.iobytecodealliance/wasmtimepkg:cargo/bytecodealliance/wasmtimeOther threatsAffected
  • <36.0.7
  • <42.0.2
  • <43.0.1
Fixed in
  • 36.0.7
  • 42.0.2
  • 43.0.1

Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.

AI-suggested

Fixed versions 36.0.7, 42.0.2, and 43.0.1 of Wasmtime address this vulnerability. Users should upgrade to one of these versions or later to remediate the issue. The vendor advisory does not indicate any alternative mitigations or temporary workarounds. Spectre mitigations or signals-based traps being enabled prevent the vulnerable code generation, but relying on these is not a substitute for applying the official fix.

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.

References

Community reviews

Loading reviews…