CVE-2025-61670 | Wasmtime has memory leak in C API with `externref` and `anyref` types

Wasmtime is a runtime for WebAssembly. Wasmtime 37.0.0 and 37.0.1 have memory leaks in the C/C++ API when using bindings for the `anyref` or `externref` WebAssembly values. This is caused by a regression introduced during the development of 37.0.0 and all prior versions of Wasmtime are unaffected. If `anyref` or `externref` is not used in the C/C++ API then embeddings are also unaffected by the leaky behavior. The `wasmtime` Rust crate is unaffected by this leak. Development of Wasmtime 37.0.0 included a refactoring in Rust of changing the old `ManuallyRooted<T>` type to a new `OwnedRooted<T>` type. This change was integrated into Wasmtime's C API but left the C API in a state which had memory leaks. Additionally the new ownership semantics around this type were not reflected into the C++ API, making it leak-prone. A short version of the change is that previously `ManuallyRooted<T>`, as the name implies, required manual calls to an "unroot" operation. If this was forgotten then the memory was still cleaned up when the `wasmtime_store_t` itself was destroyed eventually. Documentation of when to "unroot" was sparse and there were already situations prior to 37.0.0 where memory would be leaked until the store was destroyed anyway. All memory, though, was always bound by the store, and destroying the store would guarantee that there were no memory leaks. In migrating to `OwnedRooted<T>` the usage of the type in Rust changed. A manual "unroot" operation is no longer required and it happens naturally as a destructor of the `OwnedRooted<T>` type in Rust itself. These new resource ownership semantics were not fully integrated into the preexisting semantics of the C/C++ APIs in Wasmtime. A crucial distinction of `OwnedRooted<T>` vs `ManuallyRooted<T>` is that the `OwnedRooted<T>` type allocates host memory outside of the store. This means that if an `OwnedRooted<T>` is leaked then destroying a store does not release this memory and it's a permanent memory leak on the host. This led to a few distinct, but related, issues arising: A typo in the `wasmtime_val_unroot` function in the C API meant that it did not actually unroot anything. This meant that even if embedders faithfully call the function then memory will be leaked. If a host-defined function returned a `wasmtime_{externref,anyref}_t` value then the value was never unrooted. The C/C++ API no longer has access to the value and the Rust implementation did not unroot. This meant that any values returned this way were never unrooted. The goal of the C++ API of Wasmtime is to encode automatic memory management in the type system, but the C++ API was not updated when `OwnedRooted<T>` was added. This meant that idiomatic usage of the C++ API would leak memory due to a lack of destructors on values. These issues have all been fixed in a 37.0.2 release of Wasmtime. The implementation of the C and C++ APIs have been updated accordingly and respectively to account for the changes of ownership here. For example `wasmtime_val_unroot` has been fixed to unroot, the Rust-side implementation of calling an embedder-defined function will unroot return values, and the C++ API now has destructors on the `ExternRef`, `AnyRef`, and `Val` types. These changes have been made to the 37.0.x release branch in a non-API-breaking fashion. Changes to the 38.0.0 release branch (and `main` in the Wasmtime repository) include minor API updates to better accommodate the API semantic changes. The only known workaround at this time is to avoid using `externref` and `anyref` in the C/C++ API of Wasmtime. If avoiding those types is not possible then it's required for users to update to mitigate the leak issue.

Published: 2025-10-07 Last update: 2025-10-30 Assigner: [email protected] Source: [email protected]

Conclusion & alert: CVE-2025-61670 is rated Low Risk (5.7/100): CVSS Low severity, with low exploitation likelihood (EPSS 0.02%). Mandatory action: Low composite risk—no urgent action required; patch on your normal maintenance cycle and revisit priority if CVSS or EPSS increases.

Risk is dynamic; we continuously reassess and refresh what is shown on this page as upstream context changes.

Exploit prediction scoring system (EPSS) score for CVE-2025-61670

EPSS lead: Daily EPSS estimates relative likelihood of exploitation; percentile ranks this CVE among scored vulnerabilities (higher = more severe relative rank).

# Date Old EPSS score New EPSS score Delta (New - Old)
1 2025-10-08 0.02%

Full EPSS history (1 record total)

Common vulnerability scoring system (CVSS) metrics for CVE-2025-61670

CVSS metrics for this CVE.

