Cyber Resilience

CVE-2025-61670

Bytecodealliance Wasmtime 37.0.0 … 37.0.1

Published
07 October 2025
Modified
30 October 2025
Patch / advisory
CVSS Score v4 1.0
Click a component to see what it means
Raw vectorCVSS: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
EPSS Score 0.0018 8th percentile
Risk Priority 15 floored blend · peak EPSS

Summary

CVE-2025-61670 is a low-severity Missing Release of Resource after Effective Lifetime (CWE-772) vulnerability in Bytecodealliance Wasmtime. Its CVSS base score is 1.0 (Low).

Operationally, exploitation aligns with the MITRE ATT&CK technique Endpoint Denial of Service (T1499); ranked at the 8th percentile by exploit likelihood (below the median); it is not currently listed in the CISA KEV catalog.

The strongest mitigations our analysis identified map to SA-11 (Developer Testing and Evaluation) and SA-15 (Development Process, Standards, and Tools) — see the control section below for these in your framework.

EU & UK References

Vulnerability Data

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…

more

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.

CWE(s)

Related Threats

MITRE ATT&CK Enterprise Techniques

T1499 Endpoint Denial of Service Impact
Adversaries may perform Endpoint Denial of Service (DoS) attacks to degrade or block the availability of services to users.
T1499.002 Service Exhaustion Flood Impact
Adversaries may target the different network services provided by systems to conduct a denial of service (DoS).
Derived from this CVE’s CWE(s) via the direct CWE→ATT&CK cross-walk.

CVEs Like This One

CVE-2026-54786Same product: Bytecodealliance Wasmtime
CVE-2026-34944Same product: Bytecodealliance Wasmtime
CVE-2026-35186Same product: Bytecodealliance Wasmtime
CVE-2024-51745Same product: Bytecodealliance Wasmtime
CVE-2026-34943Same product: Bytecodealliance Wasmtime
CVE-2026-27572Same product: Bytecodealliance Wasmtime
CVE-2026-27204Same product: Bytecodealliance Wasmtime
CVE-2025-62711Same product: Bytecodealliance Wasmtime
CVE-2026-27195Same product: Bytecodealliance Wasmtime
CVE-2026-44216Same product: Bytecodealliance Wasmtime

Affected Assets

bytecodealliance
wasmtime
37.0.0, 37.0.1

Mitigating Controls

Mitigating Controls (NIST 800-53 r5) AI

Developer testing and evaluation can discover missing resource releases through dynamic analysis or stress testing.

Requiring documented development standards and tools can mandate explicit resource-release patterns in code.

Resource-quota allocation limits the blast radius of an unreleased-resource exhaustion condition.

Mitigating Controls (NIST CSF 2.0) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→CSF cross-walk (authority under review) — links open the control.

ID.AM-08 mostly match
prevents

Lifecycle management explicitly requires handling resources through end-of-life including release.

PR.PS-06 mostly match
prevents

Secure SDLC practices directly prevent missing resource-release defects during development.

DE.CM-09 partial match
prevents

Runtime monitoring may surface resource-exhaustion symptoms but does not address release logic.

PR.IR-04 partial match
prevents

Capacity monitoring can detect exhaustion caused by unreleased resources but does not prevent the root defect.

Mitigating Controls (ISO/IEC 27001:2022 Annex A) AI

Derived directly from the weakness types (CWEs) cited in the NVD entry via our AI-authored CWE→ISO cross-walk (authority under review) — links open the control.

degrades

Explicit information-deletion requirements directly address timely release of resources after use.

prevents

Secure-SDLC practices include resource-management reviews, yet the control covers the entire lifecycle, not just this weakness.

prevents

Secure-coding rules can mandate explicit resource-release patterns, but the control is broader than this single weakness.

detects

Change-management processes may catch missing de-allocation during reviews, but the control itself does not target resource lifetime.

none

Configuration baselines can enforce resource limits or timeouts, indirectly reducing exposure to leaks.

References