CVE-2026-119140 in Wasmtime
Summary
by MITRE • 10/29/2026
Wasmtime 46.0.0 before 48.0.6 and 49.0.0 before 49.0.3 contains a denial of service vulnerability that allows malicious components to panic the host via thread.yield in start functions. Attackers can supply a component whose start function calls an async-lowered import then thread.yield, causing an undisposed fiber drop that crashes embedders.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The identified security issue resides within specific versions of Wasmtime, specifically affecting releases 46.0.0 through 47.x and 49.0.0 through 49.0.2. This vulnerability is classified as a denial of service condition that stems from improper handling of asynchronous operations within WebAssembly components when executed by the host runtime environment. The core technical flaw involves the interaction between async-lowered imports and thread management primitives, specifically the thread.yield function. When a maliciously crafted component invokes an import that has been lowered to handle asynchronous execution during its start function phase, it can subsequently trigger a yield operation. This sequence of events leads to a critical state where fibers associated with these operations are dropped without proper disposal or cleanup mechanisms being invoked by the runtime engine.
In normal WebAssembly execution models, particularly those involving async/await patterns in Rust-based runtimes like Wasmtime, resources such as fibers must be carefully managed to prevent memory leaks and stability issues. The start function of a component is executed immediately upon instantiation before any other functions are called. If this initial phase involves lowering an import that relies on asynchronous execution contexts, the runtime allocates specific internal structures to manage these tasks. However, due to the vulnerability in question, when thread.yield is invoked within this context, it disrupts the expected lifecycle of these fibers. Instead of being properly resolved or cleaned up upon completion or interruption, the fiber objects are dropped while still holding critical state information that requires explicit disposal. This results in an undisposed fiber drop condition which triggers a panic in the host application running Wasmtime.
The operational impact of this vulnerability is significant for any service relying on untrusted WebAssembly components to process user-supplied data or code. An attacker who can supply such a malicious component can cause the hosting process to crash unexpectedly. This constitutes a classic denial of service attack vector, as it allows remote actors to disrupt availability without requiring authentication or privilege escalation beyond what is needed to submit the payload. For cloud providers, API gateways, or any system that instantiates WebAssembly modules dynamically based on external input, this vulnerability poses a severe risk to infrastructure stability and reliability. The crash occurs at the host level, meaning it affects the entire process running Wasmtime rather than just isolating within the sandboxed component environment.
From a classification perspective, this issue aligns with CWE-400, which describes uncontrolled resource consumption leading to denial of service conditions. Furthermore, in terms of adversary tactics and techniques, this vulnerability can be leveraged as part of an initial access or impact phase where availability is targeted. It corresponds broadly to ATT&CK technique T1499, Endpoint Denial of Service, specifically involving exhaustion of resources through malicious inputs that trigger system crashes. The specific mechanism involves exploiting the runtime's error handling and resource management logic during asynchronous execution contexts, highlighting a gap in how edge cases within async lowering are validated before fiber allocation proceeds.
Mitigation strategies primarily involve upgrading to patched versions of Wasmtime where this issue has been resolved. For users unable to immediately upgrade, implementing strict validation layers on incoming WebAssembly components can help mitigate risk by filtering out modules that exhibit suspicious patterns during the start function execution phase. Additionally, running untrusted components within isolated processes with limited resource quotas and automatic restart capabilities can reduce the blast radius of such crashes. Security teams should also monitor host logs for panic traces related to fiber disposal or async runtime errors as an indicator of potential exploitation attempts in environments where Wasmtime is deployed.