CVE-2026-104855: 
Rust vulnerability analysis and mitigation

CVE-2026-104855 is a race condition / invalid intermediate state vulnerability in Bytecode Alliance's Wasmtime WebAssembly runtime, titled "Preemption and traps during bulk operations enable breaking internal VM state." It affects Wasmtime versions 46.0.0–46.0.1 and 47.0.0–47.0.2, and was disclosed on July 31, 2026, with patches released the same day. The vulnerability arises when fuel or epoch preemption checks injected inside bulk WebAssembly operations (memory.copy, table.grow, array.copy) expose invalid intermediate state to embedders that mutate or reuse a Store at preemption points. It carries a CVSS v3.1 base score of 4.7 (Medium) and a CVSS v4.0 base score of 2.0 (Low) (GitHub Advisory, Red Hat CVE).

The root cause is a combination of CWE-362 (Race Condition via Shared Resource with Improper Synchronization) and CWE-1265 (Unintended Reentrant Invocation of Non-reentrant Code via Nested Calls). Wasmtime versions 46.0.0+ introduced fuel and epoch preemption checks within bulk operations as a loop, allowing embedders to observe and mutate intermediate state mid-operation. Three specific failure modes exist: (1) a cancelled table.grow on a non-nullable table leaves null elements, which subsequent WebAssembly loads assume are non-null, potentially causing segfaults; (2) during memory.copy, if an embedder's epoch_deadline_callback grows linear memory (causing the base address to move), the raw pointers used by the in-progress copy become invalid; (3) during array.copy, if a GC is triggered in an epoch callback, raw GC pointers cached within the operation become stale, corrupting the GC heap. The fix moves all preemption checks to the start of each bulk operation, eliminating mid-operation cancellation points (GitHub Advisory, Fix PR #14045).

Successful exploitation can result in process crashes (via null pointer dereference or segfault), invalid memory access within the Wasmtime runtime, or corruption of the GC heap. The availability impact is the primary concern — a crash of the Wasmtime host process — while limited integrity impact is possible through GC heap corruption or stale pointer usage. Confidentiality is not directly impacted. The vulnerability is scoped to the Wasmtime runtime process itself; lateral movement beyond the process boundary is not a documented risk, but GC heap corruption could theoretically be leveraged for further memory manipulation within the runtime (GitHub Advisory, Feedly).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation as of the disclosure date (Feedly). Exploitation requires specific embedder-side preconditions: the embedding must use Store::epoch_deadline_callback and either mutate the Store (e.g., grow memory or trigger GC) within the callback, or continue executing WebAssembly in the same Store after a cancellation or trap. Embeddings that only access host data (T in Store<T>) in callbacks, or that discard the Store after timeout, are not affected. The EPSS score is 0.0 and the vulnerability is not listed in the CISA KEV catalog (GitHub Advisory).

1. Identify a vulnerable embedding: Locate a Wasmtime-based application running versions 46.0.0–46.0.1 or 47.0.0–47.0.2 that uses Store::epoch_deadline_callback and either mutates the Store within the callback or reuses the Store after a trap/cancellation.
2. Craft a WebAssembly module with a large bulk operation: Write a .wasm module that executes a large memory.copy, table.grow (on a non-nullable table), or array.copy instruction — large enough to trigger multiple epoch/fuel preemption checks mid-operation.
3. Trigger the epoch deadline during the bulk operation: Ensure the epoch counter is incremented (e.g., via a background thread calling engine.increment_epoch()) while the bulk operation is in progress, causing the runtime to invoke the embedder's epoch_deadline_callback.
4. Mutate the Store in the callback (or cancel and reuse): In the callback, perform a state-mutating action such as growing linear memory (invalidating memory.copy pointers), growing a table, or triggering a GC (invalidating array.copy GC pointers). Alternatively, cancel the operation and then invoke more WebAssembly in the same Store.
5. Trigger the crash or corruption: Upon resumption of the bulk operation, the runtime uses stale/invalid pointers or accesses null table elements, resulting in a segfault, invalid memory access, or GC heap corruption (GitHub Advisory, Fix PR #14045).

Upgrade Wasmtime to version 46.0.2 or 47.0.3 (or later), which move all preemption checks to the start of bulk operations, eliminating mid-operation cancellation points (GitHub Advisory, PR #14041, PR #14043). As a workaround for embedders unable to upgrade immediately: (1) if using Store::epoch_deadline_callback, ensure the callback only accesses the host data T in Store<T> and does not mutate WebAssembly state (memory, tables, or trigger GC); (2) discard the Store entirely after a timeout, epoch deadline, or trap rather than continuing to execute WebAssembly in it. Embedders that explicitly mutate the Store in epoch callbacks or resume WebAssembly after trapping have no safe workaround short of upgrading.

The advisory was authored by Wasmtime maintainer alexcrichton and reviewed and approved by fitzgen, with patches merged on July 31, 2026 for both the 46.0.x and 47.0.x release branches (PR #14041, PR #14043). The fix was also backported to the main branch and included in the 48.0.0 release. Red Hat tracked the issue as "Deferred" in their CVE database, indicating it is not considered an immediate priority for their product lines (Red Hat CVE). No significant broader media coverage or social media discussion has been identified.