CVE-2026-34971
HighCVSS 7.8Exploitation Probability (EPSS)
Low risk24th percentile - higher than 24% of all known CVEs
Summary
Wasmtime versions 32.0.0 through 36.0.7, 42.0.2, and 43.0.1 have a bug in the Cranelift compiler on aarch64 that miscalculates memory addresses during heap access. This allows WebAssembly modules to bypass bounds checks and access arbitrary host memory, resulting in a sandbox escape.
Risk Assessment
The organization faces a complete breach of WebAssembly process isolation, potentially allowing an attacker to read and write arbitrary host memory, leading to system compromise or data exfiltration.
Recommendation
Immediately upgrade Wasmtime to version 36.0.7, 42.0.2, or 43.0.1. If upgrade is not possible, enable Spectre mitigations or restrict to 32-bit WebAssembly memory only.
Other vulnerabilities in Wasmtime
See all- CVE-2026-58494Medium
Wasmtime is a runtime for WebAssembly. Prior to versions 24.0.11, 36.0.12, 45.0.3, and 46.0.1, the wasmtime-wasi component checked directory permissions but not matching FilePerms on source and destination preopens during hard-link creation and renaming. This allowed a WASI guest with read-only source file capability to overwrite host files exposed as FilePerms::READ through wasip1, wasip2, or wasip3 filesystem interfaces.
- CVE-2026-54786Medium
Wasmtime prior to versions 24.0.10, 36.0.11, 44.0.3, and 45.0.2 contains a vulnerability in the native WASIp1 implementation where the fd_renumber function fails to properly close the target file descriptor. This causes resource leaks in the host system, potentially leading to exhaustion of file descriptors and resources.
- CVE-2026-47261High
Wasmtime, a runtime for WebAssembly, has a vulnerability in versions prior to 24.0.9, 36.0.10, and 44.0.2 that allows bypassing the access control mechanism using the wasip2 descriptor.open-at or wasip1 path_open interfaces. The issue arises from a missing assignment in the open mode handling, allowing files to be opened with the OpenFlags::TRUNCATE flag without the necessary write permissions.
- CVE-2026-44216High
Wasmtime versions 30.0.0 through 36.0.8, 43.0.2, and 44.0.1 contain a vulnerability where allocation logic for WebAssembly tables panics on overflow. This panic can be triggered when allocating extremely large tables (64-bit range via memory64 proposal). An attacker can cause a denial of service by providing a WebAssembly module or component that requests such a large table.
Original NVD description (English source)
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.