Wasmtime EUVD-2026-21033

CVSS score of 2.3 with CVSS:4.0 vector indicates low severity, but this understates actual risk within the specific threat model. Attack vector is network (code running in a sandboxed environment can theoretically be reached remotely), but attack complexity is high and privilege level is low-to-moderate (authenticated user interaction required). Confidentiality impact is low (partial disclosure of previous memory contents), with no integrity or availability impact. The critical mitigating factor is that exploitation requires ALL of the following: use of the pooling allocator, explicit non-default configuration of three specific parameters (memory_guard_size=0, memory_reservation<4GiB, max_memory_size=memory_reservation). Wasmtime's default configuration is NOT vulnerable. Real-world risk is situation-dependent: if an embedding intentionally uses these configurations (possibly for performance optimization in a constrained environment), data leakage between untrusted guest instances becomes a genuine sandbox escape concern. However, the requirement for authenticated access and the highly specific configuration combination reduce the overall attack surface. This is a logic/configuration-induced vulnerability rather than a universal flaw; SSVC would classify this as having low automatable impact but potentially high technical impact if the specific conditions exist. Priority should be elevated only if you operate Wasmtime with non-default pooling allocator settings; otherwise, this is a low-priority fix.

An attacker with authenticated access to a Wasmtime runtime configured with non-default pooling allocator settings (memory_guard_size=0, memory_reservation<4GiB, and max_memory_size=memory_reservation) deploys two WebAssembly guest instances sequentially. The first instance writes sensitive data (e.g., cryptographic keys, user input) into its linear memory. When the first instance terminates and the pooling allocator reuses its memory pages for a second untrusted instance, the compiled code in the second instance attempts out-of-bounds reads expecting segmentation faults; instead, due to the unreset virtual memory permissions, these reads succeed and expose the previous instance's data. No public exploit code is available; exploitation requires both the specific configuration and careful timing to trigger memory reuse.