Wasmtime CVE-2026-115389

The host application must use Wasmtime's dynamically-typed Val API (wasmtime::component::Val) to lift return values from guest components; hosts built with bindgen! or otherwise statically-typed APIs are explicitly NOT affected. The host must also execute an attacker-controlled/untrusted guest component and depend on the hostcall fuel limit to bound host memory, since the flaw is that host allocations during Val lifting are not counted against that limit (a hole in the earlier GHSA-852m-cvvp-9p4w mitigation). Limiting factors: exposure is confined to Val-API hosts that accept untrusted guests; statically-typed hosts and hosts that only run trusted modules are not at risk. Note the supplied vector lists PR:L, but the genuine prerequisite is the ability to supply a guest module rather than a conventional user account.

This is a denial-of-service issue (CWE-770, missing resource-consumption limit): a guest can bypass Wasmtime's hostcall fuel limit and cause the host to allocate at least ~100x more memory than it is tracking. Signal review: no CISA KEV listing is present, no EPSS score was supplied, and no public exploit code or PoC reference appears in the input (only the vendor GHSA and a VulnCheck advisory), so exploitation status is 'no public exploit identified at time of analysis.' The vuln.today Decision label is 'monitor,' which aligns with a low-urgency, non-emergency posture. The supplied CVSS 4.0 vector scores only 1.0 (AV:A/AC:H/AT:P/PR:L/UI:P/VA:L), which materially underrates triggerability: the advisory describes a deterministic amplification that any guest returning crafted Val values can invoke, which is inconsistent with AC:H, AT:P and UI:P. My independent read is a reliably triggerable, availability-only DoS rather than a 1.0 near-non-issue - but it is gated hard by a usage condition (only hosts using the dynamically-typed Val API are affected). Net: a real but bounded priority for the specific population that runs untrusted guests through the Val API; for everyone else (bindgen!/statically-typed hosts) it is not exploitable. Treat as patch-on-schedule, consistent with the 'monitor' label, not an emergency.

A host (e.g. an edge/plugin platform) embeds Wasmtime, calls untrusted guest component functions through the dynamically-typed Val API, and relies on the hostcall fuel limit to bound host memory. An attacker submits a malicious guest whose exported function returns a crafted value (such as a nested record) that lifts into roughly 100x more host memory than the fuel accounting records, exhausting RAM and taking the host process down. No public exploit code is identified at time of analysis; only vendor advisories exist.