CVE-2025-61670

LOWNVD 3.33.3
EchelonGraph scoreMEDIUM confidence

This low-severity CVE scores 3.3 under NVD CVSS v3. EPSS exploit probability: 0.2%, top 92% of all CVEs by exploit prediction. GitHub Security Advisory data not yet ingested — confidence will rise once GHSA publishes (typical lag: hours to days for open-source ecosystem CVEs; never for infrastructure-only CVEs).

Triggered by: NVD CVSS baseline
Sources: epss, nvd
3.3
EchelonGraph verdictMonitorLow exploitation likelihood right now — keep watching.
  • Lower severity and no public exploit yet
CISA-KEV: Not listedEPSS: 0%CVSS: 3.3Exploit: NoneExposed: 0

No vendor fix yet — apply a workaround or compensating control (WAF / firewall / segmentation) and watch for a patch.

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 type to a new OwnedRooted 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, 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 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 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 vs ManuallyRooted is that the OwnedRooted type allocates host memory outside of the store. This means that if an OwnedRooted 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 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 v3
3.3
EG Score
3.3(medium)
EG Risk
15(Track)
EG Risk 15/100SSVC: Track

EG Risk is EchelonGraph's 0–100 priority score: it fuses intrinsic severity with real-world exploitation and automatability so you can rank equal-severity CVEs and fix the most dangerous first. Higher = act sooner. Distinct from the 0–10 EG Score (severity).

How it’s computed
Severity33% × 45%
Exploitation0% × 40%
Automatability0% × 15%
Action: Routine — remediate on your standard cadence.
EPSS
7.5%
KEV
Not listed

Published

October 7, 2025

Last Modified

June 17, 2026

Vendor Advisories for CVE-2025-61670(1)

These vendors published their own advisory mentioning this CVE — often with vendor-specific remediation steps + affected product lists not in NVD.

Affected Packages

(2 across 2 ecosystems)
crates.io(1)
PackageVulnerable rangeFixed inDependents
wasmtime-c-api-impl37.0.2
PyPI(1)
PackageVulnerable rangeFixed inDependents
wasmtime-bin36.0.937.0.2

Weakness Classification(1)

MITRE Common Weakness Enumeration — the root-cause categories this CVE belongs to.

Data Freshness Timeline

(refreshed 12× in last 7d / 45× in last 30d)

Each row is a source pipeline that fetched or updated this CVE on that date, with what changed. For example, "NVD update" means NVD published or revised its analysis for this CVE; "MITRE cvelistV5" means we ingested or refreshed it from the CNA feed. Most recent first.

  1. 2026-07-23 14:18 UTCEPSS rescore
  2. 2026-07-23 14:18 UTCEPSS rescore
  3. 2026-07-23 03:00 UTCEG score recompute
  4. 2026-07-22 14:08 UTCEPSS rescore
  5. 2026-07-21 15:24 UTCEPSS rescore
  6. 2026-07-20 17:08 UTCEPSS rescore
  7. 2026-07-19 14:30 UTCEPSS rescore
  8. 2026-07-19 14:30 UTCEPSS rescore
  9. 2026-07-19 02:28 UTCEPSS rescore
  10. 2026-07-18 10:04 UTCEPSS rescore
  11. 2026-07-18 10:04 UTCEPSS rescore
  12. 2026-07-16 17:02 UTCEPSS rescore
  13. 2026-07-15 16:57 UTCEPSS rescore
  14. 2026-07-15 16:57 UTCEPSS rescore
  15. 2026-07-15 01:59 UTCEPSS rescore
  16. 2026-07-15 01:59 UTCEPSS rescore
  17. 2026-07-13 22:29 UTCEPSS rescore
  18. 2026-07-13 06:12 UTCEPSS rescore
  19. 2026-07-12 05:46 UTCEPSS rescore
  20. 2026-07-11 08:27 UTCEPSS rescore
  21. 2026-07-09 19:09 UTCEPSS rescore
  22. 2026-07-08 15:15 UTCEPSS rescore
  23. 2026-07-07 13:46 UTCEPSS rescore
  24. 2026-07-06 12:41 UTCOSV refresh
  25. 2026-07-06 02:23 UTCEPSS rescore
