Wasmtime CVE-2026-115393

Exploitation requires the embedder's own host code (not guest WebAssembly) to instantiate two or more Wasmtime Engines and then hand an object created by one Engine to a Store backed by a different Engine through one of the affected APIs: Instance::new / Instance::new_async / InstancePre::instantiate(_async) and Store::debug_register_module / Store::debug_register_component / BreakpointEdit::add_breakpoint / remove_breakpoint (trampoline mismatch and potential out-of-bounds write), StructRefPre::new / ArrayRefPre::new / ExnRefPre::new (GC heap corruption sandboxed within the GC heap), or Tag::new (type confusion and/or panic). Strict limiting factors confirmed by the advisory: untrusted guest Wasm programs CANNOT trigger this; the wasmtime CLI is not affected; embedders using a single Engine for the process lifetime are not affected; and embedders that never call an affected method are not affected. In practice the vulnerable condition is a cross-engine object-mixing bug in the embedder's Rust code, which is why the CVSS vector is AV:L with PR:H and AC:H.

All signals converge on low real-world risk despite the alarming CWE pairing (CWE-787 out-of-bounds write and CWE-843 type confusion). The input CVSS 4.0 base score is 1.0 with a vector (AV:L/AC:H/AT:P/PR:H/UI:P) indicating local vector, high attack complexity, a present attack requirement, high privileges, and passive user interaction, with only Low impact to confidentiality, integrity, and availability and no subsequent-system impact - a profile that matches the 'monitor' decision label. No EPSS score, KEV listing, or public exploit is present in the input. The decisive mitigating fact, confirmed by the Bytecode Alliance GHSA-hgjw-h833-99q9 advisory, is that this bug is NOT triggerable by guest WebAssembly programs and the wasmtime CLI is unaffected; it requires the embedder's own host (Rust) code to create two or more Engines and erroneously mix objects between them via specific APIs. This is therefore a high-CWE-class but low-real-risk issue contingent on an embedder programming error, not a remotely reachable flaw. No signals conflict: the CVSS score, the 'monitor' label, the absence of KEV/EPSS/PoC, and the advisory's stated preconditions all agree this is a defensive-upgrade item rather than an active-exploitation priority.

An application that embeds Wasmtime (before 24.0.12 / 36.0.13 / 46.0.2 / 47.0.3) creates two Engines and, through a host-code logic error, instantiates a Module belonging to Engine B into a Store built on Engine A via Instance::new, or passes a cross-engine type into StructRefPre::new or Tag::new. Because the engine ownership was not validated before the Module's code was registered, Wasmtime uses a trampoline compiled for one signature with a function of a different signature, and the host writes return values past the end of the stack allocation, corrupting memory. No public exploit code is identified in the available sources, and the flaw cannot be triggered by untrusted guest Wasm - only by the embedder's own misuse.