Wasmtime EUVD-2026-108308

The embedder must use Wasmtime's wasi:http implementation (the wasmtime-wasi-http crate) with the default-send-request Cargo feature enabled - this is on by default - and must expose those wasi:http APIs to the guest; an attacker-controlled guest then sets the between-bytes-timeout request option to zero on an outgoing request. Limiting factors: embeddings that do not provide wasi:http to guests are entirely unaffected; only Wasmtime versions >= 46.0.0 < 48.0.4 and >= 49.0.0 < 49.0.2 are vulnerable; and the attacker must be able to run guest code (or supply a request that reaches this code path), so the practical risk is tied to whether untrusted guests are permitted. Impact is limited to a host panic (availability), with no confidentiality or integrity effect.

This is a genuine but bounded issue: a availability-only denial-of-service in which an untrusted WebAssembly guest can panic and crash the host embedding. The assigned CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:P, score 5.9, Medium) tells a consistent story with the advisory - only VA:H (host availability) is set, with no confidentiality or integrity impact, which matches a 'guest crashes host' panic. No EPSS score, KEV listing, or PoC/exploit reference is present in the supplied data, so there is no signal of active or widespread exploitation; the vuln.today decision label is 'this_month' (not act_now/emergency), consistent with a medium-severity DoS rather than a top priority. The trigger is trivially simple (pass a zero duration), so weaponization is low-effort, but the blast radius is limited to availability of the embedding process. The real risk concentrates in multi-tenant or untrusted-guest deployments of wasmtime-wasi-http (e.g. edge/serverless Wasm hosting) where a hostile guest can repeatedly crash the host; for single-tenant or trusted-guest embeddings the practical risk is low. No data is strongly conflicting; the main caveat is that PR:L and AT:P reflect Wasmtime's guest-as-attacker threat model, so the severity hinges on whether untrusted guests are actually exposed to wasi:http.

In a Wasmtime host that exposes wasi:http to untrusted guests (default-send-request feature, enabled by default), a hostile guest module issues an outbound HTTP request with the between-bytes-timeout option set to zero. Wasmtime forwards that zero duration directly to a Tokio API documented to panic on a zero duration, crashing the host embedding and denying service. No public exploit code was identified, but the condition is trivial to reproduce from guest code.