CVE-2026-34988

Workarounds

All four conditions above must be met to be vulnerable to this bug, and users can work around this bug by adjusting any of the above conditions. For example it is strongly recommended that guard pages are configured for linear memories which would make this bug not applicable.

Wasmtime's implementation of its pooling allocator contains a bug where in certain configurations the contents of linear memory can be leaked from one instance to the next. The implementation of resetting the virtual memory permissions for linear memory used the wrong predicate to determine if resetting was necessary, where the compilation process used a different predicate. This divergence meant that the pooling allocator incorrectly deduced at runtime that resetting virtual memory permissions was not necessary while compile-time determine that virtual memory could be relied upon.

Exposing this bug requires specific configuration values to be used. If any of these configurations are not applicable then this bug does not happen:

• The pooling allocator must be in use.
• The Config::memory_guard_size configuration option must be 0.
• The Config::memory_reservation configuration must be less than 4GiB.
• The pooling allocator must be configured with max_memory_size the same as the memory_reservation value.

If all of these conditions are applicable then when a linear memory is reused the VM permissions of the previous iteration are not reset. This means that the compiled code, which is assuming out-of-bounds loads will segfault, will not actually segfault and can read the previous contents of linear memory if it was previously mapped.

This represents a data leakage vulnerability between guest WebAssembly instances which breaks WebAssembly's semantics and additionally breaks the sandbox that Wasmtime provides. Wasmtime is not vulnerable to this issue with its default settings, nor with the default settings of the pooling allocator, but embeddings are still allowed to configure these values to cause this vulnerability.

Kodem intelligence

Wasmtime 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update to these patched versions of Wasmtime.

1. What is CVE-2026-34988? CVE-2026-34988 is a low-severity security vulnerability in wasmtime (rust), affecting versions >= 28.0.0, < 36.0.7. It is fixed in 36.0.7, 42.0.2, 43.0.1.
2. Which versions of wasmtime are affected by CVE-2026-34988? wasmtime (rust) versions >= 28.0.0, < 36.0.7 is affected.
3. Is there a fix for CVE-2026-34988? Yes. CVE-2026-34988 is fixed in 36.0.7, 42.0.2, 43.0.1. Upgrade to this version or later.
4. Is CVE-2026-34988 exploitable, and should I be worried? Whether CVE-2026-34988 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
5. What actually determines whether CVE-2026-34988 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
6. How do I fix CVE-2026-34988?
   • Upgrade wasmtime to 36.0.7 or later
   • Upgrade wasmtime to 42.0.2 or later
   • Upgrade wasmtime to 43.0.1 or later