External risk intelligence

Wasmtime Cranelift Arbitrary Host Memory Read Write Vulnerability

CVE advisorySeverity: CRITICAL (CVSS 9.0)

CVE-2026-34971

Wasmtime is a library, not a standalone network service. Exploitation requires a specific, non-default configuration (disabling Spectre mitigations and signals-based traps) and the use of 64-bit WebAssembly memories. Public exposure of this specific vulnerable runtime setup is highly unlikely, as it contradicts standard security-hardened deployment practices for running untrusted code.

Out-of-bounds Read

Bytecodealliance Wasmtime

32.0.0 to before 36.0.737.0.0 to before 42.0.243.0.0

Halo Surface Signal: 1 out of 5 — much less likely to be public-facing.

External exposure likelihood

Horizon Alert

Summary of the vulnerability and why it matters

This critical vulnerability in Wasmtime, a WebAssembly runtime, could allow malicious code to read or write to areas of host memory it shouldn't access, potentially bypassing security protections. The issue arises from a specific compilation error on certain hardware configurations when specific security features are disabled.

A code flaw could allow unauthorized memory access.
Leadership should remember this for potential sandbox escapes.
Confirm relevance and exposure to protect system integrity.

Attack Path

How an attacker could exploit the issue

An attacker could exploit this vulnerability by crafting a malicious WebAssembly module. This module would need to be executed within a Wasmtime environment that is configured with specific, non-default security settings. The module would then trigger a bug in Wasmtime's compilation process, allowing it to read or write data beyond its intended boundaries, effectively escaping its sandbox.

Requires a crafted WebAssembly module.
Triggers a compilation bug with specific settings.
Enables arbitrary host memory read/write.

Live Threat

Current exploitation, exposure, and threat context

A vulnerability in Wasmtime's Cranelift compilation backend could allow a malicious WebAssembly module to read and write arbitrary host memory. This occurs when specific conditions are met, including the use of 64-bit WebAssembly linear memories or when `Config::wasm_memory64` is enabled, and crucially, when Spectre mitigations or signals-based traps are disabled. This sandbox escape can be achieved by exploiting a miscompile in how certain heap accesses are handled, leading to divergent address computations.

Arbitrary host memory read/write.
Exploits specific miscompiled heap accesses.
Enables sandbox escape for guest modules.

Operational Fix

Recommended remediation, mitigation, and detection steps

The teams likely responsible for addressing this critical vulnerability are application owners who integrate Wasmtime, and platform or infrastructure teams managing its deployment. The first practical step is to identify all instances of the affected Wasmtime versions, assess their exposure, and confirm business criticality to prioritize remediation efforts.

Identify Wasmtime usage and accountable owners.
Verify affected Wasmtime deployments and configurations.
Plan risk-based remediation or vendor coordination.

Supplementary metadata

CVSS vector

Validate whether this threat affects your internet-facing exposure.

Halo Threat Intelligence helps prioritize remediation with Halo Surface Signal and H/A/L/O context. Start exposure validation with a free external attack surface trial.

Free EASM Trial See How Signal Works

Frequently asked questions

What is Wasmtime?

Wasmtime is a specialized runtime engine that executes WebAssembly modules. Developers use it as a library to safely run untrusted code in a sandboxed environment, allowing applications to execute high-performance code across different platforms. It is widely utilized to provide isolation between the guest code and the host system's memory.

What is the vulnerability in CVE-2026-34971?

The issue involves an Out-of-bounds Read (CWE-125) and Out-of-bounds Write (CWE-787). A bug in the Cranelift compilation backend causes the runtime to calculate incorrect memory addresses for certain heap operations on aarch64 architectures. This allows a malicious WebAssembly module to bypass security checks and perform unauthorized read or write operations directly on the host system's memory, effectively escaping the intended sandbox.

When does this security bug trigger?

The flaw only triggers under a very specific combination of factors: running on aarch64 hardware, using 64-bit WebAssembly linear memory, and having both Spectre mitigations and signals-based traps disabled. Standard 32-bit WebAssembly modules are not affected. If you are using default security configurations, the specific code pattern required to miscompile the memory access is not generated.

Is my system at risk according to Halo Surface Signal?

Halo Surface Signal notes that while the bug is critical, exploitation is very unlikely. Wasmtime is a library, not a network service, and the requirement to disable standard security-hardened features like Spectre mitigations makes a successful attack difficult. You should verify if your specific Wasmtime deployment intentionally uses these non-default, less secure configurations.

How do I address this CVE-2026-34971 issue?

Start by identifying all applications in your environment that integrate Wasmtime and confirm which versions are in use. If you are running an affected version, update to 36.0.7, 42.0.2, or 43.0.1 to incorporate the fix for the Cranelift compilation backend. Once identified, coordinate with the teams responsible for these applications to schedule the necessary software updates.

References

Written by Nicholas Merritt

Nicholas Merritt is VP of Security Solutions at Halo Security. With more than 25 years across application security, vulnerability prioritization, and offensive security, he helps teams translate threat data into practical exposure validation and remediation focus. He authors Halo Threat Intelligence CVE advisories using Halo Surface Signal and H/A/L/O context to prioritize internet-facing risk.