{"answers":{"affected":"5 open source packages ship an affected version, including wasmtime-bin and wasmtime-c-api-impl. It affects 1 product.","exploited":"There is no known exploitation of CVE-2025-61670 in the wild and no public exploit code.","fix":"Upgrade wasmtime-bin to 37.0.2 or later.","what":"CVE-2025-61670 is a low-severity denial of service vulnerability in bytecodealliance wasmtime, published on 7 Oct 2025. It can only be exploited from the same machine or local network, and only if a user opens a file or follows a link."},"fix_prompt":"Check this codebase for CVE-2025-61670 and fix it if it is affected.\n\nWhat it is: CVE-2025-61670 is a low-severity denial of service vulnerability in bytecodealliance wasmtime, published on 7 Oct 2025. It can only be exploited from the same machine or local network, and only if a user opens a file or follows a link.\nExploitation: There is no known exploitation of CVE-2025-61670 in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- wasmtime-bin (PyPI): affected all versions up to 37.0.0; no fix listed\n- wasmtime-bin (PyPI): affected all versions; fixed in 37.0.2\n- wasmtime-bin (PyPI): affected all versions; fixed in 37.0.2\n- wasmtime-c-api-impl (crates.io): affected from 37.0.0; fixed in 37.0.2\n- wasmtime-c-api-impl (crates.io): affected from 37.0.0; fixed in 37.0.2\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/CVE-2025-61670/ (Markdown: https://insights.sbomify.com/CVE-2025-61670/index.md)","id":"CVE-2025-61670","markdown":"https://insights.sbomify.com/CVE-2025-61670/index.md","name":"CVE-2025-61670","record":{"aliases":["GHSA-vvp9-h8p2-xwfc","PYSEC-2025-268"],"analysis":{"component_type":"library","fix_type":"upgrade","impacts":["denial_of_service"],"network_reachable":"adjacent_or_local","non_default_config":false,"product_category":"WebAssembly runtime library","requires_auth":"low_privilege","summary":"Attackers can cause permanent memory leaks in Wasmtime C/C++ APIs using anyref or externref, leading to resource exhaustion and denial of service.","user_interaction":"required","vuln_class":"denial_of_service"},"analysis_generated_by":"qwen3.8-flash-next","assigner":"GitHub_M","cpe":[{"product":"wasmtime","vendor":"bytecodealliance"}],"cvss":{"score":1,"severity":"low","source":"cna","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","version":"4.0"},"cwes":[{"id":"CWE-772","name":"Missing Release of Resource after Effective Lifetime"}],"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.\n\nDevelopment of Wasmtime 37.0.0 included a refactoring in Rust of changing the old `ManuallyRooted\u003cT\u003e` type to a new `OwnedRooted\u003cT\u003e` 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\u003cT\u003e`, 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\u003cT\u003e` 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\u003cT\u003e` 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\u003cT\u003e` vs `ManuallyRooted\u003cT\u003e` is that the `OwnedRooted\u003cT\u003e` type allocates host memory outside of the store. This means that if an `OwnedRooted\u003cT\u003e` is leaked then destroying a store does not release this memory and it's a permanent memory leak on the host.\n\nThis 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\u003cT\u003e` 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 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.","ecosystems":["PyPI","crates.io"],"exploits":{"exploitdb":0,"first_seen":null,"github_poc":0,"max_poc_stars":null,"metasploit":0,"nuclei":0,"refs":[],"tier":"none_known"},"has_fix":true,"headline":"Wasmtime has memory leak in C API with `externref` and `anyref` types","id":"CVE-2025-61670","indexable":true,"kev":null,"kind":"cve","links":{"ecosystem":"PyPI","product":null,"products":[],"type":"denial_of_service","year":"2025"},"n_packages":5,"n_references":3,"next":{"headline":"Further research determined the issue is not an open source vulnerability.","id":"CVE-2025-61671"},"packages":[{"ecosystem":"PyPI","fixed":[],"introduced":["0"],"last_affected":["37.0.0","37.0.1"],"package":"wasmtime-bin","purl":"pkg:pypi/wasmtime-bin","source":"PYSEC-2025-268"},{"ecosystem":"PyPI","fixed":["37.0.2"],"introduced":["0"],"last_affected":[],"package":"wasmtime-bin","purl":null,"source":"GHSA-vvp9-h8p2-xwfc"},{"ecosystem":"PyPI","fixed":["37.0.2"],"introduced":["0"],"last_affected":[],"package":"wasmtime-bin","purl":"pkg:pypi/wasmtime-bin","source":"GHSA-vvp9-h8p2-xwfc"},{"ecosystem":"crates.io","fixed":["37.0.2"],"introduced":["37.0.0"],"last_affected":[],"package":"wasmtime-c-api-impl","purl":null,"source":"GHSA-vvp9-h8p2-xwfc"},{"ecosystem":"crates.io","fixed":["37.0.2"],"introduced":["37.0.0"],"last_affected":[],"package":"wasmtime-c-api-impl","purl":"pkg:cargo/wasmtime-c-api-impl","source":"GHSA-vvp9-h8p2-xwfc"}],"prev":{"headline":"jupyter_server next parameter open redirect can redirect users to external domains","id":"CVE-2025-61669"},"products":["wasmtime"],"published":"2025-10-07","related":[{"cvss_score":9,"headline":"Wasmtime miscompiled guest heap access enables sandbox escape on aarch64 Cranelift","id":"CVE-2026-34971","kev_date_added":null,"published":"2026-04-09"},{"cvss_score":9,"headline":"Wasmtime with Winch compiler backend on aarch64 may allow a sandbox-escaping memory access","id":"CVE-2026-34987","kev_date_added":null,"published":"2026-04-09"},{"cvss_score":8.6,"headline":"Wasmtime vulnerable to data leakage between instances in the pooling allocator","id":"CVE-2022-39393","kev_date_added":null,"published":"2022-11-10"},{"cvss_score":8.1,"headline":"Use after free in Wasmtime","id":"CVE-2022-24791","kev_date_added":null,"published":"2022-03-31"},{"cvss_score":7.5,"headline":"Wasmtime: WASI path_open(TRUNCATE) bypasses `FilePerms::WRITE` host restriction","id":"CVE-2026-47261","kev_date_added":null,"published":"2026-06-15"},{"cvss_score":6.9,"headline":"Wasmtime has a Heap OOB read in component model UTF-16 to latin1+utf16 string transcoding","id":"CVE-2026-34941","kev_date_added":null,"published":"2026-04-09"},{"cvss_score":6.9,"headline":"Wasmtime is vulnerable to panic when dropping a `[Typed]Func::call_async` future","id":"CVE-2026-27195","kev_date_added":null,"published":"2026-02-24"}],"sources":[{"class":"attribution","licence":"CVE Terms of Use (MITRE)","name":"CVE List","prefix":"CVE"},{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"},{"class":"attribution","licence":"CC BY 4.0","name":"PyPA Advisory Database","prefix":"PYSEC"},{"class":"attribution","licence":"US public information, NVD API terms","name":"NVD"},{"class":"attribution","licence":"CWE Terms of Use","name":"CWE (MITRE)"},{"class":"attribution","licence":"FIRST CVSS licence","name":"CVSS (FIRST)"}],"ssvc":{"automatable":"no","exploitation":"none","technical_impact":"partial"},"state":"PUBLISHED","updated":"2025-10-07","vendors":["bytecodealliance"]},"summary":"Attackers can cause permanent memory leaks in Wasmtime C/C++ APIs using anyref or externref, leading to resource exhaustion and denial of service.","url":"https://insights.sbomify.com/CVE-2025-61670/"}