CVE-2026-34988: Bytecode Alliance Wasmtime data leakage in pooling allocator

CVE-2026-34988 · Severity: medium · CVSS 6.3 · Published 2026-04-09

Wasmtime is a runtime for executing WebAssembly code in a secure, isolated environment. A bug in its memory management system can allow one guest program to access the private memory of a previously running program under specific configurations. This could lead to sensitive data leakage between different users or applications sharing the same infrastructure.

Technologies: Bytecodealliance Wasmtime, wasmtime (crates.io). Vendors: Bytecodealliance, crates.io.

Quick answers

Is CVE-2026-34988 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-34988 being exploited in the wild.
How severe is CVE-2026-34988?
Medium severity, with a CVSS score of 6.3, published 9 April 2026.
Which products and versions are affected?
wasmtime (crates.io) SEMVER:introduced=0.0.0-0,fixed=36.0.7,introduced=37.0.0,fixed=42.0.2,introduced=43.0.0,fixed=43.0.1, SEMVER:introduced=28.0.0,fixed=36.0.7.
Is there a fix for CVE-2026-34988?
Yes. wasmtime (crates.io): upgrade to 36.0.7, 43.0.1 or later. Junglewise finds every place you run it, drafts the upgrade and applies it once you approve.
How is CVE-2026-34988 attacked?
It is attacked over the network, in a software library.
Am I affected by CVE-2026-34988?
Check whether you run Bytecodealliance Wasmtime or wasmtime (crates.io) at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

  • wasmtime (crates.io): upgrade to 36.0.7, 43.0.1 or later
    cargo update -p wasmtime

Technical details

A logic error in Wasmtime's pooling allocator causes a divergence between runtime memory resetting and compile-time assumptions. Specifically, the allocator may use an incorrect predicate to determine if virtual memory permissions need to be reset when a linear memory slot is reused. If the pooling allocator is active, memory guard size is 0, and memory reservation is less than 4GiB (matching max_memory_size), the system fails to trigger a segfault on out-of-bounds loads. This allows a subsequent WebAssembly instance to read the memory remains of a previous instance. The issue is fixed in versions 36.0.7, 42.0.2, and 43.0.1.

Affected products

  • Bytecode Alliance Wasmtime >= 28.0.0, < 36.0.7; >= 37.0.0, < 42.0.2; 43.0.0

Identifiers

  • CVE-2026-34988
  • GHSA-6wgr-89rj-399p
  • RUSTSEC-2026-0088

Timeline

  • 2026-04-09: disclosed
  • 2026-04-09: advisory
  • 2026-04-09: patched

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.