CVE-2026-34983: Wasmtime has a use-after-free bug after cloning `wasmtime::Linker`
Impact
In version 43.0.0 of the wasmtime crate, cloning a wasmtime::Linker is unsound and can result in use-after-free bugs.
This bug is not controllable by guest Wasm programs. It can only be triggered by a specific sequence of embedder API calls made by the host.
The typical symptom of this use-after-free bug is a segfault. It does not enable heap corruption or data leakage.
If you are using the wasmtime CLI, rather than the embedding API, you are not affected. If you are using the embedding API but are not calling wasmtime::Linker's Clone implementation, you are not affected.
Specifically, the following steps must occur to trigger the bug:
Clone a wasmtime::Linker Drop the original linker instance Use the new, cloned linker instance, resulting in a use-after-free
Patches
This bug has been patched in Wasmtime version 43.0.1
Workarounds
Wasmtime embedders are highly encouraged to upgrade their wasmtime crate dependency.
If upgrading is not an option, or as a temporary workaround before upgrading, you can avoid this bug by not cloning wasmtime::Linker and instead creating a new, empty wasmtime::Linker and manually reregistering the host APIs from the original linker:
rust use wasmtime::{Linker, Result, Store};
fn clonelinker<T>(linker: &Linker<T>, store: &mut Store<T>) -> Result<Linker<T>> { let mut cloned = Linker::new(); for (module, name, item) in linker.iter(store) { cloned.define(module, name, item)?; } Ok(cloned) }
References
This bug was introduced during an internal refactoring that was part of our efforts to robustly handle allocation failure in Wasmtime. This refactoring introduced an string-interning pool which had an unsound TryClone[^try-clone] implementation.
[^try-clone]: The TryClone trait is our version of the Rust standard library's Clone trait that allows for returning OutOfMemory errors.
The StringPool was introduced in https://github.com/bytecodealliance/wasmtime/pull/12536, at which time the bug in TryClone for StringPool was already present, although this code path was not yet used anywhere. wasmtime::Linker was refactored to internally use StringPool in https://github.com/bytecodealliance/wasmtime/pull/12537, at which time the buggy code path became accessible. This bug was originally reported to the Wasmtime maintainers as https://github.com/bytecodealliance/wasmtime/pull/12906
Other sources
Wasmtime is a runtime for WebAssembly. In 43.0.0, cloning a wasmtime::Linker is unsound and can result in use-after-free bugs. This bug is not controllable by guest Wasm programs. It can only be triggered by a specific sequence of embedder API calls made by the host. Specifically, the following steps must occur to trigger the bug clone a wasmtime::Linker, drop the original linker instance, use the new, cloned linker instance, resulting in a use-after-free. This vulnerability is fixed in 43.0.1.
— MITRE
Affected Software
Event History
Frequently Asked Questions
What is the severity of CVE-2026-34983?
CVE-2026-34983 has a critical severity level due to the potential for unsound memory usage leading to use-after-free vulnerabilities.
How do I fix CVE-2026-34983?
To resolve CVE-2026-34983, upgrade the 'wasmtime' crate to version 43.0.1 or later.
Is CVE-2026-34983 exploitable?
CVE-2026-34983 is not directly exploitable by guest Wasm programs, but it may still lead to instability in the host application.
Which versions of 'wasmtime' are affected by CVE-2026-34983?
CVE-2026-34983 affects version 43.0.0 of the 'wasmtime' crate.
What are the potential impacts of CVE-2026-34983?
The potential impacts of CVE-2026-34983 include program crashes and undefined behavior due to memory management errors.