CVE-2026-34944
Out-of-Bounds Read in Wasmtime f64x2.splat Compilation
Publication date: 2026-04-09
Last updated on: 2026-04-20
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| bytecodealliance | wasmtime | to 24.0.7 (exc) |
| bytecodealliance | wasmtime | From 25.0.0 (inc) to 36.0.7 (exc) |
| bytecodealliance | wasmtime | From 37.0.0 (inc) to 42.0.2 (exc) |
| bytecodealliance | wasmtime | From 43.0.0 (inc) to 43.0.1 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-248 | An exception is thrown from a function, but it is not caught. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability in Wasmtime primarily results in a potential denial-of-service (DoS) condition under specific configurations and does not impact confidentiality or integrity of data.
Since there is no confidentiality or integrity impact, the vulnerability does not directly expose sensitive data or violate data protection requirements under standards like GDPR or HIPAA.
However, the availability impact due to possible DoS could affect system reliability and uptime, which may indirectly influence compliance if availability is a critical requirement.
Overall, this vulnerability does not directly compromise compliance with common data protection regulations but should be addressed to maintain system availability and operational security.
Can you explain this vulnerability to me?
CVE-2026-34944 is a moderate severity vulnerability in Wasmtime, a Rust-based WebAssembly runtime using the Cranelift backend on x86-64 platforms with SSE3 disabled.
The issue occurs when Wasmtime compiles the WebAssembly f64x2.splat instruction that operates on a value loaded from memory. Instead of loading the expected 8 bytes (64 bits), it incorrectly loads 16 bytes (128 bits), reading up to 8 bytes beyond the intended memory boundary.
Depending on Wasmtime's configuration, this can cause different behaviors: with guard pages disabled, the extra data loaded is not visible to WebAssembly guests and does not pose a security risk; with guard pages and signals-based traps enabled (default), it causes a caught segmentation fault treated as a safe trap; with guard pages enabled but signals-based traps disabled, it causes an uncaught segmentation fault that crashes the host process.
How can this vulnerability impact me? :
The main impact of this vulnerability is a potential denial-of-service (DoS) attack against the host process running Wasmtime.
If signals-based traps are disabled and guard pages are enabled, a malicious WebAssembly guest can cause an uncaught segmentation fault that terminates the host process.
There is no impact on confidentiality or integrity since out-of-bounds data loaded is not visible to guests, and arbitrary memory read or write is not possible.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability manifests as an uncaught segmentation fault (segfault) on x86-64 platforms with SSE3 disabled when running Wasmtime with signals-based traps disabled and guard pages enabled. Detection involves monitoring for unexpected segfaults or crashes of the Wasmtime host process during execution of WebAssembly code using the Cranelift backend.
Since the issue is specific to Wasmtime's handling of the f64x2.splat WebAssembly instruction, you can detect it by running Wasmtime workloads that use this instruction and observing if the host process crashes unexpectedly.
There are no specific commands provided to detect this vulnerability directly, but general approaches include:
- Check Wasmtime version to see if it is older than 24.0.7, 36.0.7, 42.0.2, or 43.0.1.
- Monitor system logs (e.g., using `dmesg` or `journalctl`) for segfaults related to Wasmtime.
- Run Wasmtime with debugging or verbose logging enabled to capture crashes.
- Use commands like `ps` or `top` to monitor Wasmtime process stability.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation is to upgrade Wasmtime to a fixed version: 24.0.7, 36.0.7, 42.0.2, or 43.0.1.
If upgrading is not immediately possible, ensure that SSE3 is enabled on your x86-64 platform or use a non-x86-64 host, as the vulnerability only affects x86-64 hosts with SSE3 disabled.
Also, avoid disabling signals-based traps when running Wasmtime, as disabling them combined with guard pages enabled leads to uncaught segfaults and potential denial-of-service.
No other known workarounds exist besides these steps.