CVE-2026-34987: 
Rust vulnerability analysis and mitigation

CVE-2026-34987 is a memory sandbox escape vulnerability in Wasmtime's Winch (baseline) non-default compiler backend that allows properly constructed guest WebAssembly modules to access host memory outside of the linear-memory sandbox. It affects Wasmtime versions 25.0.0 through before 36.0.7, 37.0.0 through before 42.0.2, and version 43.0.0 (patched in 43.0.1). The vulnerability was disclosed on April 9, 2026, with fixes released the same day. It carries a CVSS v3.1 base score of 9.9 (Critical) and a CVSS v4.0 base score of 9.0 (Critical) (Github Advisory, Red Hat Bugzilla).

The root cause is an incorrect numeric type conversion (CWE-681) in the Winch compiler backend: a 32-bit memory offset stored in a 64-bit register is assumed to have its upper bits cleared, but this assumption does not always hold. This leads to out-of-bounds read (CWE-125) and potentially out-of-bounds write (CWE-787) conditions, allowing a guest Wasm module to access memory before or after its designated linear-memory region. The bug is confirmed exploitable on aarch64 with an observed working proof-of-concept; the x86-64 case is considered theoretical and may not be reachable in practice. The accessible range in the initial PoC is up to 32KiB before the start of linear memory or approximately 4GiB after it, independently of guard region configuration or bounds-checking mechanisms, and closely related exploit variants may reach truly arbitrary in-process memory (Github Advisory).

Successful exploitation can result in three distinct outcomes: an arbitrary data leak from the host process (confidentiality breach), a host process segmentation fault causing denial of service (availability breach), or — via a write primitive — potentially arbitrary remote code execution within the host process (integrity breach). The scope is changed, meaning a compromised Wasm guest can affect the broader host system beyond its sandbox. Environments running untrusted WebAssembly modules with the Winch compiler backend enabled are at highest risk, as an attacker with low privileges could leverage this to escalate access or exfiltrate sensitive in-process data (Github Advisory, Red Hat Bugzilla).

A working proof-of-concept exists for the aarch64 architecture, as acknowledged in the official advisory, though no public PoC code has been released. There is no evidence of in-the-wild exploitation or threat actor attribution at this time. The vulnerability is not currently listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. The EPSS score is approximately 0.042%, indicating a low near-term exploitation probability (Github Advisory, Feedly).

1. Identify target: Confirm the target Wasmtime deployment is using the Winch compiler backend (-Ccompiler=winch) on an aarch64 host, as the default Cranelift backend is not affected and x86-64 exploitation is theoretical.
2. Craft malicious Wasm module: Construct a WebAssembly module that performs memory load or store operations using a 32-bit offset value whose upper bits, when sign-extended or zero-extended into a 64-bit register by the Winch compiler, produce an address outside the linear-memory region.
3. Submit Wasm for execution: Deliver the crafted .wasm file to the target Wasmtime runtime — for example, via a web service, plugin system, or API that accepts and executes user-supplied Wasm modules.
4. Trigger out-of-bounds access: When Winch JIT-compiles and executes the module, the incorrect register handling causes memory accesses up to 32KiB before or ~4GiB after the linear-memory base address, bypassing guard regions and bounds checks.
5. Achieve objective: Depending on the access type — read operations can leak sensitive host process memory (credentials, keys, heap data); write operations may corrupt host memory to achieve code execution or denial of service via segmentation fault (Github Advisory).

• Process: Wasmtime host process terminating unexpectedly with a segmentation fault (SIGSEGV) signal, particularly when executing externally supplied Wasm modules with the Winch backend.
• Logs: Application or system logs showing crashes or abnormal exits of the Wasmtime process; kernel logs (dmesg) recording segfault events attributed to the Wasmtime process.
• File System: Presence of unexpected .wasm files submitted to the service, especially those with unusual memory instruction patterns or large offset values in load/store operations.
• Network: Unusual outbound connections from the Wasmtime host process following Wasm module execution, which may indicate successful code execution and callback to an attacker-controlled server.

Bytecode Alliance has released patched versions: 36.0.7, 42.0.2, and 43.0.1. Users should upgrade to the appropriate patched version based on their current branch (25.x–36.x → 36.0.7; 37.x–42.x → 42.0.2; 43.0.0 → 43.0.1). There are no in-backend workarounds for affected Winch versions; the only alternative mitigation is to switch to the default Cranelift compiler backend by removing the -Ccompiler=winch flag. Restricting execution of untrusted WebAssembly modules until patching is complete is also advised (Github Advisory).

The Bytecode Alliance published a security advisory blog post covering this and related Wasmtime vulnerabilities shortly after disclosure. The vulnerability was credited to reporter shumbo with additional acknowledgment to bholley and deian. The issue was tracked by Red Hat's Product Security team via Bugzilla and has been picked up by Linux distribution security mailing lists, including openSUSE. No significant broader media coverage or notable social media discussion beyond automated CVE tracking accounts has been observed (Bytecode Alliance Blog, Red Hat Bugzilla).