CVE-2025-61670: Memory Leak in Wasmtime C/C++ API WebAssembly GC Reference Handling

Wasmtime is a high-performance, open-source WebAssembly runtime developed by the Bytecode Alliance. It supports running WebAssembly modules outside of browser environments, often embedded into larger host programs using various language bindings. The C and C++ bindings expose critical APIs for configuring runtime environments, handling WebAssembly stores, and interacting with guest-exported functions.

WebAssembly garbage collection (Wasm-GC) types, specifically anyref and externref, allow guest modules to safely reference host-allocated objects and general-purpose garbage-collected data. The host tracks these references to ensure objects remain alive during module execution and are safely reclaimed when no longer in use. Managing the lifecycle of these cross-boundary references requires tight coordination between Wasmtime's internal Rust core and the thin C/C++ FFI wrappers.

CVE-2025-61670 represents a resource management vulnerability (CWE-772) in the C and C++ APIs of Wasmtime versions 37.0.0 and 37.0.1. Due to mismatched memory ownership models introduced during an internal Rust-level refactoring, references of type anyref and externref fail to be released from the host heap. Consequently, applications employing these APIs to exchange reference types with WebAssembly guests will leak memory indefinitely.

The technical boundary of this vulnerability is strictly restricted to the C and C++ language layers. The primary Rust engine does not leak these references during pure Rust execution, as its internal garbage collection hooks execute as designed. However, any downstream language wrapper or application relying on the C-API integration will inherit the memory leak conditions.

Prior to Wasmtime version 37.0.0, reference-type lifecycles were bound to the parent wasmtime_store_t via the ManuallyRooted<T> wrapper. Under this architectural design, any unreleased reference was ultimately reclaimed when the host application destroyed the WebAssembly store. While temporary leaks could occur within the store's lifecycle, the store acted as a strict upper memory limit, preventing unbounded exhaustion of the host's virtual memory space.

In Wasmtime version 37.0.0, the core runtime transitioned from ManuallyRooted<T> to OwnedRooted<T> to simplify internal reference tracking. Unlike its predecessor, OwnedRooted<T> allocates the reference management structure directly on the host heap outside the boundary of the WebAssembly store. The memory management of OwnedRooted<T> relies exclusively on Rust's native deterministic destruction (Drop trait) to trigger deallocation.

This architectural change broke the lifecycle assumptions of the C and C++ API layers. Because the FFI bindings did not correctly bridge Rust's Drop mechanics to the wrapping C/C++ objects, the host memory backing these references was never freed. This disconnect manifested in three distinct code paths: a typo in the C API unroot function, a failure to unroot returned values from host-defined imports, and missing resource acquisition is initialization (RAII) implementations in the C++ wrappers.

The diagram below illustrates the structural differences in reference management and lifetime boundaries between the legacy architecture and the vulnerable versions:

The primary FFI failure occurred in crates/c-api/src/val.rs where the Rust implementation of the C-binding function wasmtime_val_unroot had a typo. The function attempted to inspect and release the internal GC references using as_externref rather than retrieving and consuming the wrapper with from_externref. As a result, calling wasmtime_val_unroot in C or C++ was a structural no-op, preventing even manual deallocation of the host-allocated GC references.

To resolve this, the patch introduced proper Drop implementations for FFI-facing structs on the Rust side, ensuring that when the C API structs are dropped, their inner ManuallyDrop wrappers are correctly consumed. The following annotated code snippet shows the corrected implementation:

// crates/c-api/src/val.rs - Corrected FFI Drop Mechanics
impl Drop for wasmtime_val_t {
    fn drop(&mut self) {
        unsafe {
            match self.kind {
                crate::WASMTIME_ANYREF => {
                    // Correctly take and drop the inner reference
                    let _ = ManuallyDrop::take(&mut self.of.anyref);
                }
                crate::WASMTIME_EXTERNREF => {
                    // Correctly take and drop the outer reference
                    let _ = ManuallyDrop::take(&mut self.of.externref);
                }
                _ => {}
            }
        }
    }
}

