CVE-2026-34988: 
Rust vulnerability analysis and mitigation

CVE-2026-34988 is a data leakage vulnerability in Wasmtime's pooling allocator that allows contents of linear memory to be leaked from one WebAssembly instance to the next under specific non-default configurations. Discovered and disclosed on April 9, 2026, it affects Wasmtime versions 28.0.0 through 36.0.6, 37.0.0 through 42.0.1, and 43.0.0 (Rust/cargo package). The vulnerability was published by alexcrichton under GHSA-6wgr-89rj-399p and credited to researcher shumbo. It carries a CVSS v3.1 score of 6.3 (Medium) and a CVSS v4.0 score of 2.3 (Low) (Github Advisory, Red Hat Bugzilla).

The root cause is an incorrect predicate used in the pooling allocator's runtime logic to determine whether virtual memory permissions need to be reset between WebAssembly instance reuses, which diverges from the predicate used at compile time (CWE-119: Improper Restriction of Operations within the Bounds of a Memory Buffer; CWE-825: Expired Pointer Dereference). At compile time, Wasmtime assumes out-of-bounds memory accesses will segfault due to virtual memory protections; however, at runtime the allocator incorrectly skips resetting those protections, allowing compiled code to read stale memory from a prior instance. Exploitation requires all four of the following non-default conditions to be simultaneously true: the pooling allocator is in use, Config::memory_guard_size is set to 0, Config::memory_reservation is less than 4 GiB, and max_memory_size equals memory_reservation (Github Advisory, Wasmtime Advisory).

Successful exploitation breaks WebAssembly's memory isolation semantics and Wasmtime's sandbox guarantees, allowing a guest WebAssembly instance to read the residual contents of linear memory from a previously executed instance in the same pooling allocator. This is a confidentiality-only impact — there is no integrity or availability impact — but sensitive data such as cryptographic material, credentials, or application state from prior tenants could be exposed to a subsequent, potentially malicious, WebAssembly workload. The scope is changed, meaning the impact extends beyond the directly vulnerable instance to affect data belonging to other guest instances (Github Advisory, Red Hat Bugzilla).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Github Advisory). The EPSS score is approximately 0.011% (1st percentile), indicating a very low probability of exploitation in the near term. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation is constrained by the requirement for a specific, non-default Wasmtime configuration and low-privileged network access, making opportunistic exploitation unlikely.

1. Identify a vulnerable deployment: Confirm the target is running Wasmtime versions 28.0.0–36.0.6, 37.0.0–42.0.1, or 43.0.0 with the pooling allocator enabled, Config::memory_guard_size set to 0, Config::memory_reservation less than 4 GiB, and max_memory_size equal to memory_reservation.
2. Obtain low-privileged access: Acquire credentials or a mechanism to submit WebAssembly modules to the target Wasmtime runtime (e.g., via an API or multi-tenant WebAssembly execution service).
3. Trigger memory reuse: Submit a WebAssembly instance that processes or stores sensitive data, then allow it to terminate so its linear memory slot is returned to the pooling allocator.
4. Craft a malicious WebAssembly module: Write a WebAssembly module that performs out-of-bounds memory reads beyond its declared memory size, targeting addresses that would normally segfault but are now accessible due to the missing permission reset.
5. Read leaked data: Execute the malicious module in the same pooling allocator slot previously occupied by the victim instance; the compiled code reads the stale linear memory contents, exposing data from the prior instance (Wasmtime Advisory).

• Logs: Wasmtime runtime logs showing repeated instantiation and termination of WebAssembly instances in rapid succession, potentially indicating an attacker cycling instances to trigger memory reuse.
• Behavioral: WebAssembly modules performing memory accesses beyond their declared linear memory size without triggering segmentation faults (observable via runtime instrumentation or abnormal absence of expected traps).
• Configuration Audit: Presence of Config::memory_guard_size = 0, Config::memory_reservation < 4GiB, and max_memory_size == memory_reservation in Wasmtime embedder configuration files, confirming a vulnerable deployment posture.

Upgrade to Wasmtime versions 36.0.7, 42.0.2, or 43.0.1 depending on the currently deployed version branch — these releases correct the predicate mismatch in the pooling allocator (Wasmtime Advisory). If immediate upgrade is not possible, any one of the four vulnerable configuration conditions can be changed to eliminate the risk: enabling guard pages (setting Config::memory_guard_size to a non-zero value is strongly recommended), increasing Config::memory_reservation to 4 GiB or more, or decoupling max_memory_size from memory_reservation. Deployments using Wasmtime's default settings are not affected and require no action (Github Advisory).

The Bytecode Alliance published a security advisory blog post covering this and related Wasmtime advisories shortly after disclosure (Bytecode Alliance). Red Hat tracked the issue via Bugzilla and assigned it medium severity for their products (Red Hat Bugzilla). OpenSUSE issued security announcements for their wasmtime packages in response to the vulnerability (OpenSUSE Announce). The Zed editor project also issued a patch commit addressing the dependency (Zed Commit). Overall community reaction has been measured, reflecting the low severity and narrow exploitation conditions.