CVE-2026-34941
Bounds Check Bypass in Wasmtime Causes Host Memory Read, DoS
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-125 | The product reads data past the end, or before the beginning, of the intended buffer. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-34941 is a vulnerability in the Wasmtime runtime for WebAssembly that occurs during the transcoding of UTF-16 strings to the latin1+utf16 component-model encoding.
The issue arises because the code incorrectly validates the input string's length by checking the number of UTF-16 code units instead of the actual byte length, which is twice as large. This improper bounds check can cause the host to read beyond the end of a WebAssembly linear memory buffer.
In Wasmtime's default configuration, this out-of-bounds read triggers a segmentation fault, crashing the host process and causing a denial-of-service. In nonstandard configurations without guard pages, it may allow the host to read and interpret memory beyond the intended boundary, potentially leading to information disclosure.
This vulnerability affects users running untrusted WebAssembly components that perform cross-component string passing involving UTF-16 source strings and latin1+utf16 destination encodings.
How can this vulnerability impact me? :
The primary impact of this vulnerability is a denial-of-service (DoS) condition caused by the host process crashing due to a segmentation fault triggered by an out-of-bounds read.
If Wasmtime is configured without guard pages—a nonstandard setup—there is also a risk that the host may read memory beyond the linear memory boundary and interpret it as UTF-16 data, potentially leading to information disclosure.
This means that attackers could cause your application or service using Wasmtime to crash or, in some configurations, potentially leak sensitive information from memory.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability manifests as a host process crash (segmentation fault) when Wasmtime attempts to transcode UTF-16 strings incorrectly, causing an out-of-bounds read. Detection can involve monitoring for unexpected Wasmtime process crashes or segmentation faults (SIGSEGV/SIGBUS) during execution of WebAssembly components that perform UTF-16 to latin1+utf16 transcoding.
Since the vulnerability triggers a denial-of-service via process termination, you can detect it by observing Wasmtime logs or system logs for segfaults related to Wasmtime processes.
There are no specific commands provided in the resources for direct detection or scanning of this vulnerability.
What immediate steps should I take to mitigate this vulnerability?
The only effective mitigation is to update Wasmtime to a fixed version. The vulnerability is resolved in Wasmtime versions 24.0.7, 36.0.7, 42.0.2, and 43.0.1.
There are no known workarounds or alternative mitigations; therefore, upgrading to a patched version is critical.
Additionally, avoid running Wasmtime with nonstandard configurations that disable guard pages, as this increases the risk of information disclosure.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The vulnerability in Wasmtime can cause denial of service through host process crashes and, under nonstandard configurations, potential information disclosure by reading memory beyond intended boundaries.
While the vulnerability may lead to information disclosure in specific configurations, there is no explicit mention in the provided context or resources about direct impacts on compliance with common standards and regulations such as GDPR or HIPAA.
Organizations relying on Wasmtime should consider the risk of potential data exposure or service disruption when evaluating compliance, but no direct compliance implications are detailed.