In addition to the Rust FFI fixes, the C++ API wrapper layer required an implementation of the Rule of Five to ensure proper RAII compliance. The C++ classes ExternRef, AnyRef, and Val were updated to handle copying, moving, and destruction. Below is the patched version of the ExternRef class in crates/c-api/include/wasmtime/val.hh:

// crates/c-api/include/wasmtime/val.hh - Patched RAII Wrapper
class ExternRef {
  wasmtime_externref_t val;
public:
  // Copy constructor cloning the underlying reference
  ExternRef(const ExternRef &other) {
    wasmtime_externref_clone(&other.val, &val);
  }
 
  // Copy assignment operator freeing old resource and cloning new
  ExternRef &operator=(const ExternRef &other) {
    wasmtime_externref_unroot(&val);
    wasmtime_externref_clone(&other.val, &val);
    return *this;
  }
 
  // Move constructor transferring ownership without cloning
  ExternRef(ExternRef &&other) {
    val = other.val;
    wasmtime_externref_set_null(&other.val);
  }
 
  // Move assignment operator freeing old resource and transferring ownership
  ExternRef &operator=(ExternRef &&other) {
    wasmtime_externref_unroot(&val);
    val = other.val;
    wasmtime_externref_set_null(&other.val);
    return *this;
  }
 
  // Destructor invoking FFI unroot logic
  ~ExternRef() {
    wasmtime_externref_unroot(&val);
  }
};

Exploitation of CVE-2025-61670 requires an environment where untrusted WebAssembly guest modules are executed within a host application that exposes host-defined functions via the Wasmtime C or C++ APIs. The guest module must call these host imports repeatedly, forcing the host to return or allocate GC references (externref or anyref). Because these operations allocate heap memory that is never reclaimed, a malicious module can easily exhaust host resources.

The execution flow of a denial-of-service attack begins with the guest module invoking a host-defined import that returns a reference. In the vulnerable runtime, the FFI layer fails to track the return lifetime, leaving the OwnedRooted<T> wrapper allocated on the host heap. The guest module drops its local WebAssembly handle immediately, but the underlying host allocation persists.

By executing this pattern within a loop, the guest module bypasses the memory limits enforced on the WebAssembly store. The host process memory usage increases linearly with each callback execution. The attack terminates when the host system runs out of physical memory, triggering the operating system's Out-Of-Memory (OOM) killer to terminate the host process.

The impact of this vulnerability is classified as an availability failure (Denial of Service). While standard sandbox architectures isolate WebAssembly guest memory from the host, CVE-2025-61670 allows guests to bypass these boundaries by leaking memory outside the guest store. In multi-tenant systems where multiple isolated modules run within the same host process, a single malicious module can crash the host, impacting all co-located users.

The CVSS v3.1 score is evaluated at 3.3 (Low Severity), reflecting the local nature of the attack vector and the lack of confidentiality or integrity compromise. However, in modern cloud architectures deploying WebAssembly as an edge compute platform, this low-severity rating may underrepresent the operational impact. A crash of the edge runner process directly impacts service availability for all concurrent connections.

No known public exploits or evidence of active exploitation exist in the wild. The vulnerability's EPSS score of 0.00178 indicates a low probability of imminent exploitation. Nevertheless, the construction of a denial-of-service payload is trivial, requiring only basic WebAssembly module compilation and execution.

The primary remediation for CVE-2025-61670 is upgrading the Wasmtime engine to version 37.0.2 or higher. The patch fully addresses the FFI unroot typo and implements proper RAII lifecycle management across the C and C++ wrappers. Applications compiled against the corrected SDK headers will automatically release GC references when wrapper objects go out of scope.

For environments where upgrading is not immediately feasible, developers must implement structural workarounds to avoid cross-boundary reference passing. Instead of returning externref or anyref types directly from host imports, host applications should maintain an internal registry of active objects. The host can then exchange simple 32-bit integer indices (handles) with the WebAssembly guest.

This index-based approach keeps object lifetimes under the absolute control of the host registry. When the guest indicates it no longer requires the resource, the host can safely remove the entry from its registry, ensuring that no FFI-level GC tracking occurs. This pattern completely bypasses the vulnerable OwnedRooted<T> code paths.