Wasmtime CVE-2025-62711

Exploitation requires all of the following narrow conditions, which sharply limit real-world risk: (1) the host runs Wasmtime 38.0.0, 38.0.1, or 38.0.2 (the Rust 'wasmtime' crate); (2) a deliberately hand-crafted component that directly lifts a component-model intrinsic (e.g. resource.rep) so that the host-to-wasm trampoline for a component intrinsic is actually used - something no conventional toolchain produces; (3) the host embedder invokes that intrinsic with exactly the right type signatures (many pre-built embeddings never use these signatures and therefore cannot run the component at all); and (4) a trap/error must occur during wasm execution so the code path reads the un-updated runtime data. The combination of carefully crafted component plus a specific cooperating embedder plus a required trap is the main limiting factor; there is no authentication or privilege the attacker gains, and impact is confined to crashing the host process.

All signals converge on this being a genuinely low-priority issue rather than a high-CVSS-but-low-real-risk mismatch. The vendor/NVD CVSS 4.0 base score is only 2.1 (AV:N/AC:H/AT:P/PR:L/UI:P) with impact limited to availability (VA:L/SA:L) and no confidentiality or integrity effect, consistent with CWE-755 and a pure denial-of-service crash. EPSS is 0.43% (35th percentile), the CVE is NOT in CISA KEV, and there is no public exploit identified - so exploitation status is 'no public exploit identified at time of analysis.' The GHSA advisory itself stresses that triggering the bug requires (a) a carefully crafted component no normal toolchain would emit, (b) a specific host embedder invoking component-model intrinsics with exactly the right type signatures, and (c) a trap occurring during execution - a very narrow combination that matches the high attack complexity (AC:H) and attack requirement (AT:P). CONFLICT TO NOTE: I assess the availability impact higher than the vendor - a deterministic segfault crashes the entire host process (a hard crash, not graceful degradation), which I treat as A:H/VA:H rather than Low; however, the extreme preconditions keep real-world risk low regardless of the impact metric. This is a correctness/sandbox-integrity fix (Wasmtime's safety goal is that safe Rust cannot crash the runtime) more than an actively dangerous vulnerability. Remediation is simple: upgrade to 38.0.3; there are no workarounds.

A service embedding Wasmtime 38.0.0-38.0.2 that loads untrusted WebAssembly components and invokes component-model intrinsics with specific type signatures could be fed a maliciously crafted component; when a trap occurs during its execution, an un-updated host-to-wasm trampoline leaves trap-handling runtime data uninitialized (e.g. a jump target left at 0), causing execution to jump to the null address and deterministically segfault, crashing the whole host process. No public exploit code exists, and the required component and embedder type signatures are highly specific, so this is a theoretical DoS rather than an opportunistic one.