Wasmtime EUVD-2026-108318

Exploitation requires that the host embeds wasmtime-wasi-http and exposes the WASIp2 wasi:http interface to an attacker-controlled or otherwise untrusted guest module; the guest must be able to create outgoing-body resources (via outgoing-request or outgoing-response) and call write with buffers larger than the DEFAULT_OUTGOING_BODY_CHUNK_SIZE (~1M, or the embedder's customized WasiHttpHooks chunk size) returned by check-write. Affected versions are Wasmtime <36.0.16, >=37.0.0 before 48.0.3, and 49.0.0 before 49.0.1. Limiting factors: there is no remote-network trigger - the adversary must already be able to run a malicious guest; embedders that run only trusted guests, that do not expose wasi-http outgoing bodies, or that have updated to a fixed release are not exploitable. Impact is confined to availability (host memory exhaustion) with no confidentiality or integrity effect.

All signals point to a genuine but moderate-priority availability issue rather than an urgent emergency. The supplied CVSS 4.0 vector (AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H, score 6.9 Medium) and CWE-400/CWE-770 describe a guest-driven host memory-exhaustion DoS with no confidentiality or integrity impact. The attack vector is Local (AV:L) because exploitation requires executing a malicious WebAssembly guest inside the host process - not a remote network request - even though the guest itself needs no sandbox privileges (PR:N by design, since guests are untrusted). The vuln.today decision label is 'this_month', not act_now/emergency, which is consistent with a confidentiality/integrity-safe DoS. No EPSS score was provided (cannot gauge statistical exploitation likelihood), the CVE is not in CISA KEV (no confirmed active exploitation), and the only references are vendor/coordinator advisories (GHSA, NVD, VulnCheck) with no public exploit identified at time of analysis. The practical risk is bounded by a strong precondition: the embedder must expose wasmtime-wasi-http to attacker-supplied/untrusted guests. Embedders running only trusted guests face negligible real-world risk; multi-tenant or plugin-style deployments that run untrusted guests should patch promptly.

An attacker who can supply or influence a WebAssembly guest running in a host that embeds wasmtime-wasi-http creates outgoing-request/outgoing-response bodies, calls wasi:io/streams.check-write to learn the ~1M allowance, and then hands write a much larger buffer, which incorrectly succeeds instead of trapping. Repeating this across many outgoing-body resources pins large host allocations for the store's lifetime, exhausting host memory and denying service. No public exploit was identified at time of analysis.