Base score Version Severity Vector Exploitability Impact Score source
1.0 4.0 LOW
CVSS:4.0/AV:A/AC:L/AT:P/PR:L/UI:P/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X Click to expand
Attack vector (AV:A)
Attacker has to be on an adjacent/local network segment.
Attack complexity (AC:L)
Exploitation conditions are straightforward and stable.
Attack requirements (AT:P)
Additional preconditions must be present for exploitation.
Privileges required (PR:L)
Low privileges are required.
User interaction (UI:P)
A user has to participate (for example click/open/approve).
Vulnerable system confidentiality impact (VC:N)
No confidentiality impact on the vulnerable system.
Vulnerable system integrity impact (VI:N)
No integrity impact on the vulnerable system.
Vulnerable system availability impact (VA:L)
Limited availability impact on the vulnerable system.
Subsequent system confidentiality impact (SC:N)
No confidentiality impact on subsequent systems.
Subsequent system integrity impact (SI:N)
No integrity impact on subsequent systems.
Subsequent system availability impact (SA:L)
Limited availability impact on subsequent systems.
Exploit maturity (threat) (E:X)
Not defined: no reliable threat intelligence; scoring assumes the worst case (equivalent to Attacked).
Confidentiality requirement (CR:X)
Not defined: insufficient information; scoring treats this like High (worst case).
Integrity requirement (IR:X)
Not defined: insufficient information; scoring treats this like High (worst case).
Availability requirement (AR:X)
Not defined: insufficient information; scoring treats this like High (worst case).
Modified attack vector (MAV:X)
Not defined: scoring uses the Base Attack Vector (AV).
Modified attack complexity (MAC:X)
Not defined: scoring uses the Base Attack Complexity (AC).
Modified attack requirements (MAT:X)
Not defined: scoring uses the Base Attack Requirements (AT).
Modified privileges required (MPR:X)
Not defined: scoring uses the Base Privileges Required (PR).
Modified user interaction (MUI:X)
Not defined: scoring uses the Base User Interaction (UI).
Modified vulnerable system confidentiality impact (MVC:X)
Not defined: scoring uses the Base VC metric.
Modified vulnerable system integrity impact (MVI:X)
Not defined: scoring uses the Base VI metric.
Modified vulnerable system availability impact (MVA:X)
Not defined: scoring uses the Base VA metric.
Modified subsequent system confidentiality impact (MSC:X)
Not defined: scoring uses the Base SC metric.
Modified subsequent system integrity impact (MSI:X)
Not defined: scoring uses the Base SI metric.
Modified subsequent system availability impact (MSA:X)
Not defined: scoring uses the Base SA metric.
Safety (supplemental) (S:X)
Not evaluated.
Automatable (supplemental) (AU:X)
Not evaluated.
Recovery (supplemental) (R:X)
Not evaluated.
Value density (supplemental) (V:X)
Not evaluated.
Vulnerability response effort (supplemental) (RE:X)
Not evaluated.
Provider urgency (supplemental) (U:X)
Not evaluated.
[email protected]
3.3 3.1 LOW
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L Click to expand
Attack vector (AV:L)
They already need access on the box, or another person has to do something wrong; it’s not a remote drive-by.
Attack complexity (AC:L)
Once they can reach the bug, pulling it off is straightforward—no weird race conditions or rare setup.
Privileges required (PR:L)
A normal user session is enough; they don’t have to be admin.
User interaction (UI:N)
Nobody has to click “OK” or open a trap file; it can work without a victim helping.
Scope (S:U)
Damage stays in the same “trust bubble” as the broken component—no big spill into unrelated systems.
Confidentiality (C:N)
Doesn’t really leak secrets in a meaningful way.
Integrity (I:N)
Data isn’t meaningfully altered or forged.
Availability (A:L)
Might cause slowdowns, glitches, or partial disruption—not a full brick.
1.8 1.4 [email protected]

Weakness enumeration for CVE-2025-61670

OS Trackers for CVE-2025-61670

vendor priority summary link
debian unimportant CVE-2025-61670 unimportant priority: Debian including 1 source packages (rust-wasmtime), 3 status rows across 3 suites (forky, sid, trixie): resolved 3. https://security-tracker.debian.org/tracker/CVE-2025-61670

Affected software / configurations for CVE-2025-61670

Vendor Product Version Raw CPE
bytecodealliance wasmtime 37.0.0 cpe:2.3:a:bytecodealliance:wasmtime:37.0.0:*:*:*:*:rust:*:*
bytecodealliance wasmtime 37.0.1 cpe:2.3:a:bytecodealliance:wasmtime:37.0.1:*:*:*:*:rust:*:*

References for CVE-2025-61670

cvelogic Threat Intelligence