CVE-2026-34988: Wasmtime Information Disclosure Flaw

CVE-2026-34988 Overview

CVE-2026-34988 is an Information Leakage vulnerability affecting Wasmtime, a runtime for WebAssembly. The vulnerability exists in Wasmtime's pooling allocator implementation where, under specific configurations, the contents of linear memory can be leaked from one WebAssembly instance to another. This occurs due to a predicate mismatch between the compilation process and runtime behavior when determining whether virtual memory permissions need to be reset.

Critical Impact

WebAssembly sandbox bypass allowing guest instances to read linear memory contents from previously executed instances, breaking both WebAssembly semantics and Wasmtime's isolation guarantees.

Affected Products

• Wasmtime versions 28.0.0 to before 36.0.7
• Wasmtime versions 42.0.0 to before 42.0.2
• Wasmtime versions 43.0.0 to before 43.0.1

Discovery Timeline

• 2026-04-09 - CVE CVE-2026-34988 published to NVD
• 2026-04-09 - Last updated in NVD database

Technical Details for CVE-2026-34988

Vulnerability Analysis

This vulnerability stems from a logic flaw in Wasmtime's pooling allocator, specifically in how it handles virtual memory permission resets for linear memory regions. The pooling allocator is designed to efficiently manage memory for multiple WebAssembly instances by reusing memory slots. However, a critical divergence exists between the predicate used at compile-time and the one used at runtime to determine if memory permissions need to be reset.

At compile-time, the WebAssembly compiler generates code that assumes out-of-bounds memory accesses will trigger a segmentation fault (segfault). However, the runtime pooling allocator uses a different predicate to decide whether to reset virtual memory permissions when reusing a linear memory slot. This mismatch means the allocator may incorrectly determine that resetting permissions is unnecessary, while the compiled code relies on those resets occurring.

The practical impact is that when a linear memory slot is reused for a new WebAssembly instance, the previous memory contents and permissions may persist. Since the compiled code assumes segfaults will protect against out-of-bounds reads, a malicious or buggy WebAssembly module can read data from the previous instance's memory, leading to information disclosure between sandboxed guests.

This vulnerability is classified under CWE-119 (Improper Restriction of Operations within the Bounds of a Memory Buffer).

Root Cause

The root cause is a predicate mismatch in Wasmtime's pooling allocator implementation. The code responsible for determining whether virtual memory permissions need to be reset at runtime uses different logic than what the compiler assumes during code generation. Specifically, the compilation process generates code expecting that out-of-bounds loads will trigger segfaults, but the runtime allocator's reset logic uses an incorrect condition that fails to reset VM permissions under certain configurations.

This divergence only manifests when all of the following configuration conditions are met:

• The pooling allocator must be enabled
• Config::memory_guard_size must be set to 0
• Config::memory_reservation must be less than 4GiB
• The pooling allocator's max_memory_size must equal the memory_reservation value

Attack Vector

The attack vector for this vulnerability is network-based, requiring the attacker to execute WebAssembly code within a Wasmtime environment configured with the vulnerable settings. An attacker controlling a WebAssembly module running in a shared Wasmtime instance could exploit this vulnerability to read sensitive data from other WebAssembly instances that previously used the same memory slot.

The attack scenario involves:

1. A victim WebAssembly instance processes sensitive data in linear memory
2. The instance terminates, but memory permissions are not properly reset
3. An attacker's WebAssembly module is allocated the same memory slot
4. The attacker's module performs out-of-bounds reads that should segfault but instead successfully read the victim's leftover data

This represents a cross-instance information disclosure that breaks WebAssembly's isolation model and Wasmtime's sandbox guarantees.

Detection Methods for CVE-2026-34988

Indicators of Compromise

• WebAssembly instances exhibiting unexpected memory read patterns or accessing memory beyond defined boundaries
• Anomalous WebAssembly module behavior attempting systematic out-of-bounds reads
• Evidence of data exfiltration from WebAssembly sandboxed environments

Detection Strategies

• Review Wasmtime configuration files for the vulnerable combination: memory_guard_size set to 0, memory_reservation less than 4GiB, and max_memory_size matching memory_reservation
• Audit WebAssembly module behavior logs for patterns of out-of-bounds memory access attempts
• Monitor for unexpected data appearing in WebAssembly instance outputs that could indicate cross-instance memory leakage

Monitoring Recommendations

• Enable verbose logging for Wasmtime's memory allocation and deallocation operations
• Implement runtime monitoring for WebAssembly instances to detect anomalous memory access patterns
• Conduct periodic configuration audits to ensure vulnerable settings are not inadvertently enabled

How to Mitigate CVE-2026-34988

Immediate Actions Required

• Upgrade Wasmtime to patched versions: 36.0.7, 42.0.2, or 43.0.1 depending on your current version line
• If immediate upgrade is not possible, review and modify Wasmtime configuration to avoid the vulnerable parameter combination
• Audit any multi-tenant WebAssembly hosting environments for potential historical exploitation

Patch Information

Security patches are available in Wasmtime versions 36.0.7, 42.0.2, and 43.0.1. These releases correct the predicate logic in the pooling allocator to ensure virtual memory permissions are properly reset when linear memory slots are reused. Organizations should upgrade to the appropriate fixed version based on their current Wasmtime version line. For detailed patch information, refer to the GitHub Security Advisory.

Workarounds

• Set Config::memory_guard_size to a non-zero value to prevent the vulnerable code path from being triggered
• Configure Config::memory_reservation to 4GiB or greater if operationally feasible
• Disable the pooling allocator entirely and use Wasmtime's default memory management (may impact performance)
• Ensure max_memory_size differs from memory_reservation to avoid the vulnerable configuration

# Configuration example - Ensure memory_guard_size is non-zero
# In your Wasmtime configuration, set:
# memory_guard_size = 2097152  # 2MB guard region (non-zero)
# This prevents the vulnerable code path from being exercised