Skip to content
Noroxi
NVD / CVE Program· CNA GitHub_M

CVE-2025-61670: Wasmtime has memory leak in C API with `externref` and `anyref` types

Noroxi assessment

Priority: Monitor (action score 4/100)

  • The sources we track (CISA KEV, Exploit-DB, Metasploit, Nuclei, GitHub) show no public exploit code or exploitation in the wild.
  • Probability of exploitation in the next 30 days: 0.19% (FIRST EPSS).
  • Someone on the same network segment can trigger it. A low-privileged account is enough. No special conditions are required; it is repeatable.
  • Fixed version: wasmtime-c-api-impl (crates.io) 37.0.2; wasmtime-bin (PyPI) 37.0.2.

Low priority for now. Upgrade to wasmtime-c-api-impl (crates.io) 37.0.2; wasmtime-bin (PyPI) 37.0.2 or later.

Generated automatically from the record's data: CVSS (NVD and CNA), CISA KEV and SSVC, FIRST EPSS, exploit sources, fixed versions. How we calculate it

Primary sources: NVD · CVE.org · FIRST EPSS

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.

LowCVSS 1.0 · v4.0—No exploit Fix available
Published
Oct 7, 2025
Updated
Jun 17, 2026
EPSS
0.1% · 9th percentile

Report tools

JSON

Action score

4

Monitor

Low priority for now.

CVSS
4 / 40 · 1.0 / 10
CISA KEV
0 / 30 · Not listed
EPSS
0 / 30 · 0.1%

CISA SSVC decision

Exploitation
none
Automatable
no
Technical impact
partial

Vulnrichment: CISA's decision-tree inputs.

CNA vs NVD score

NVD
—
CNA · GitHub_M
1.0
NVD has not scored this yet; the score shown is the CNA’s.

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

The score given by the assigning authority versus NVD’s independent score. A gap means the severity is contested.

Get told when this record changes

  • Not in KEV: no record of exploitation in the wild
  • No public exploit code on record
  • A fix has been released

If any of these changes, we'll tell you in the daily email digest.

Follow CVE-2025-61670

When you'll hear from us

  • when it enters CISA KEV
  • when exploit code appears or is weaponized
  • when the record is updated (including a fixed version)
  • when EPSS rises 20 points in a week

One daily email digest (06:00 UTC); connect a webhook for KEV listings and weaponized exploits instantly.

Your free account also gets you

Running WordPress? Scan your site free with WP Lens

  • Stack alerts: add the products and versions you run, get the new CVEs that affect them
  • Uptime monitoring: 1 site, instant email when it goes down
  • Add your domain: subdomains and takeover risk scanned every week (1 domain)
  • 10 scans an hour on the security tools (3 a day without an account), an API key and MCP
  • All your scans in one panel: findings, what changed in the last scan, a report per domain or per client (PDF, share link)
All free tools

Running WordPress? Scan your site free with WP Lens

Is your version affected? Check it

Noroxi analysis

What does it mean in your environment?

The assessment above is generated automatically from the record's data; it doesn't know your environment. Our team verifies on your systems whether this vulnerability is actually exploitable and which mitigation is enough.

We use this product, ask for help

Affected systems

Is your version affected?

Pick the product and type the version you run. It's compared with this record's version ranges in your browser; the version isn't sent anywhere.

VendorProduct
bytecodealliancewasmtime

Affected versions

NVD version ranges (for catalog products). Add the product to your stack with a version and matching uses these.

  • bytecodealliance wasmtime37.0.0
  • bytecodealliance wasmtime37.0.1

Versions reported by the vendor

Affected version ranges reported by the assigning authority (GitHub_M). Independent of NVD's CPE analysis and usually ahead of it.

  • bytecodealliance wasmtime

    • >= 37.0.0, < 37.0.2affected

Package-level exposure

OSV and GitHub Advisory data: ecosystem, package and range. SBOM matching uses this table.

EcosystemPackageAffected rangeFix
crates.iowasmtime-c-api-implfrom 37.0.0 · before 37.0.237.0.2
PyPIwasmtime-binbefore 37.0.237.0.2
PyPIwasmtime-binup to and including 37.0.0—
PyPIwasmtime-binup to and including 37.0.1—

Other highest-scoring records for the same primary product.

  • CVE-2026-115893Wasmtime: Cranelift backend on aarch64 can jump to incorrect target on large Wasm `br_table` instruction
    39Monitor
  • CVE-2026-115889Wasmtime: Bit-packing in Cranelift compiler causes silent overflow and miscompilation
    39Monitor
  • CVE-2022-39394wasmtime_trap_code C API function has out of bounds write vulnerability
    39Monitor

Published before and after this one in the same product

  • ← EarlierCVE-2024-51745Nov 5, 2024 · Wasmtime doesn't fully sandbox all the Windows device filenames
    9Monitor
  • ← EarlierCVE-2025-53901Jul 18, 2025 · Wasmtime has host panic with `fd_renumber` WASIp1 function
    14Monitor
  • Later →CVE-2025-62711Oct 24, 2025 · Wasmtime vulnerable to segfault when using component resources
    8Monitor

Remediation

Which version to upgrade to

Fix versions compiled from the vendor, package registries and Microsoft. Verify the vendor's note before upgrading.

Product / packageFixed versionSource
crates.io:wasmtime-c-api-impl37.0.2Package registry (OSV)
PyPI:wasmtime-bin37.0.2Package registry (OSV)

Exploit status

No known public exploit

No public exploit has been observed yet. That doesn't mean you're safe, only that the bar is a little higher.

Research context

For pentesters and researchers: attack profile, score disagreement, timeline, patch commits, credits, variant and chain candidates, bug bounty scope. All derived from existing data; no exploit code.

Timeline

From publication to today: proof of concept, Metasploit module, CISA KEV and fix record. Dates are as reported by the sources.

No dated events beyond publication.

No history yet (it accumulates with the daily EPSS job).

Patch and commit links

Commit, PR and diff links among the references. A starting point for patch-diffing and variant hunting; fixes, not exploits.

Finders, reporters and analysts named in the CNA record. Click a name for that researcher’s other records.

No credits in the CNA record.

Variant candidates

Same product, same weakness class, within 18 months. If the patch missed the root cause, the sibling bug is here.

No nightly-computed relations.

Chain candidates

An authentication bypass and a privilege-requiring bug in the same product, published close together: combined they may become an unauthenticated path.

—

Bug bounty scope

No known public program.

Source: bounty-targets-data (public HackerOne, Bugcrowd, Intigriti, YesWeHack listings).

Technical details

Attack conditions

  • Someone on the same network segment can trigger it.
  • A low-privileged account is enough.
  • No special conditions are required; it is repeatable.

If successful

Confidentiality
Integrity
Availability
Attack vector
Adjacent
Attack complexity
Low
Privileges required
Low
User interaction
P
Scope
X

CVSS vector

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/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

nvd-secondary

Attack context

MITRE CAPEC attack patterns and ATT&CK techniques for this weakness class (CWE). A starting point for detection rules and threat hunting.

Change log

  1. Fix✗ → ✓

For records you follow, these changes also arrive as notifications. →

References

All records