Wasmtime EUVD-2026-108314

Exploitation requires the WASIp1 API to be enabled AND the guest to have been granted a preopened directory it can enumerate - the vendor states guests running without a filesystem are entirely unaffected, and guests using WASIp2 or later are unaffected. The attacker must be able to run guest code within the Wasmtime host (realistically a multi-tenant or untrusted-guest deployment). Limiting factors: the leaked bytes are uncontrollable (the guest learns only 3 adjacent bytes per entry, not which bytes), the information impact is confidentiality-only with no integrity or availability effect, and the attack requirement flag (AT:P) reflects the dependence on a preopened directory being present. There is no workaround if WASIp1 is enabled with a preopened directory; the vendor states updating is the only fix.

This is a genuinely low-priority issue, and the signals agree rather than conflict. The supplied CVSS 4.0 base score is 2.1 (AV:N/AC:L/AT:P/PR:L/UI:P with only VC:L and no integrity/availability impact), and the vuln.today decision label is 'monitor' - the lowest urgency tier. No EPSS score, no CISA KEV listing, and no SSVC fields were provided; absence of these is expected for a low-severity memory-safety hygiene bug and is not itself a red flag. The technical impact is narrow: each fd_readdir entry leaks exactly 3 bytes of uninitialized host stack or heap memory, and the GHSA advisory explicitly states the guest cannot control which bytes are leaked. That makes this an information-disclosure primitive of low fidelity - a guest could aggregate many directory reads to harvest small, non-targeted fragments of host memory, but it cannot reliably exfiltrate specific secrets such as keys or pointers in one shot. The AT:P (attack requirement, present) in the 4.0 vector indicates a condition outside the attacker's control must hold; the advisory grounds this in the requirement that the guest have a preopened directory to enumerate. The main caveat for defenders is contextual: raw CVSS understates risk only in multi-tenant environments running untrusted WASM guests, where even low-fidelity host-memory leakage can aid sandbox-escape research or ASLR/secret inference. In single-tenant or trusted-guest deployments the real-world risk is negligible. No key data is missing for triage - vendor-confirmed impact, patches, and affected ranges are all present.

In a multi-tenant WASM hosting setup, an attacker supplies a malicious WASIp1 guest module that is granted a preopened directory. The guest repeatedly calls fd_readdir and reads the 3 bytes of uninitialized struct padding appended to each returned directory entry, accumulating small fragments of host stack or heap memory over many entries. No public exploit code is identified at time of analysis, and the leaked bytes are uncontrollable, so this is a low-fidelity harvesting primitive rather than targeted secret theft.