Wasmtime EUVD-2026-108321

Exploitation requires ALL of the following, per the vendor advisory: (1) fuel metering must be explicitly enabled via Config::consume_fuel or -W fuel=N - this is OFF by default; (2) the Cranelift backend must be in use - this is the default unless Winch is configured, and it also covers Pulley interpreter users; (3) the guest must contain the call_ref opcode (function-references proposal) or the try_table opcode (exception-handling proposal), both supported by default since Wasmtime 47.0.0; and (4) the attacker must be able to supply or run a crafted guest module. LIMITING FACTORS: because fuel is disabled by default, the vast majority of deployments are not exposed; embedders using epoch interruption (Config::epoch_interruption) instead of fuel are unaffected by this bug, though epoch interruption is not deterministic. Affected only in version ranges >= 47.0.0 < 48.0.3 and 49.0.0 < 49.0.1.

This is a medium-severity denial-of-service issue (vendor CVSS 4.0 base 6.9; CWE-400 uncontrolled resource consumption) whose real-world risk is gated hard by configuration rather than by raw reachability. The 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:P) shows availability as the only impact (VC:N/VI:N/VA:H) with no confidentiality or integrity effect and no scope change to other systems - consistent with a timeout/yield-evasion DoS, not code execution or escape. The vuln.today priority is 'this_month' (not act_now/emergency). There is no CISA KEV listing and no EPSS score in the provided data, so widespread automated exploitation cannot be inferred; absence of these signals is not evidence of safety but does not elevate urgency. No exploit or PoC reference is present in the input - only the GHSA and VulnCheck advisories - so this is 'no public exploit identified at time of analysis.' The dominant risk driver is the precondition: fuel metering (Config::consume_fuel / -W fuel=N) must be explicitly enabled, which is OFF by default, and the guest must contain call_ref or try_table opcodes. For embedders that rely on fuel as their only deterministic timeout/yield mechanism against untrusted guests, this is a genuine priority because it defeats the exact control they depend on; for the majority who leave fuel disabled or use epoch interruption, real exposure is low. The vendor-assigned PR:L (an attacker able to supply/run a guest module) is appropriate for a WebAssembly runtime threat model where guests are inherently untrusted.

An embedder runs untrusted WebAssembly guests under Wasmtime's Cranelift backend and relies on fuel metering (Config::consume_fuel) to bound execution time. A malicious guest containing call_ref or try_table opcodes structures recursive/exceptional call paths so that fuel consumed inside callees is dropped and reset to the pre-call remaining fuel, achieving exponential runtime on linear fuel and evading the fuel-based timeout, thereby hanging or starving the host. No public exploit code is identified in the provided sources, though the mechanism is described in detail in the GHSA advisory.