Vulnerabilities in pkg:pypi/wasmtime-bin

PACKAGE
Advisory Identifier: GHSA-vvp9-h8p2-xwfc
Advisory Summary

CVE-2025-61670 is a LOW (CVSS 3.3) memory leak vulnerability (CWE-772: Missing Release of Resource after Effective Lifetime) affecting Wasmtime libraries in the crates.io ecosystem. The issue involves memory leak in c api with `externref` and `anyref` types. Remediation is available by upgrading affected packages to version 37.0.2.

1 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:pypi/wasmtime-bin

1 Known Advisory Record(s)

Vulnerability advisories affecting package pkg:pypi/wasmtime-bin. Select an advisory below to view technical details or fixes.

Advisory ID CVE / NVD Severity Summary
GHSA-vvp9-h8p2-xwfc CVE-2025-61670 LOW Wasmtime: Memory leak in C API with `externref` and `anyref` types

CVE-2025-61670 at a Glance

CVE Identifier CVE-2025-61670
GHSA Identifier GHSA-vvp9-h8p2-xwfc
Severity LOW
CVSS v3.1 Base Score 3.3
CWE Classification CWE-772: Missing Release of Resource after Effective Lifetime
Affected Product Wasmtime
Package Ecosystem crates.io
Published Date
Last Updated

Security Impact

CVSS: 3.3

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L).

Attack Vector Local (AV:L)
Attack Complexity Low (AC:L)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality None (C:N)
Integrity None (I:N)
Availability Low (A:L)

How to Fix CVE-2025-61670

To remediate this vulnerability, upgrade all affected Wasmtime dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

wasmtime-c-api-impl fixed: 37.0.2
Upgrade wasmtime-c-api-impl to 37.0.2
wasmtime-bin fixed: 37.0.2
pip install wasmtime-bin>=37.0.2
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for wasmtime-c-api-impl

How to Check if You Are Affected

To determine whether your application is affected by CVE-2025-61670, inspect your project dependencies for Wasmtime:

inspect dependencies for wasmtime-c-api-impl

Analyze the terminal output to locate any version of Wasmtime in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 37.0.2), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-772: Missing Release of Resource after Effective Lifetime, where the product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed. In Wasmtime, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Impact 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 accomodate the API semantic changes. ### Patches Wasmtime 37.0.2 has been released which fixes these issues. Users of 37.0.0 and 37.0.1 are recommended to upgrade. Users of 36.0.x and prior are unaffected and need not upgrade. ### Workarounds 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. ### Remediations The Wasmtime project will be looking more closely into improving the situation around testing the C and C++ APIs of Wasmtime in the near future. For example we plan to integrate ASAN testing to discover leaks and errors earlier on in the development process. We're also going to look into expanding the test coverage of the C/C++ APIs to catch issues like this earlier on in development in the future.

CVE-2025-61670 Affected Wasmtime Versions

2 component(s)
Fixed Versions:
37.0.2
Product / Package Ecosystem Affected Versions Fixed Version
wasmtime-c-api-impl
crates.io
≥ 37.0.0
< 37.0.2
37.0.2
wasmtime-bin
PyPI
< 37.0.2
37.0.2

References

Frequently Asked Questions

What is CVE-2025-61670?
CVE-2025-61670 is a security vulnerability in Wasmtime involving Memory leak in C API with `externref` and `anyref` types under CWE-772: Missing Release of Resource after Effective Lifetime.
Which Wasmtime versions are affected?
Affected versions include releases prior to 37.0.2 across affected packages: wasmtime-c-api-impl, wasmtime-bin.
What version fixes CVE-2025-61670?
Upgrading to 37.0.2 (or the latest patched release for your respective branch) resolves the vulnerability.
Is wasmtime-c-api-impl affected?
Yes, wasmtime-c-api-impl is affected in releases prior to 37.0.2. Upgrade your dependency to 37.0.2 or later.
Is wasmtime-bin affected?
Yes, wasmtime-bin is affected in releases prior to 37.0.2. Upgrade your dependency to 37.0.2 or later.
What is the CVSS score of CVE-2025-61670?
CVE-2025-61670 has a CVSS v3.1 base score of 3.3 (LOW) with vector string CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L.
What CWE is associated with CVE-2025-61670?
CVE-2025-61670 is classified under CWE-772: Missing Release of Resource after Effective Lifetime (The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.).
How can I check crates.io dependencies for CVE-2025-61670?
Run the dependency tree command: 'inspect dependencies for wasmtime-c-api-impl'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-vvp9-h8p2-xwfc",
  "modified" : "2026-07-14T17:48:35Z",
  "published" : "2026-07-14T17:48:35Z",
  "aliases" : [ "CVE-2025-61670" ],
  "summary" : "Wasmtime: Memory leak in C API with `externref` and `anyref` types",
  "details" : "### Impact\n\nWasmtime 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.\n\nDevelopment 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.\n\nIn 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:\n\n* 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.\n* 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.\n* 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.\n\nThese 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 accomodate the API semantic changes.\n\n### Patches\n\nWasmtime 37.0.2 has been released which fixes these issues. Users of 37.0.0 and 37.0.1 are recommended to upgrade. Users of 36.0.x and prior are unaffected and need not upgrade.\n\n### Workarounds\n\nThe 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.\n\n### Remediations\n\nThe Wasmtime project will be looking more closely into improving the situation around testing the C and C++ APIs of Wasmtime in the near future. For example we plan to integrate ASAN testing to discover leaks and errors earlier on in the development process. We're also going to look into expanding the test coverage of the C/C++ APIs to catch issues like this earlier on in development in the future.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L"
  }, {
    "type" : "CVSS_V4",
    "score" : "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"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "crates.io",
      "name" : "wasmtime-c-api-impl"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "37.0.0"
      }, {
        "fixed" : "37.0.2"
      } ]
    } ]
  }, {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "wasmtime-bin"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "37.0.2"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-vvp9-h8p2-xwfc"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2025-61670"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/bytecodealliance/wasmtime/commit/adff9d9d0f09569203709d5687e5a7dc8e1ad0a3"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/bytecodealliance/wasmtime"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/bytecodealliance/wasmtime/releases/tag/v37.0.2"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/pypa/advisory-database/tree/main/vulns/wasmtime-bin/PYSEC-2025-268.yaml"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-772" ],
    "severity" : "LOW",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-07-14T17:48:35Z",
    "nvd_published_at" : "2025-10-07T19:15:38Z"
  }
}