bytecodealliance wasmtime bis 37.0.1 C API Denial of Service

CVSS Meta Temp ScoreAktueller Exploitpreis (≈)CTI Interest Score
3.4$0-$5k0.00

Zusammenfassunginfo

Es wurde eine problematische Schwachstelle in bytecodealliance wasmtime bis 37.0.1 entdeckt. Betroffen davon ist ein unbekannter Prozess der Komponente C API. Mittels Manipulieren mit unbekannten Daten kann eine Denial of Service-Schwachstelle ausgenutzt werden. Diese Schwachstelle wird als CVE-2025-61670 gehandelt. Der Angriff muss über das lokale Netzwerk initiiert werden. Es ist kein Exploit verfügbar. Es wird empfohlen, die betroffene Komponente zu aktualisieren.

Detailsinfo

In bytecodealliance wasmtime bis 37.0.1 wurde eine problematische Schwachstelle ausgemacht. Es geht um unbekannter Code der Komponente C API. Durch Beeinflussen mit einer unbekannten Eingabe kann eine Denial of Service-Schwachstelle ausgenutzt werden. CWE definiert das Problem als CWE-772. Auswirken tut sich dies auf die Verfügbarkeit. Die Zusammenfassung von CVE lautet:

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.

Das Advisory findet sich auf github.com. Die Verwundbarkeit wird seit dem 29.09.2025 als CVE-2025-61670 geführt. Die Ausnutzbarkeit gilt als leicht. Der Angriff kann im lokalen Netzwerk angegangen werden. Um eine Ausnutzung durchzusetzen, muss keine spezifische Authentisierung umgesetzt werden. Eine Ausnutzung erfordert, dass das Opfer eine spezifische Handlung durchführt. Technische Details sind nicht bekannt und ein Exploit zur Schwachstelle ist ebenfalls nicht vorhanden.

Ein Aktualisieren auf die Version 37.0.2 vermag dieses Problem zu lösen. Eine neue Version kann von github.com bezogen werden. Die Schwachstelle lässt sich auch durch das Einspielen des Patches adff9d9d0f09569203709d5687e5a7dc8e1ad0a3 lösen. Dieser kann von github.com bezogen werden. Als bestmögliche Massnahme wird das Upgrade auf eine neue Version empfohlen.

Unter anderem wird der Fehler auch in der Verwundbarkeitsdatenbank von EUVD (EUVD-2025-32904) dokumentiert. Be aware that VulDB is the high quality source for vulnerability data.

Produktinfo

Hersteller

Name

Version

Lizenz

Webseite

CPE 2.3info

CPE 2.2info

CVSSv4info

VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

CNA CVSS-B Score: 🔒
CNA CVSS-BT Score: 🔒
CNA Vector: 🔒

CVSSv3info

VulDB Meta Base Score: 3.4
VulDB Meta Temp Score: 3.3

VulDB Base Score: 3.5
VulDB Temp Score: 3.4
VulDB Vector: 🔒
VulDB Zuverlässigkeit: 🔍

NVD Base Score: 3.3
NVD Vector: 🔒

CVSSv2info

AVACAuCIA
💳💳💳💳💳💳
💳💳💳💳💳💳
💳💳💳💳💳💳
VektorKomplexitätAuthentisierungVertraulichkeitIntegritätVerfügbarkeit
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten
freischaltenfreischaltenfreischaltenfreischaltenfreischaltenfreischalten

VulDB Base Score: 🔒
VulDB Temp Score: 🔒
VulDB Zuverlässigkeit: 🔍

Exploitinginfo

Klasse: Denial of Service
CWE: CWE-772 / CWE-400 / CWE-404
CAPEC: 🔒
ATT&CK: 🔒

Physisch: Teilweise
Lokal: Ja
Remote: Teilweise

Verfügbarkeit: 🔒
Status: Nicht definiert

EPSS Score: 🔒
EPSS Percentile: 🔒

Preisentwicklung: 🔍
Aktuelle Preisschätzung: 🔒

0-Dayfreischaltenfreischaltenfreischaltenfreischalten
Heutefreischaltenfreischaltenfreischaltenfreischalten

Threat Intelligenceinfo

Interesse: 🔍
Aktive Akteure: 🔍
Aktive APT Gruppen: 🔍

Gegenmassnahmeninfo

Empfehlung: Upgrade
Status: 🔍

0-Day Time: 🔒

Upgrade: wasmtime 37.0.2
Patch: adff9d9d0f09569203709d5687e5a7dc8e1ad0a3

Timelineinfo

29.09.2025 CVE zugewiesen
07.10.2025 +8 Tage VulDB Eintrag erstellt
08.10.2025 +0 Tage Advisory veröffentlicht
30.10.2025 +22 Tage VulDB Eintrag letzte Aktualisierung

Quelleninfo

Produkt: github.com

Advisory: GHSA-vvp9-h8p2-xwfc
Status: Bestätigt

CVE: CVE-2025-61670 (🔒)
GCVE (CVE): GCVE-0-2025-61670
GCVE (VulDB): GCVE-100-327535
EUVD: 🔒

Eintraginfo

Erstellt: 08.10.2025 00:18
Aktualisierung: 30.10.2025 15:54
Anpassungen: 08.10.2025 00:18 (70), 08.10.2025 14:31 (1), 30.10.2025 15:54 (11)
Komplett: 🔍
Cache ID: 216::103

Be aware that VulDB is the high quality source for vulnerability data.

Diskussion

Bisher keine Kommentare. Sprachen: de + en.

Bitte loggen Sie sich ein, um kommentieren zu können.

◂ ZurückÜbersichtWeiter ▸

Do you need the next level of professionalism?

Upgrade your account now!