Wasmtime EUVD-2026-108304

Exploitation requires that WASI preview 0 be enabled AND that the host run a guest module the attacker controls. The wasmtime CLI is affected by default because WASI preview 0 is enabled by default; library embeddings are affected ONLY if they explicitly call p0::add_to_linker_async or p0::add_to_linker_sync. The guest must invoke the poll_oneoff API with many subscriptions to force the O(n) host work. Limiting factors that reduce real-world risk: WASIp1, WASIp2, and WASIp3 are unaffected (they consume fuel correctly or do not expose the API), the issue is meaningful only when running untrusted guest code under a fuel limit, and the vendor provides a workaround of disabling preview 0 in the CLI via '-Spreview0=n' in addition to the fixed releases 36.0.17, 48.0.4, and 49.0.2.

This is a medium-severity denial-of-service issue (CVSS 4.0 base 5.1), and the signals are internally consistent rather than conflicting. The 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:N) with only availability impact (VA:L, VC:N/VI:N) matches the mechanism described: a guest WebAssembly module forces the host to do O(n) work per subscription in the WASI preview 0 poll_oneoff adapter without consuming or checking fuel, defeating a configured fuel limit. AV:L is appropriate because the adversary is a guest module executing locally within the Wasmtime host, not a network peer. There is no CISA KEV listing and no EPSS score in the supplied data, and no public exploit code is identified - the two references are the Bytecode Alliance GHSA advisory and a VulnCheck advisory, not working exploit code. The vuln.today priority is 'this_month,' which aligns with a patch-available, non-emergency DoS rather than an urgent remote code execution. Real-world priority is bounded by the deployment condition: it only matters where untrusted guest code is run with WASI preview 0 enabled (the default for the wasmtime CLI; library embeddings are unaffected unless they explicitly enable p0). For operators running only trusted modules, or using WASIp1/p2/p3, real risk is minimal despite the 'high'-looking fuel-bypass framing.

An operator runs untrusted or semi-trusted WebAssembly modules under the wasmtime CLI (where WASI preview 0 is enabled by default) and relies on a fuel limit to bound guest execution time. A malicious guest invokes poll_oneoff with a very large number of subscriptions; the preview 0 adapter mutates and processes each one in the host doing O(n) work while never consuming or checking fuel, so the guest runs a long host computation that ignores the configured fuel cap and degrades or stalls service. No public exploit code is identified at time of analysis.