CVE-2025-64345: Wasmtime Vulnerability in Shared Linear Memory API Leading to Data Races
Summary
CVE-2025-64345: Wasmtime provides unsound API access to a WebAssembly shared linear memory. Affects wasmtime across 4 version ranges.
< 24.0.5
>= 26.0.0, < 36.0.3
>= 37.0.0, < 37.0.3
>= 38.0.0, < 38.0.4
Fixed in 4 releases; the minimum fixed version depends on the release line you run. How to fix ↓
Check if this vulnerability affects your application
Upload a manifest or SBOM and we'll show whether you're affected, plus every other risky package in the same scan.
No signup required · Results in about 60 seconds
Background
Wasmtime is a popular runtime for executing WebAssembly (Wasm) modules, designed to provide a safe and efficient environment for running Wasm code. It offers a Rust embedder API that allows developers to integrate Wasm into their applications seamlessly. The package supports both standard and shared linear memory, enabling concurrent access across threads. However, a recent vulnerability has been identified that compromises the soundness of its API when handling shared linear memory.
Vulnerability Detail
The vulnerability arises from an unsound interaction within Wasmtime's Rust embedder API, where a WebAssembly shared linear memory is incorrectly treated as a type that allows safe access to its contents. This can lead to data races in the host application, particularly when multiple threads attempt to modify the shared memory concurrently. Specifically, the 'wasmtime::Memory' type allows unsafe access patterns that are not suitable for shared memories, which should instead utilize 'wasmtime::SharedMemory'. The issue is exacerbated by the fact that core dumps can expose shared linear memories as 'wasmtime::Memory', leading to unsynchronized reads and potential data races.
How To Fix
Latest published version: 50.0.0 as of 22 Oct 2026
Upgrading to it may include breaking changes; the versions below are the minimum fixed release for this vulnerability.
If you can't move to the latest
The minimum fixed version depends on the release line you run.
-
< 24.0.524.0.5 -
>= 26.0.0, < 36.0.336.0.3 -
>= 37.0.0, < 37.0.337.0.3 -
>= 38.0.0, < 38.0.438.0.4
Tip — Not sure which release line you're on? Vulert can find the fix for the version you are using. Scan free →
Workaround
If immediate upgrading is not feasible, affected embeddings should use 'SharedMemory::new' instead of 'Memory::new' to create shared memories. Additionally, disabling core dumps can mitigate the risk of unsynchronized reads. Core dumps are disabled by default, but if the wasm threads proposal is enabled, users should ensure that shared memory is not inadvertently exposed.
Conclusion
The vulnerability identified as CVE-2025-64345 in Wasmtime poses significant risks related to shared linear memory access, potentially leading to data races in applications. It is crucial for developers to update to the patched versions or implement workarounds to ensure the safety and reliability of their applications.
See every vulnerability recorded for wasmtime →
FAQ
The vulnerability involves an unsound API access to shared linear memory, which can lead to data races when multiple threads modify the memory concurrently.
You can use Vulert, which monitors and alerts for open-source vulnerabilities in real-time. Visit Vulert Scanner to check your application's Cargo.lock for vulnerabilities without needing to sign up.
Failing to address this vulnerability may result in data races, leading to unpredictable behavior, crashes, or data corruption in applications using Wasmtime.
Yes, versions 24.0.5, 36.0.3, 37.0.3, and 38.0.4 have been patched to fix this vulnerability. It is recommended to upgrade to one of these versions.
As a temporary measure, use 'SharedMemory::new' for creating shared memories and consider disabling core dumps to avoid unsynchronized reads.
References
Related vulnerabilities
Recent vulnerabilities recorded for wasmtime.
