CVE-2026-119136 in Wasmtime
Summary
by MITRE • 10/29/2026
Wasmtime 42.0.0 before 48.0.6 and 49.0.0 before 49.0.3 contains insufficient checks in Store when mixing async-style and sync-style WebAssembly calls. Embedders re-entering WebAssembly via sync APIs from host functions called asynchronously can trigger runtime panics or unsound cross-thread movement of !Send host variables.
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 vulnerability identified in Wasmtime versions prior to 48.0.6 and 49.0.3 stems from a critical flaw in the internal state management logic, specifically within the Store component responsible for hosting WebAssembly instances. This issue arises when an embedder attempts to mix asynchronous-style execution with synchronous-style calls to WebAssembly functions. The core technical deficiency lies in the insufficient validation of thread safety and context consistency during these mixed-mode interactions. When a host function is invoked asynchronously but subsequently triggers a re-entry into the WebAssembly runtime via a synchronous API, the system fails to adequately verify that the current execution context remains valid and isolated from concurrent operations. This lack of rigorous checks allows for unsafe state transitions that violate Rust's ownership and borrowing rules, particularly concerning types marked as !Send, which are explicitly not safe to transfer across thread boundaries.
From an operational perspective, this flaw can lead to severe runtime instability and potential security compromises. The immediate consequence is often a panic in the WebAssembly runtime, causing denial of service for applications relying on Wasmtime for execution isolation. However, beyond simple crashes, the unsound cross-thread movement of !Send host variables presents a more insidious risk. If an attacker or malicious code can manipulate the timing and sequence of these mixed calls, they may induce undefined behavior within the host environment. This could potentially lead to memory corruption, data leakage, or privilege escalation depending on how the embedder utilizes these host functions. The vulnerability effectively undermines the sandboxing guarantees that WebAssembly is designed to provide, as it allows for state corruption through improper concurrency handling rather than direct exploitation of buffer overflows or injection flaws.
This issue aligns with CWE-662, which describes improper synchronization within multithreaded processes, and specifically relates to race conditions where shared resources are accessed without proper locking or context verification. In the context of the MITRE ATT&CK framework, this vulnerability could be leveraged in techniques related to Defense Evasion by causing crashes to disrupt security monitoring tools, or potentially Execution if the resulting undefined behavior allows for arbitrary code execution through memory corruption. The flaw highlights a common challenge in systems programming where high-level abstractions like async/await patterns interact with low-level runtime constraints regarding thread safety and lifetime management.
To mitigate this vulnerability, organizations must immediately upgrade Wasmtime to version 48.0.6 or later, which includes the necessary fixes for these synchronization checks. For embedders who cannot update immediately, it is crucial to audit codebases that mix async host functions with synchronous WebAssembly calls. Developers should ensure that any state shared between asynchronous callbacks and synchronous runtime invocations is properly synchronized using thread-safe primitives such as Mutexes or Arcs, although the most robust solution remains avoiding mixed calling styles altogether where possible. Additionally, embedding applications in environments with strict memory safety guarantees can help contain potential impacts if a panic occurs, preventing broader system compromise. Regular security audits focusing on concurrency patterns and WebAssembly integration points are recommended to identify similar architectural weaknesses before they can be exploited.