Wasmtime EUVD-2026-108306

Exploitation requires that the Wasmtime embedding does NOT configure stdout/stderr streams, which leaves the default SinkOutputStream in place - this is the exact precondition stated by the vendor. The attacker must be able to run a malicious WebAssembly guest in the host, which then calls the WASIp2 write-zeroes method requesting a very large zero-filled write. What LIMITS exploitation: embeddings that explicitly configure stdout/stderr are not affected because configured streams enforce their own check-write limits that cap the allocation; only the unconfigured-stdio case is vulnerable. Impact is limited to availability (host memory exhaustion / DoS) with no confidentiality or integrity effect. The related GHSA-852m-cvvp-9p4w fix was incomplete specifically for SinkOutputStream, which previously had no size limit.

This is a CWE-770 unbounded memory allocation leading to host denial of service in the Wasmtime WebAssembly runtime, and the signals consistently point to a moderate, conditional risk rather than an urgent emergency. The vendor CVSS 4.0 score is 5.9 (medium), with VA:H as the only impact (no confidentiality or integrity effect) and AT:P signaling that a specific attack requirement must hold - namely that the embedding does not configure stdout/stderr, so the default SinkOutputStream is in use. The vuln.today decision label is 'this_month' (not act_now/emergency), aligning with the medium severity. There is no CISA KEV listing and no EPSS score was supplied, and no public exploit is identified in the input, so there is no evidence of active or widespread exploitation. The references include the Bytecode Alliance GHSA advisory and a VulnCheck advisory but neither is presented as working exploit code. The key limiting factor is confirmed by the vendor: the bug only affects embeddings that do not configure stdout/stderr streams; configured streams carry their own check-write limits that prevent the oversized allocation. Net assessment: a real but bounded availability issue most relevant to Wasmtime embedders running untrusted guests with default/unconfigured stdio, worth patching on a normal monthly cadence rather than treating as a drop-everything priority.

An application embeds Wasmtime and runs untrusted WebAssembly guests without configuring stdout/stderr, so the default SinkOutputStream is used. A malicious guest invokes the WASIp2 write-zeroes method requesting a huge zero-filled write; the host allocates an unbounded buffer, exhausting memory and crashing or hanging the host process. No public exploit code is identified at time of analysis.