GHSA-hfr4-7c6c-48w2 CVE-2026-34983 PYSEC-2026-151 RUSTSEC-2026-0090
Wasmtime has use-after-free bug after cloning `wasmtime::Linker`
- Severity
- 0.0 / 10
- Medium · CVSS 4.0
- Exploit chance (EPSS)
- 0.12%
- Chance of exploitation in the next 30 days. Higher than 1.64% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-416 Use After Free
- Fix
43.0.1- Upgrade wasmtime to this version or later
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
StringPoolwas introduced in https://github.com/bytecodealliance/wasmtime/pull/12536, at which time the bug inTryClone for StringPoolwas already present, although this code path was not yet used anywhere. wasmtime::Linkerwas refactored to internally useStringPoolin 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
Affected versions
PyPI
| Package | Vulnerable | Fixed in |
|---|---|---|
| wasmtime | <= 43.0.0 |
No fix yet |
crates.io
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
wasmtime crates.io → 43.0.1
- cargo
cargo update -p wasmtime --precise 43.0.1
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:P/AC:H/AT:P/PR:H/UI:A/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N
- Attack vector
- Physical
- Attack complexity
- High
- Attack requirements
- Present
- Privileges required
- High
- User interaction
- Active
- Confidentiality (vulnerable system)
- Low
- Integrity (vulnerable system)
- Low
- Availability (vulnerable system)
- Low
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
CVSS 3.1 5.0
CVSS:3.1/AV:L/AC:L/PR:L/UI:R/S:U/C:N/I:N/A:H
- Attack vector
- Local
- Attack complexity
- Low
- Privileges required
- Low
- User interaction
- Required
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- None
- Availability
- High
Weakness
CWE-416: Use After Free
The product reuses or references memory after it has been freed. At some point afterward, the memory may be allocated again and saved in another pointer, while the original pointer references a location somewhere within the new allocation. Any operations using the original pointer are no longer valid because the memory "belongs" to the code that operates on the new pointer.
How to prevent it
- Architecture and Design: Choose a language that provides automatic memory management.
- Implementation: When freeing pointers, be sure to set them to NULL once they are freed. However, the utilization of multiple or complex data structures may lower the usefulness of this strategy.
References
Advisories
Issue reports
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| RUSTSEC-2026-0424 Unchecked memory usage in transferring borrowed resources between components | Not rated yet | Also affects wasmtime |
| RUSTSEC-2026-0423 Cross-engine type confusion with host-created struct-types-with-supertypes | Not rated yet | Also affects wasmtime |
| RUSTSEC-2026-0422 Typed functions with `i31` or `nullref` arguments may panic due to insufficient type-check | Low | Also affects wasmtime |
| RUSTSEC-2026-0379 Wasmtime: Cranelift backend on aarch64 can jump to incorrect target on large Wasm `br_table` instruction | Critical | Also affects wasmtime |
| GHSA-9pvw-hwfg-92h5 Wasmtime: Panic lowering a host-created component model stream into a guest that expects a different payload type | Medium | Also affects wasmtime |
| GHSA-897f-g5gm-fmxm Wasmtime: Bit-packing in Cranelift compiler causes silent overflow and miscompilation | Critical | Also affects wasmtime |
| RUSTSEC-2026-0364 Exception tags can cause host data structures to be unaligned | Not rated yet | Also affects wasmtime |
| RUSTSEC-2026-0363 Component-model handle tables are capped only per instance and charged to no limit | Medium | Also affects wasmtime |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor