CVE-2026-119141 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 Wasm modules to panic the host because the may_leave flag is not cleared during realloc. Attackers can call into the host from realloc while lowering stream or future results, such as cancelling the active read or re-waiting a waitable-set, crashing the host.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The vulnerability identified in Wasmtime versions prior to 48.0.6 and 49.0.3 represents a critical flaw within the WebAssembly runtime engine that facilitates denial of service attacks through improper state management during memory reallocation operations. This issue specifically targets the internal handling of the may_leave flag, which is designed to control whether execution can return from a host function call back into the WebAssembly module or vice versa. When a maliciously crafted Wasm module triggers a realloc operation while lowering stream results or managing future outcomes such as cancelling an active read or re-waiting on a waitable set, the runtime fails to properly clear this flag. This oversight creates a race condition and state inconsistency that allows the attacker to force the host environment into an unrecoverable panic state, effectively crashing the entire application running Wasmtime.
From a technical perspective, the core of the flaw lies in the lifecycle management of asynchronous operations within the runtime's foreign function interface layer. The may_leave flag serves as a safeguard mechanism ensuring that control flow transitions between WebAssembly code and host functions occur safely without corrupting internal execution contexts. During realloc calls, particularly those invoked during complex async workflows like stream cancellation or waitable set re-waiting, the engine must ensure that all pending state is stabilized before allowing any potential exit from the current context. By neglecting to reset this flag when these specific asynchronous operations are in progress, Wasmtime leaves the runtime vulnerable to invalid transitions. An attacker exploiting this flaw can craft a WebAssembly module that repeatedly triggers reallocs during these sensitive windows, causing the host process to encounter an internal invariant violation and subsequently panic.
The operational impact of this vulnerability is severe for any service relying on Wasmtime to execute untrusted or semi-trusted code in a multi-tenant environment. Since the attack results in a complete crash of the host application, it directly compromises availability, which is one of the three pillars of information security alongside confidentiality and integrity. In cloud-native architectures where WebAssembly modules are often used for sandboxing user-provided logic, such as serverless functions or plugin systems, this vulnerability could allow an attacker to take down entire service instances by simply submitting a malicious module. This does not require privilege escalation or code execution on the host system but is sufficient to cause significant disruption and potential data loss if state was being persisted at the time of the crash.
This flaw aligns with CWE-400, which describes uncontrolled resource consumption leading to denial of service, as well as CWE-362 regarding concurrent execution issues where shared resources are accessed without proper synchronization or state validation. In terms of offensive security frameworks, this vulnerability maps to MITRE ATT&CK technique T1499, Endpoint Denial of Service, specifically under the sub-category of resource exhaustion via application layer attacks. The exploitation vector is classified as remote if the Wasmtime instance accepts inputs from untrusted sources over a network interface, making it particularly dangerous in public-facing services that parse and execute WebAssembly modules dynamically.
To mitigate this risk, organizations must immediately upgrade their Wasmtime dependencies to version 48.0.6 or later for the 48.x branch, or version 49.0.3 and later for the 49.x branch, as these releases contain patches that correctly manage the may_leave flag during realloc operations involving async streams and waitable sets. Additionally, developers should implement strict input validation on any WebAssembly modules received from external sources to ensure they do not trigger complex asynchronous patterns unless absolutely necessary. Implementing resource limits and timeouts for Wasm execution can also help contain the blast radius of such attacks by limiting the duration a malicious module can run before being forcibly terminated, thereby reducing the window of opportunity for triggering the state corruption that leads to host panics.