Wasmtime CVE-2026-115387

Exploitation requires the ability to execute an untrusted or malicious guest WASI module inside the host, and that the host has granted the guest filesystem access (e.g. preopened directories) reachable by the time-setting calls. The guest must invoke path_filestat_set_times or fd_filestat_set_times (wasip1), or set-times/set-times-at on wasi:filesystem/types.descriptor (wasip2/wasip3), passing an atim or mtim Timestamp/Datetime whose microseconds field overflows the seconds field. For wasip1 specifically, the relevant fst_flags must NOT set ATIM_NOW/MTIM_NOW, because those flags bypass the supplied atim/mtim argument. Limiting factors: there is no network vector (AV:L) - the attacker must already be running guest code; hosts that execute only trusted first-party wasm modules, or that do not expose WASI filesystem set-times capabilities to guests, are not realistically exposed. The complete fix is upgrading wasmtime-wasi to 36.0.16, 48.0.3, or 49.0.1 as stated by the vendor.

The source assigns CVSS 4.0 base 6.9 (medium) with vector AV:L/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H - a pure availability (denial-of-service) impact with no confidentiality or integrity consequence. The critical signal is AV:L: this is NOT a network-reachable flaw. The 'attacker' is a guest WASI module already executing inside the host process, so real-world risk is bounded entirely by whether a deployment runs untrusted or semi-trusted guest code. No EPSS score, no CISA KEV entry, and no public exploit were provided in the input, and the vuln.today decision label is 'this_month' (moderate), not act_now/emergency - all consistent with a serious-but-not-fire-drill issue. Where it genuinely matters is multi-tenant or plugin-style WASM hosting (serverless/edge, embedded untrusted modules): there a single malicious guest can panic the shared host and take down co-tenants, so for those operators this is a real availability priority. For deployments that execute only trusted, first-party wasm modules, exploitability is largely theoretical. The CWE-190 integer-overflow classification matches the described mechanism (microseconds field overflowing the seconds field, causing Rust's std::time::Duration::new to panic), so the metadata is internally consistent; the main caveat is the absence of EPSS/KEV/POC signals rather than any conflict between them.

On a multi-tenant WebAssembly platform that runs untrusted guest modules with filesystem access, a hostile tenant invokes set-times/set-times-at (wasip2/3) or fd_filestat_set_times/path_filestat_set_times (wasip1) with an atim or mtim whose microseconds field overflows the seconds field (e.g. seconds u64::MAX/i64::MAX, microseconds 1_000_000_000). The resulting Duration::new panic crashes the entire host process, denying service to all co-located guests. No packaged public exploit was identified at time of analysis, though the Bytecode Alliance advisory documents the exact overflowing values needed to trigger it.