CVE-2026-115892 in Wasmtime
Summary
by MITRE • 10/24/2026
Wasmtime is a runtime for WebAssembly. From 46.0.0 until 48.0.7 and 49.0.4, lowering a host-created component-model stream or future into a guest can omit a required payload-type check after the value passes through guest code and returns through StreamAny, FutureAny, Val::Stream, Val::Future, or an equivalent typed reader. A malicious guest that controls exported function types or returned values can cause the host to pass the type-erased value to a guest expecting a different payload type, which panics the Wasmtime host. This issue is fixed in versions 48.0.7 and 49.0.4.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/24/2026
The vulnerability identified within the Wasmtime runtime environment represents a critical failure in type safety enforcement during the interaction between host-created components and guest WebAssembly modules. Specifically, this flaw exists in version ranges spanning from 46.0.0 up to 48.0.7 and 49.0.4. The core issue arises when lowering a stream or future created by the host into a format consumable by the guest code. In these affected versions, the runtime fails to perform a mandatory payload-type check after the value has traversed through guest-executed logic and returns via specific interfaces such as StreamAny, FutureAny, Val::Stream, or Val::Future. This omission creates a significant security gap where type integrity is compromised during the boundary crossing between the host environment and the untrusted guest execution space.
From a technical perspective, the flaw allows for a scenario where a malicious guest module can manipulate exported function types or control returned values to bypass expected data structures. When the host passes a type-erased value back into the guest without verifying its actual payload type against what is expected by the receiving side, it leads to a fundamental mismatch in data interpretation. This misalignment occurs because the runtime assumes that once a value has passed through certain intermediate stages or interfaces, its integrity remains intact, which is an incorrect assumption when dealing with potentially hostile code. The lack of validation at this specific juncture means that arbitrary or malformed data structures can be injected into contexts expecting strictly typed payloads, violating the isolation guarantees provided by WebAssembly.
The operational impact of this vulnerability manifests as a denial-of-service condition resulting in a panic within the Wasmtime host process. Because the type mismatch occurs during critical value handling operations, it triggers an unrecoverable error state rather than allowing for graceful degradation or safe error handling. For applications relying on Wasmtime to execute untrusted code, such as cloud-native services, serverless functions, or sandboxed environments, this panic can lead to immediate service disruption. An attacker controlling the guest module's behavior could repeatedly trigger these panics, effectively crashing the host application and rendering it unavailable to legitimate users. This represents a severe availability risk in production environments where stability is paramount.
This vulnerability aligns with CWE-20 Improper Input Validation, as the system fails to adequately verify that inputs meet specified requirements before processing them further. Additionally, it relates to CWE-841 Improper Enforcement of Type Integrity, highlighting the failure to maintain distinct boundaries between different data types during inter-process or intra-runtime communication. In terms of offensive security frameworks, this flaw can be leveraged within ATT&CK techniques related to Execution and Defense Evasion, specifically by exploiting software vulnerabilities to disrupt service availability. The attack vector primarily involves supplying crafted inputs through exported function calls or return values from guest modules, requiring the attacker to have control over at least some aspects of the guest code's interface definitions or execution paths.
Mitigation strategies focus on immediate version upgrades and defensive coding practices. Organizations running affected versions must upgrade Wasmtime to 48.0.7 or 49.0.4 immediately, as these releases contain the necessary fixes for the payload-type checking logic. For environments where upgrading is not instantly feasible, implementing strict validation layers at the host level before passing values into guest contexts can provide a partial workaround, though this increases complexity and may impact performance. Furthermore, developers should ensure that all exported function types are rigorously defined and validated against expected schemas to minimize the attack surface available to malicious guests. Regular security audits of WebAssembly integration points and continuous monitoring for unusual panic patterns in host logs can also aid in early detection and response to exploitation attempts.