CVE-2026-119138 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 pending calls to trigger an assertion failure after a trap poisons the Store. Attackers supplying misbehaving guest code can cause a trap and let earlier calls proceed, crashing embedders that continue using the inconsistent Store.
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 WebAssembly runtime Wasmtime contains a critical denial of service vulnerability affecting versions prior to 48.0.6 in the 48.x series and prior to 49.0.3 in the 49.x series. This flaw stems from an improper handling of state consistency when asynchronous or pending execution contexts interact with trap conditions within the runtime environment. The core issue lies in how the Store object, which holds all mutable WebAssembly state including memory, globals, and tables, is managed during error scenarios. When a guest module executes code that triggers a trap, such as an out-of-bounds memory access or an invalid operation, the expected behavior is for the runtime to halt execution immediately and propagate the error up to the embedder without leaving the Store in a corrupted state. However, due to this vulnerability, certain sequences of pending calls can continue to execute even after a trap has poisoned the underlying Store structure.
This specific failure mode allows an attacker who controls or influences the guest code to induce a trap condition while other function invocations are still queued or in progress within the same execution context. Instead of aborting all concurrent operations and resetting the state cleanly, Wasmtime permits these earlier calls to proceed using references to data structures that have already been compromised by the initial trap. This results in undefined behavior because the embedder continues to interact with a Store object whose internal integrity has been violated. The immediate operational impact is an assertion failure within the runtime itself, leading to an abrupt termination of the host process hosting Wasmtime. For applications relying on WebAssembly for sandboxed execution or plugin architectures, this translates directly into a denial of service condition where the entire application crashes rather than gracefully handling the error from the untrusted module.
From a technical perspective, this vulnerability aligns with CWE-617, which describes Reachable Assertion failure in an external control block. The root cause is related to CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization of Actions, as the race condition between trap handling and pending call resolution leads to inconsistent state access. In terms of threat modeling, this behavior can be mapped to MITRE ATT&CK technique T1499, Endpoint Denial of Service, specifically under sub-techniques involving resource exhaustion or application crash via malformed input. The vulnerability highlights a gap in the isolation guarantees provided by the runtime when dealing with asynchronous execution flows and error propagation mechanisms.
Mitigation strategies for this issue primarily involve upgrading to patched versions of Wasmtime that address these state management inconsistencies. Embedders should ensure they are running version 48.0.6 or later, or version 49.0.3 and above, where the logic has been corrected to properly isolate pending calls from poisoned store states. Additionally, developers integrating WebAssembly into their applications should implement robust error handling routines that anticipate potential runtime failures and avoid relying on synchronous assumptions for all guest code executions. It is also advisable to run untrusted modules in isolated processes or threads with strict resource limits to contain the blast radius of any such crashes, ensuring that a single malicious module cannot bring down the entire host infrastructure. Regular updates to the WebAssembly toolchain and runtime are essential to maintain security posture against evolving exploitation techniques targeting execution environments.