CVE-2026-34988
Memory Leak in Wasmtime Pooling Allocator Causes Data Exposure
Publication date: 2026-04-09
Last updated on: 2026-04-15
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| bytecodealliance | wasmtime | From 37.0.0 (inc) to 42.0.2 (exc) |
| bytecodealliance | wasmtime | From 28.0.0 (inc) to 36.0.7 (exc) |
| bytecodealliance | wasmtime | 43.0.0 |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-119 | The product performs operations on a memory buffer, but it reads from or writes to a memory location outside the buffer's intended boundary. This may result in read or write operations on unexpected memory locations that could be linked to other variables, data structures, or internal program data. |
Attack-Flow Graph
AI Powered Q&A
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability causes data leakage between WebAssembly instances by exposing previous contents of linear memory due to improper resetting of virtual memory permissions. Such data leakage could potentially lead to unauthorized disclosure of sensitive information.
Because the vulnerability allows low-privileged attackers to access stale memory contents, it may impact compliance with data protection regulations like GDPR or HIPAA, which require safeguarding personal and sensitive data against unauthorized access or leaks.
However, the vulnerability only occurs under specific, non-default configurations, and Wasmtime’s default settings are not vulnerable. Organizations using vulnerable configurations should upgrade or apply mitigations to avoid risks that could lead to non-compliance.
Can you explain this vulnerability to me?
CVE-2026-34988 is a low-severity data leakage vulnerability in Wasmtime's pooling allocator implementation. It occurs because the virtual memory permissions for linear memory are not properly reset between reused WebAssembly instances due to a mismatch between runtime and compile-time checks. Specifically, the runtime incorrectly decides that resetting memory permissions is unnecessary, while the compilation process assumes memory protections are reliable. This causes out-of-bounds memory loads, which should cause segmentation faults, to instead succeed and expose the previous contents of linear memory from earlier instances.
The vulnerability requires all of the following conditions to be met simultaneously: the pooling allocator must be enabled; the Config::memory_guard_size option must be set to 0; the Config::memory_reservation must be less than 4 GiB; and the pooling allocator's max_memory_size must equal the memory_reservation value. Under these conditions, reused linear memory retains previous virtual memory permissions, allowing data leakage between WebAssembly instances and breaking Wasmtime's sandbox isolation guarantees.
Wasmtime's default settings and default pooling allocator configurations are not vulnerable, but custom embeddings can trigger this issue. The vulnerability was fixed in Wasmtime versions 36.0.7, 42.0.2, and 43.0.1.
How can this vulnerability impact me? :
This vulnerability can lead to data leakage between different WebAssembly instances running within Wasmtime. Specifically, an attacker could read stale contents of linear memory from a previous instance due to improper resetting of virtual memory permissions.
Because the compiled code expects out-of-bounds memory accesses to cause segmentation faults, the failure to reset permissions means these accesses succeed, exposing potentially sensitive data from prior instances.
The impact is limited to confidentiality (data leakage) and does not affect integrity or availability. The attack requires low privileges, no user interaction, and specific configuration conditions to be met, making exploitation complex but possible in certain custom setups.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability depends on specific configuration settings in Wasmtime's pooling allocator, such as enabling the pooling allocator, setting Config::memory_guard_size to 0, Config::memory_reservation to less than 4 GiB, and matching max_memory_size to memory_reservation. Detection involves verifying these configuration parameters in your Wasmtime environment.
Since the vulnerability is related to Wasmtime's internal memory management and configuration, detection would primarily involve checking the Wasmtime version and configuration rather than network commands.
Suggested commands include checking the Wasmtime version to ensure it is not within the vulnerable ranges (>=28.0.0 to <=36.0.6, >=37.0.0 to <=42.0.1, and version 43.0.0) and inspecting the configuration options related to the pooling allocator.
- Run `wasmtime --version` to determine the installed version.
- Review the embedding or application configuration files or code to verify if the pooling allocator is enabled and if Config::memory_guard_size is set to 0.
- Check if Config::memory_reservation is less than 4 GiB and if max_memory_size equals memory_reservation.
No specific network or system commands are provided in the available resources for direct detection of exploitation attempts.
What immediate steps should I take to mitigate this vulnerability?
The primary mitigation step is to upgrade Wasmtime to a fixed version where this vulnerability is resolved. The patched versions are 36.0.7, 42.0.2, and 43.0.1.
If upgrading immediately is not possible, you can mitigate the vulnerability by changing any of the four configuration conditions that enable the vulnerability:
- Disable the pooling allocator.
- Set Config::memory_guard_size to a non-zero value (enabling guard pages for linear memories).
- Set Config::memory_reservation to 4 GiB or higher.
- Ensure the pooling allocator’s max_memory_size is not equal to the memory_reservation value.
These configuration changes prevent the reuse of linear memory with stale VM permissions, thereby blocking the data leakage.