CVE-2026-34941: Heap Out-of-bounds Read in Wasmtime Component String Transcoding

Wasmtime is a prominent WebAssembly runtime developed by the Bytecode Alliance, widely used for sandboxing untrusted code execution. CVE-2026-34941 identifies a critical heap out-of-bounds (OOB) read vulnerability within the WebAssembly Component Model implementation. The flaw resides specifically in the runtime's string transcoding logic, affecting the conversion of UTF-16 strings to the hybrid latin1+utf16 encoding format.

The vulnerability is classified under CWE-125 (Out-of-bounds Read) and carries a CVSS 4.0 score of 6.9. The runtime exposes this attack surface through the fact (Fast API Call Trampoline) compiler, which generates the operational logic for transcoding strings between WebAssembly components. The core issue stems from an incorrect bounds validation calculation that interprets code unit counts as byte counts.

Exploitation allows a malicious WebAssembly guest module to induce the host runtime into reading memory beyond the established sandbox boundaries. Depending on the runtime configuration, this memory access violation results in either a denial-of-service condition or the unauthorized disclosure of sensitive host memory contents.

The root cause of CVE-2026-34941 is an arithmetic discrepancy in the bounds checking logic applied prior to string transcoding. In the WebAssembly Component Model, the length of a UTF-16 string is formally defined by the number of 16-bit code units it contains, not its raw byte size. The host system performs memory access on a byte-oriented basis, necessitating a precise conversion between code units and byte lengths during validation.

Prior to the patch, the Wasmtime fact compiler retrieved the string length L (representing the number of 16-bit code units) provided by the guest module. The bounds validation logic then verified whether L bytes were available in the guest's linear memory. This check was mathematically flawed, as each UTF-16 code unit strictly occupies two bytes of memory space.

Following the flawed validation, the subsequent transcoding loop proceeded to read L * 2 bytes from memory to process the actual footprint of the UTF-16 units. If a guest module provided a length L that fell within the valid memory bounds, but the calculated L * 2 value extended beyond the allocated linear memory, the validation check would erroneously succeed.

This discrepancy created a classic out-of-bounds read condition within the runtime memory space. The host process would execute the transcode loop, traversing past the guest sandbox bounds and reading adjacent memory regions. The structural flaw resided specifically within crates/environ/src/fact/trampoline.rs, where the validate_string_length function was invoked directly against the raw code unit count.

Analyzing the vulnerable codebase reveals the precise location of the logic error within the trampoline generation routines. The validate_string_length function was utilized to guarantee that a given memory range remained strictly within the guest's allocated bounds. The input argument to this function was derived directly from the guest's provided string length parameter without the necessary encoding width multiplier.

The vulnerability manifested because the source length was not multiplied by two prior to validation for width-2 encodings. The patched code introduces a centralizer helper function, source_string_byte_len, which accurately calculates the total byte requirement for specific encoding types before passing the value to the bounds checker.

The patch commit 96dde3aa67a5c456e4091ed60a9e3e774f0efd85 resolves the arithmetic mismatch by applying a bitwise shift operator. For UTF-16 encodings, the code unit count is shifted left by one (ptr_shl(1)), effectively multiplying the value by two before invoking the newly defined validate_string_inbounds routine.

// Conceptual representation of the patch logic
 
// Vulnerable Implementation
fn generate_transcode(...) {
    // Validates 'len' units instead of bytes
    validate_string_length(len);
    execute_transcode(src_ptr, len * 2);
}
 
// Patched Implementation 
fn generate_transcode(...) {
    // Calculate accurate byte length
    let byte_len = source_string_byte_len(len, Encoding::Utf16);
    validate_string_inbounds(byte_len);
    verify_aligned(src_ptr);
    execute_transcode(src_ptr, byte_len);
}

Additionally, the patch includes verify_aligned instructions to ensure strict memory alignment for UTF-16 pointers. This secondary fix prevents misaligned read panics on the host architecture during the transcoding process, hardening the implementation against supplementary memory safety violations.

Exploitation of CVE-2026-34941 requires the attacker to execute a malicious WebAssembly guest module within the vulnerable Wasmtime host environment. The guest module must interact with a system component that explicitly requires latin1+utf16 transcoding, passing a carefully crafted string pointer and length parameter to the host.

To trigger the out-of-bounds read, the attacker positions the source string near the absolute end of the guest's allocated linear memory space. The attacker then provides a length value L calculated to satisfy the flawed L byte bounds check, while ensuring that the actual access pattern of L * 2 bytes physically crosses the linear memory boundary.

The Wasmtime host evaluates the parameters, passes the flawed initial boundary check, and begins executing the fact trampoline transcode loop. The host process iteratively reads two-byte chunks from the source pointer, eventually iterating beyond the sandbox limit and accessing memory belonging to the host process or other guest allocations.

While no public proof-of-concept exploit is currently available, the attack methodology is entirely deterministic. The attack does not require advanced heap manipulation or complex memory corruption primitives, as it strictly relies on the host's logic error to execute the unauthorized read operations on behalf of the guest module.

The concrete security impact of CVE-2026-34941 is heavily dependent on the specific runtime configuration of the Wasmtime host environment. In standard deployments, Wasmtime surrounds the linear memory of guest modules with unmapped virtual memory known as guard pages.

When an attacker triggers this vulnerability in a default configuration, the out-of-bounds read operation immediately traverses into these protective guard pages. The host operating system intercepts this invalid memory access, generating a fatal SIGSEGV or SIGBUS signal. This results in the abrupt termination of the Wasmtime host process, constituting a definitive denial-of-service condition affecting all running modules on that host.

In non-standard configurations where guard pages are explicitly disabled or configured with insufficient sizes, the vulnerability escalates into a severe information disclosure primitive. The out-of-bounds read operation successfully accesses adjacent host memory regions, treating the raw binary data as UTF-16 string material during the transcoding pass.

The host process transcodes this leaked memory and returns it to the guest module or an associated component boundary. An attacker analyzes the resulting string to extract sensitive data, including heap structures, cryptographic material, or sensitive application data belonging to other tenant instances running within the same host runtime.

Remediation of CVE-2026-34941 requires updating the Wasmtime runtime to the latest available patch releases across the supported maintenance branches. The Bytecode Alliance has issued fixed versions including 24.0.7, 36.0.7, 42.0.2, and 43.0.1 to comprehensively address the bounds checking logic error.

Software developers and infrastructure engineers utilizing Wasmtime as an embedded runtime must update their crate dependencies and recompile their host applications. Containerized environments or serverless platforms relying on Wasmtime must schedule deployment rollouts to replace the vulnerable runtime binaries executing guest workloads.

For deployments where immediate patching is administratively unfeasible, security teams must verify that Wasmtime guard pages are actively enabled. Maintaining the default guard page configuration successfully mitigates the risk of information disclosure, restricting the attacker's capability strictly to process termination.

Monitoring strategies must include robust alerting on unexpected host process crashes, specifically targeting SIGSEGV events occurring within the Wasmtime execution context. Network-based detection mechanisms remain ineffective against this vulnerability due to the encapsulated execution model of WebAssembly.