Wasmtime's pooling allocator may allow the contents of linear memory to leak from one guest instance to the next when certain configuration values diverge between compile time and runtime. The bug arises when the runtime incorrectly determines that virtual-memory permissions need not be reset, allowing previously mapped data to be read by an out-of-bounds load. This enables a guest module to read memory contents that belong to an earlier instance, thus violating WebAssembly's isolation guarantees and leaking confidential data.

Bytecodealliance Wasmtime versions 28.0.0 through 36.0.6, 42.0.0–42.0.1, and 43.0.0 are affected; the flaw is patched in 36.0.7, 42.0.2, and 43.0.1 and any newer releases. The issue does not affect the default configuration, but applications that enable the pooling allocator with Config::memory_guard_size set to 0, Config::memory_reservation below 4 GiB, and max_memory_size equal to memory_reservation may be exposed.

The CVSS score of 2.3 indicates low severity; the EPSS score is not available and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog. Exploitation requires the pooling allocator to be active, Config::memory_guard_size set to 0, Config::memory_reservation under 4 GiB, and max_memory_size equal to memory_reservation. These conditions are not part of the default configuration, so an attacker would need to control the embedding environment or supply specially crafted WebAssembly modules. When the conditions are met, a canary-free out-of-bounds load can read data left behind in linear memory, leading to information disclosure rather than denial-of-service or remote code execution. Because the bug only affects data isolation, the risk to most deployments that use the default settings is minimal, but any custom configuration that uses the pooling allocator with the specific parameter set is vulnerable.