Open-Source Security Intelligence

Know every vulnerability
before it knows you.

DevGuard continuously monitors your dependencies and alerts you when CVEs like this one affect your stack — with real-time threat intelligence built for developers.

Search

GHSA-hfr4-7c6c-48w2

LowCVSS 1 / 10
Published Apr 9, 2026·Last modified Apr 22, 2026
Affected Components(0)

No affected components available

Description

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:

use wasmtime::{Linker, Result, Store};

fn clone_linker<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
Risk Scores
Base Score
1.0

The vulnerability requires physical access to the device to be exploited. It is difficult for an attacker to exploit this vulnerability and may require special conditions. An attacker needs high-level or administrative privileges.

Threat Intelligence
0.1

Limited exploitation activity has been observed. Close monitoring and planned remediation are recommended.

EPSS
0.12%

The exploit probability is very low. The vulnerability is unlikely to be exploited in the next 30 days.

Exploit
Not available

We did not find any exploit available. Neither in GitHub repositories nor in the Exploit-Database.

Browse More

Scan your project

Continuously monitor your dependencies and get alerted when vulnerabilities like this one affect your stack.

Checkout DevGuard