CVE-2026-119135 in Wasmtime
Summary
by MITRE • 10/29/2026
Wasmtime 46.0.0 before 48.0.6 and 49.0.0 before 49.0.3 panics when the host reads a component model stream as a different Rust item type than it was created with, because the host-to-host read path asserts matching TypeIds instead of returning an error. Guest code can return a host-created StreamReader<U> that the embedder reads as StreamReader<T>, where both types map to the same component model type, crashing the embedding process.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability in Wasmtime versions 46.0.0 through 47.x and 49.0.0 through 49.0.2 involves a critical flaw in the host-to-host read path for component model streams, specifically affecting how type safety is enforced during cross-boundary data transfers. When an embedder application attempts to read from a stream that was originally created by another host context or returned by guest code, Wasmtime performs internal assertions to verify that the Rust type ID of the reader matches the type ID of the writer. In this specific scenario, if the embedder reads a component model stream as one Rust item type while it was actually created with a different Rust item type, even though both types map to the same underlying component model representation, the assertion fails and triggers a panic rather than returning a controlled error condition. This behavior results in an immediate crash of the embedding process, effectively causing a denial of service for any application relying on Wasmtime as its WebAssembly runtime engine.
From a technical perspective, this issue stems from overly strict type checking that does not account for semantic equivalence at the component model level versus syntactic identity at the Rust language level. The guest code can return a host-created StreamReader instance typed with one generic parameter U, which is then consumed by an embedder expecting a different generic parameter T. Since both types serialize to identical binary representations within the WebAssembly Component Model specification, they are functionally interchangeable for data transfer purposes. However, Wasmtime's internal implementation relies on Rust's TypeId mechanism for validation, which distinguishes between distinct generic instantiations even when their underlying structures and serialization formats are compatible. This mismatch leads to an unhandled assertion failure rather than a graceful error return, violating the principle of robust input handling in secure software design.
The operational impact of this vulnerability is significant for any production environment utilizing Wasmtime as part of a larger system architecture. Because the flaw results in a process crash via panic, it allows for straightforward denial-of-service attacks if an attacker can influence or control the guest code that returns stream instances to the host embedder. In cloud-native environments, serverless computing platforms, or any service where WebAssembly modules are executed dynamically based on untrusted inputs, this vulnerability could be exploited to destabilize services by triggering repeated crashes through crafted module interactions. The lack of error handling means that recovery mechanisms within the embedding application cannot intercept the fault, leading to complete service interruption until the process is restarted manually or via external monitoring systems.
This flaw aligns with CWE-248 Unhandled Exception in a Critical Loop and CWE-756 Missing Correct Calculation, as it represents a failure to handle exceptional conditions properly during critical data processing operations. Furthermore, from an adversarial simulation perspective using the MITRE ATT&CK framework, this vulnerability facilitates Denial of Service (T1499) by enabling attackers to disrupt service availability through resource exhaustion via process termination. It also touches upon Improper Input Validation (CWE-20), as the system fails to validate that the logical type compatibility matches the strict runtime identity requirements before proceeding with data extraction operations.
Mitigation strategies primarily involve upgrading Wasmtime to version 48.0.6 or later, and for versions in the 49.x series, updating to at least 49.0.3 where this assertion logic has been corrected to return appropriate errors instead of panicking on type mismatches that are semantically equivalent. For organizations unable to immediately upgrade due to dependency constraints, implementing external watchdog processes or health checks can help detect and restart crashed instances more rapidly, minimizing downtime. Additionally, developers should review their embedder code to ensure strict adherence to expected types when interacting with streams returned by guest modules, although this is a workaround rather than a fix for the underlying runtime flaw. Ensuring that all dependencies are kept up-to-date remains the most effective defense against such implementation-level vulnerabilities in WebAssembly runtimes.