CVE-2026-34942: Denial of Service via Unaligned Memory Allocation in Wasmtime Component Model

Wasmtime functions as a standalone runtime for WebAssembly and implements the WebAssembly Component Model for modular architecture. A vulnerability exists within the system's string transcoding logic, specifically when transferring data between guest and host environments using utf16 or latin1+utf16 encodings. During these transfers, the host delegates memory allocation to the guest environment.

The vulnerability manifests as an Improper Validation of Array Index or Pointer flaw, categorized under CWE-129. When the runtime initiates a string transfer, it calls a guest-provided realloc function to reserve space in the guest's linear memory. The host environment subsequently accepts the returned memory address but fails to validate its alignment constraints before utilizing it in host-side operations.

Operating on the misaligned pointer triggers an unrecoverable panic within the Rust-based host runtime. Rust enforces strict memory alignment rules, and violating these invariants during memory intrinsic operations results in immediate process termination. This behavior allows an untrusted guest module to intentionally crash the runtime process, constituting a severe Denial of Service (DoS) attack.

The root cause resides within the fact (Fast-call Trampoline) compiler of Wasmtime. This compiler generates dynamic trampolines responsible for managing ABI boundaries and data transcoding operations between the host and guest modules. During string encoding conversion targeting UTF-16, the trampoline must allocate destination space within the guest's linear memory.

To execute this allocation, the generated trampoline performs a function call to a realloc routine exported by the guest module. According to the WebAssembly Component Model ABI specifications, UTF-16 strings strictly require 2-byte memory alignment. The generated host-side code operates under the assumption that the guest allocator inherently adheres to this ABI contract.

The implementation vulnerability occurs immediately following the realloc execution. The trampoline logic retrieves the returned memory pointer but entirely omits any runtime verification of its alignment characteristics. When the host subsequently invokes optimized Rust transcoding routines or memory intrinsics, such as slice::from_raw_parts, the presence of an unaligned pointer violates Rust's core safety invariants.

Analyzing the vulnerable codebase reveals a structural omission in the trampoline generation logic. Prior to the patch, the fact compiler emitted instructions to call the guest allocator and directly bind the returned pointer to the destination variable. No intermediary validation instructions were injected into the generated execution path.

The remediation, implemented in crates/environ/src/fact/trampoline.rs, introduces a mandatory alignment verification step. The patch modifies the fact compiler to inject a verify_aligned check immediately after receiving the pointer from the guest's realloc function.

// Vulnerable Implementation (Before Patch)
self.instruction(Call(dst_mem_opts.realloc.unwrap().as_u32()));
self.instruction(LocalSet(dst.ptr.idx));
// [MISSING ALIGNMENT VERIFICATION]
 
// Remediated Implementation (After Patch)
self.instruction(Call(dst_mem_opts.realloc.unwrap().as_u32()));
self.instruction(LocalSet(dst.ptr.idx));
// New alignment verification enforces 2-byte alignment for UTF-16
self.verify_aligned(dst_opts.data_model.unwrap_memory(), dst.ptr.idx, 2);

This added instruction fundamentally alters the execution behavior upon encountering malformed input. If the verify_aligned instruction detects an unaligned address, it interrupts the execution flow and raises a standard WebAssembly trap. This isolates the failure to the guest execution context, terminating the malicious instance while preserving the stability of the overall host process.

Exploiting this vulnerability requires the attacker to supply a malicious WebAssembly module to the target Wasmtime host. The module must utilize the Component Model and define a custom string transcoding boundary. By defining these parameters, the attacker exercises precise control over the memory allocation logic exported to the host environment.

The malicious payload implements a custom realloc function that intentionally violates the Component Model ABI requirements. When invoked by the host during a string transfer operation, this function returns a deliberately misaligned pointer. For a UTF-16 target encoding, the function returns an odd memory address where the least significant bit is set to 1.

The exploitation process completes when the host runtime attempts to write the transcoded string data into the provided memory location. The misaligned address triggers the underlying Rust panic macro, terminating the process immediately. This attack vector executes deterministically and requires no complex memory manipulation, heap grooming, or race conditions.

The prerequisite for exploitation is the ability to submit a guest module to the Wasmtime instance. The attack requires low privileges and can be executed over a network if the deployment accepts remote WebAssembly payloads. The outcome is strictly localized to a runtime crash, providing no mechanisms for arbitrary code execution or memory disclosure.

The primary impact of CVE-2026-34942 is a high-severity Denial of Service (DoS) affecting the availability of the Wasmtime host environment. Because the host panic is unrecoverable, the entire runtime process terminates abruptly. This termination disrupts all concurrently executing guest modules within the same runtime instance, expanding the blast radius beyond the malicious payload.

In multi-tenant environments or cloud-based serverless platforms utilizing Wasmtime, this vulnerability poses a significant operational risk. A single malicious tenant can degrade the service availability for other users sharing the same physical or virtual host infrastructure. The CVSS 4.0 score of 5.9 (Medium) specifically reflects this isolated yet impactful availability disruption.

The vulnerability exhibits a low attack complexity because triggering the flaw requires only fundamental knowledge of the WebAssembly Component Model ABI. The absolute determinism of the resulting crash guarantees that an attacker can reliably cause service disruption on demand. Security controls that monitor for resource exhaustion or infinite loops cannot detect this exploitation vector.

Despite the high impact on availability, the vulnerability does not compromise data confidentiality or runtime integrity. The strict nature of the Rust panic prevents the unaligned pointer from being utilized for arbitrary memory read or write operations. Exploit intelligence currently indicates no known active exploitation in the wild and an EPSS score of 0.00014.

The Bytecode Alliance has released multiple patched versions of Wasmtime to address this vulnerability comprehensively. Organizations must update their Wasmtime dependencies to versions 24.0.7, 36.0.7, 42.0.2, or 43.0.1, depending on their current release train. These versions incorporate the strict alignment validation within the fact trampoline compiler.

There are no viable configuration workarounds or runtime flags that mitigate this vulnerability in unpatched versions. The flaw is deeply embedded in the Component Model's ABI boundary handling and fundamental trampoline compilation logic. Disabling the Component Model entirely serves as the only operational workaround, which is functionally impractical for applications that depend on it.

Security teams must perform software supply chain auditing to identify all internal applications embedding the Wasmtime runtime. Dependency scanning tools should be configured to flag vulnerable versions across all Rust projects and container images deployed in the production environment.

As a forward-looking mitigation strategy, developers should review other data types handled by the Component Model that possess alignment constraints, such as list<u32> or list<f64>. Ensuring comprehensive validation of all guest-supplied memory pointers at the ABI boundary is critical for preventing similar vulnerability classes from emerging in other architectural subsystems.