Skip to main content
DashboardThreatsMapFeedsAPI
reconnecting
Press slash or control plus K to focus the search. Use the arrow keys to navigate results and press enter to open a threat.
Reconnecting to live updates…

CVE-2025-61670: CWE-772: Missing Release of Resource after Effective Lifetime in bytecodealliance wasmtime

0
Low
VulnerabilityCVE-2025-61670cvecve-2025-61670cwe-772
Published: Tue Oct 07 2025 (10/07/2025, 18:49:53 UTC)
Source: CVE Database V5
Vendor/Project: bytecodealliance
Product: wasmtime

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.

AI-Powered Analysis

AILast updated: 10/07/2025, 19:15:23 UTC

Technical Analysis

Wasmtime is a WebAssembly runtime that provides C, C++, and Rust APIs for embedding WebAssembly modules. In versions 37.0.0 and 37.0.1, a refactoring replaced the old `ManuallyRooted<T>` type with a new `OwnedRooted<T>` type to manage memory ownership more safely in Rust. However, this change was not fully propagated to the C and C++ APIs, leading to memory leaks when using `anyref` or `externref` WebAssembly reference types. Previously, `ManuallyRooted<T>` required manual unrooting, but memory was still bound to the store and cleaned up when the store was destroyed. The new `OwnedRooted<T>` type allocates host memory outside the store, so leaked references cause permanent memory leaks that are not freed upon store destruction. A typo in the `wasmtime_val_unroot` function meant it failed to unroot values, and the C++ API lacked destructors for these reference types, causing idiomatic usage to leak memory. The Rust API is unaffected because it uses automatic destructors. These leaks can accumulate if host-defined functions return these reference types without proper unrooting, potentially leading to resource exhaustion. The issue was fixed in Wasmtime 37.0.2 by correcting the unroot function, adding destructors in the C++ API, and updating ownership semantics. The vulnerability is classified under CWE-772 (Missing Release of Resource after Effective Lifetime) and has a CVSS 4.0 score of 1.0, indicating low severity. No known exploits are reported. The only mitigation besides patching is to avoid using `anyref` and `externref` in the vulnerable versions.

Potential Impact

The primary impact of this vulnerability is a memory leak that can lead to resource exhaustion on hosts running Wasmtime 37.0.0 or 37.0.1 with C/C++ API usage of `anyref` or `externref`. Over time, this can degrade system performance, cause application instability, or lead to denial of service due to out-of-memory conditions. Since the leak does not affect confidentiality or integrity, the risk is limited to availability degradation. For European organizations, especially those embedding Wasmtime in performance-critical or resource-constrained environments, this could disrupt services or increase operational costs due to increased memory usage. The vulnerability requires some level of interaction and privileges, limiting remote exploitation scope. However, organizations using Wasmtime in cloud, edge computing, or embedded systems should be aware of potential impacts on uptime and reliability. The lack of known exploits reduces immediate risk but does not eliminate the need for timely remediation.

Mitigation Recommendations

European organizations should upgrade all Wasmtime deployments to version 37.0.2 or later to fully resolve the memory leak issues. If upgrading immediately is not feasible, avoid using the `anyref` and `externref` reference types in the C/C++ API to prevent triggering the leak. Review and audit code that embeds Wasmtime to identify usage of these reference types and refactor to eliminate or replace them where possible. Implement monitoring of memory usage for applications embedding Wasmtime to detect abnormal growth indicative of leaks. For long-running processes, consider periodic restarts as a temporary mitigation to release leaked memory. Engage with Wasmtime maintainers or community for updates on API changes if migrating to version 38.0.0 or later. Finally, incorporate this vulnerability into vulnerability management and patching workflows to ensure timely updates.

Need more detailed analysis?Get Pro

Technical Details

Data Version
5.1
Assigner Short Name
GitHub_M
Date Reserved
2025-09-29T20:25:16.180Z
Cvss Version
4.0
State
PUBLISHED

Threat ID: 68e56349a677756fc99d1128

Added to database: 10/7/2025, 7:00:25 PM

Last enriched: 10/7/2025, 7:15:23 PM

Last updated: 10/8/2025, 6:35:46 PM

Views: 16

Community Reviews

0 reviews

Crowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.

Sort by
Loading community insights…

Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.

Actions

PRO

Updates to AI analysis are available only with a Pro account. Contact root@offseq.com for access.

Please log in to the Console to use AI analysis features.

Need enhanced features?

Contact root@offseq.com for Pro access with improved analysis and higher rate limits.

Latest Threats