CVE-2025-61670
Unknown Unknown - Not Provided
BaseFortify

Publication date: 2025-10-07

Last updated on: 2025-10-30

Assigner: GitHub, Inc.

Description
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.
CVSS Scores
EPSS Scores
Probability:
Percentile:
Meta Information
Published
2025-10-07
Last Modified
2025-10-30
Generated
2026-05-07
AI Q&A
2025-10-07
EPSS Evaluated
2026-05-05
NVD
CVE-2025-61670
EUVD
EUVD-2025-33183
Affected Vendors & Products
Showing 2 associated CPEs
Vendor Product Version / Range
bytecodealliance wasmtime 37.0.0
bytecodealliance wasmtime 37.0.1
Helpful Resources
Exploitability
CWE
CWE Icon
KEV
KEV Icon
CWE ID Description
CWE-772 The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?

This vulnerability is a memory leak in the Wasmtime runtime's C/C++ API versions 37.0.0 and 37.0.1 when using the `anyref` or `externref` WebAssembly values. It was caused by a regression during a refactoring that changed how memory ownership is handled, specifically moving from a manual unrooting system to an automatic one in Rust. However, the C/C++ APIs were not fully updated to reflect this change, leading to permanent memory leaks when these reference types are used. The Rust API is unaffected, and the issue is fixed in version 37.0.2.


How can this vulnerability impact me? :

This vulnerability can cause memory leaks in applications embedding Wasmtime via the C/C++ API when using `anyref` or `externref` types. Over time, this can lead to increased memory usage and potentially degrade system performance or cause resource exhaustion if the leaks accumulate. If these reference types are not used, or if the Rust API is used instead, the issue does not occur.


What immediate steps should I take to mitigate this vulnerability?

The immediate step to mitigate this vulnerability is to update Wasmtime to version 37.0.2 or later, where the memory leak issues in the C/C++ API related to `anyref` and `externref` have been fixed. If updating is not possible, avoid using `anyref` and `externref` types in the C/C++ API to prevent memory leaks.


Ask Our AI Assistant
Need more information? Ask your question to get an AI reply (Powered by our expertise)
0/70
EPSS Chart