RUSTSEC-2026-0223: Wasmtime: Preemption and traps during bulk operations enable breaking internal VM state
Wasmtime is a runtime for WebAssembly. From 46.0.0 until 46.0.2 and 47.0.3, fuel and epoch preemption checks inside bulk operations including memory.copy, table.grow, and array.copy can expose invalid intermediate state when an embedder mutates a Store in Store::epochdeadlinecallback or continues using a Store after cancellation or a trap. A cancelled non-nullable table growth can leave null elements, linear-memory growth during memory.copy can invalidate retained raw pointers, and callback-triggered garbage collection during array.copy can invalidate GC pointers, resulting in a crash, invalid memory access, or GC heap corruption. Embeddings whose callbacks only access the host data in Store<T>, and embeddings that discard a Store after timeout or epoch deadline, are not affected. This issue is fixed in versions 46.0.2 and 47.0.3.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Wasmtimeto a version that resolves this vulnerability.Fixed in 46.0.2 - Upgrade
Upgrade
Wasmtimeto a version that resolves this vulnerability.Fixed in 47.0.3
Event History
Frequently Asked Questions
Which embeddings are exposed to this issue?
Embeddings are affected when fuel or epoch preemption can occur during bulk operations and code mutates the Store from Store::epoch_deadline_callback or continues using the Store after cancellation or a trap. Embeddings whose callbacks access only the host data in Store<T>, or that discard the Store after a timeout or epoch deadline, are not affected.
What conditions are needed for exploitation?
An attacker must be able to trigger affected bulk operations, such as memory.copy, table.grow, or array.copy, while fuel or epoch preemption checks occur. Exploitation also depends on the embedding handling the resulting callback, cancellation, or trap in a way that mutates or reuses the Store.
What can be done if an immediate upgrade is not possible?
Do not mutate the Store from Store::epoch_deadline_callback; limit callback access to the host data in Store<T>. After a timeout, epoch deadline, cancellation, or trap, discard the Store rather than continuing to use it.
How can an application determine whether it may be affected?
Review whether it uses Wasmtime versions from 46.0.0 up to before 46.0.2, or version 47.0.3 before its fix, and whether fuel or epoch preemption is enabled. Then check whether epoch-deadline callbacks mutate the Store or whether a Store is reused after cancellation or a trap.
Which versions contain the fix?
The issue is fixed in Wasmtime 46.0.2 and 47.0.3.