CVE-2026-115383 in Wasmtime
Summary
by MITRE • 10/23/2026
Wasmtime 47.0.0 before 48.0.4 and 49.0.0 before 49.0.2 contains an improper validation vulnerability that accepts components whose core modules import WebAssembly tags with a subtype of the original type. Malicious guests can mis-type exception object payloads to corrupt the GC heap, causing Wasmtime to panic when the exceptions proposal is enabled.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The identified vulnerability resides within the component model validation logic of Wasmtime versions 47.0.0 through 48.0.3 and 49.0.0 through 49.0.2, representing a critical failure in type safety enforcement for WebAssembly components. This flaw specifically affects scenarios where the experimental garbage collection proposal is enabled, allowing malicious guest modules to exploit improper validation of imported tags. The core issue stems from Wasmtime accepting component instances that import WebAssembly exception tags with subtypes that differ incorrectly from the original expected types defined by the host or the component interface contract. In a properly secured environment, strict type checking ensures that any data passed through these interfaces adheres to predefined structural and semantic constraints, preventing memory corruption and logic errors.
From a technical perspective, this vulnerability allows an attacker to mis-type exception object payloads during the import process. When exceptions are thrown within a WebAssembly component, they carry associated payload objects that may include references to garbage-collected data structures. By supplying a subtype of the expected tag type, the malicious guest module bypasses standard validation checks, leading to a situation where the runtime interprets memory layouts incorrectly. This misinterpretation can result in heap corruption because the garbage collector operates under assumptions about object sizes and alignments that are violated by the improperly typed payload. The discrepancy between the declared subtype and the actual data structure creates an inconsistency that corrupts internal state within the WebAssembly linear memory and associated GC heaps.
The operational impact of this vulnerability is severe, primarily manifesting as a denial of service through application crashes. When Wasmtime encounters these corrupted heap states during exception handling or garbage collection cycles, it triggers a panic condition rather than gracefully recovering from the error. This behavior effectively terminates the execution environment, disrupting any services relying on WebAssembly for sandboxed code execution. For platforms utilizing Wasmtime to run untrusted third-party plugins or microservices, this vulnerability poses a significant risk as an attacker could repeatedly trigger these panics to cause sustained outages without needing arbitrary code execution capabilities initially. The reliance on the garbage collection proposal means that systems not using GC features are largely unaffected by this specific vector, but those leveraging advanced component model features for complex data exchange remain vulnerable.
This flaw aligns with CWE-20 Improper Input Validation and CWE-787 Out-of-bounds Write in contexts where type confusion leads to memory corruption. In terms of the MITRE ATT&CK framework, it relates to techniques involving exploitation via invalid input types that bypass security-relevant checks, potentially leading to availability impacts classified under Impact: Denial of Service. The vulnerability highlights the complexity of maintaining strict type safety across language boundaries and component interfaces in WebAssembly environments, particularly when experimental features like garbage collection are involved.
To mitigate this risk, organizations must immediately upgrade Wasmtime to version 48.0.4 or later for the 48.x branch, or version 49.0.2 and later for the 49.x branch. These releases contain patches that enforce stricter validation rules on imported tags, ensuring that subtypes are correctly validated against their base types before allowing exception payloads to be processed. Additionally, developers should review component interfaces to ensure that type definitions are explicit and robust, minimizing reliance on implicit subtype relationships where possible. Enabling strict mode configurations in Wasmtime can also help catch such discrepancies earlier during the compilation or instantiation phase rather than at runtime. Regular security audits of WebAssembly components and staying informed about updates related to the garbage collection proposal are essential practices for maintaining a secure execution environment.