Show 64 more
  1. 2026-07-06 02:23 UTCEPSS rescore
  2. 2026-07-05 02:30 UTCEPSS rescore
  3. 2026-07-05 02:30 UTCEPSS rescore
  4. 2026-07-04 06:31 UTCEPSS rescore
  5. 2026-07-04 06:30 UTCEPSS rescore
  6. 2026-07-01 15:06 UTCEPSS rescore
  7. 2026-07-01 15:06 UTCEPSS rescore
  8. 2026-06-30 23:22 UTCEPSS rescore
  9. 2026-06-29 14:06 UTCEPSS rescore
  10. 2026-06-29 14:06 UTCEPSS rescore
  11. 2026-06-28 14:07 UTCEPSS rescore
  12. 2026-06-28 14:07 UTCEPSS rescore
  13. 2026-06-28 04:56 UTCEPSS rescore
  14. 2026-06-28 04:55 UTCEPSS rescore
  15. 2026-06-27 03:08 UTCEPSS rescore
  16. 2026-06-25 13:49 UTCEPSS rescore
  17. 2026-06-24 14:04 UTCEPSS rescore
  18. 2026-06-24 14:04 UTCEPSS rescore
  19. 2026-06-23 21:32 UTCEPSS rescore
  20. 2026-06-23 21:32 UTCEPSS rescore
  21. 2026-06-22 14:25 UTCEPSS rescore
  22. 2026-06-21 14:56 UTCEPSS rescore
  23. 2026-06-21 14:56 UTCEPSS rescore
  24. 2026-06-21 01:59 UTCEPSS rescore
  25. 2026-06-21 01:59 UTCEPSS rescore
  26. 2026-06-19 19:25 UTCEPSS rescore
  27. 2026-06-19 19:25 UTCEPSS rescore
  28. 2026-06-18 17:52 UTCEPSS rescore
  29. 2026-06-18 17:52 UTCEPSS rescore
  30. 2026-06-18 00:43 UTCOSV refresh
  31. 2026-06-17 17:52 UTCEPSS rescore
  32. 2026-06-16 17:52 UTCEPSS rescore
  33. 2026-06-15 17:48 UTCEPSS rescore
  34. 2026-06-15 17:48 UTCEPSS rescore
  35. 2026-06-14 23:18 UTCEPSS rescore
  36. 2026-06-13 23:00 UTCEPSS rescore
  37. 2026-06-13 23:00 UTCEPSS rescore
  38. 2026-06-12 23:11 UTCEPSS rescore
  39. 2026-06-11 14:00 UTCEPSS rescore
  40. 2026-06-10 22:18 UTCEPSS rescore
  41. 2026-06-10 22:18 UTCEPSS rescore
  42. 2026-06-10 13:22 UTCEPSS rescore
  43. 2026-06-08 14:17 UTCEPSS rescore
  44. 2026-06-08 14:16 UTCEPSS rescore
  45. 2026-06-07 15:24 UTCEPSS rescore
  46. 2026-06-07 15:24 UTCEPSS rescore
  47. 2026-06-06 13:47 UTCEPSS rescore
  48. 2026-06-06 13:47 UTCEPSS rescore
  49. 2026-06-05 22:46 UTCEPSS rescore
  50. 2026-06-05 22:46 UTCEPSS rescore
  51. 2026-06-05 06:10 UTCEPSS rescore
  52. 2026-06-05 06:10 UTCEPSS rescore
  53. 2026-06-04 13:12 UTCEPSS rescore
  54. 2026-06-04 13:12 UTCEPSS rescore
  55. 2026-06-02 20:13 UTCEPSS rescore
  56. 2026-06-02 20:12 UTCEPSS rescore
  57. 2026-06-01 13:51 UTCEPSS rescore
  58. 2026-06-01 13:51 UTCEPSS rescore
  59. 2026-05-31 22:30 UTCEPSS rescore
  60. 2026-05-31 22:30 UTCEPSS rescore
  61. 2026-05-31 00:16 UTCEPSS rescore
  62. 2026-05-31 00:16 UTCEPSS rescore
  63. 2026-05-29 21:14 UTCEG score recompute
  64. 2026-05-29 13:44 UTCEPSS rescore

Frequently asked(5)

What is CVE-2025-61670?
CVE-2025-61670 is a low vulnerability published on October 7, 2025. 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…
When was CVE-2025-61670 disclosed?
CVE-2025-61670 was first published in the National Vulnerability Database on October 7, 2025, with the most recent update on June 17, 2026. EchelonGraph re-ingests CVE updates from NVD on a 2-hour cycle, so this page reflects the latest published state.
Is CVE-2025-61670 actively exploited?
CVE-2025-61670 is not currently on CISA's Known Exploited Vulnerabilities catalog. FIRST EPSS estimates a 7.5% percentile likelihood of exploitation in the next 30 days — higher percentiles indicate greater predicted risk.
What is the CVSS score of CVE-2025-61670?
CVE-2025-61670 has a CVSS v3 base score of 3.3 (NVD).
How do I remediate CVE-2025-61670?
Patch to the fixed version published by the affected vendor. Where vendor advisories exist for CVE-2025-61670, EchelonGraph cross-links them in the Vendor Advisories panel below — those typically contain the canonical remediation steps, fixed version numbers, and any vendor-specific mitigations.

Dependency Blast Radius

See which npm, PyPI, Go, and Maven packages are affected by CVE-2025-61670

Explore →

Is Your Infrastructure Affected by CVE-2025-61670?

EchelonGraph automatically scans your cloud infrastructure and maps CVE exposure using blast radius analysis.