CVE-2026-115386

Wasmtime before 24.0.12, 25.0.0 before 36.0.13, 37.0.0 before 46.0.2, and 47.0.0 before 47.0.3 contains a type confusion vulnerability because several Store APIs fail to validate that objects belong to the Store's Engine. Embedders mixing objects between Engines via Instance::new, StructRefPre::new, or Tag::new can trigger trampoline signature mismatches causing out-of-bounds stack writes, GC heap corruption, or panics.

Wasmtime before 24.0.13, 25.0.0 before 36.0.14, 37.0.0 before 46.0.3, and 47.0.0 before 47.0.4 allows a filesystem sandbox escape in wasmtime-wasi because its cap-std dependency mishandles symlinks with trailing slashes on macOS and Linux kernels lacking openat2. A guest with write access to any sandboxed directory can read and write any host-accessible file, and read-only guests may read host files via preexisting symlinks.

Wasmtime 46.0.0 before 46.0.3 and 47.0.0 before 47.0.4 contains an uncontrolled resource allocation vulnerability in its WASIp3 implementation that buffers guest-specified-length writes on the host without limit. Malicious guests can offer large buffers to WASIp3 file or HTTP write streams, causing the host to copy and buffer all bytes, bounded only by guest linear memory, exhausting host memory.

Wasmtime 47.0.0 before 48.0.3 and 49.0.0 before 49.0.1 contains a fuel accounting flaw in Cranelift-compiled call_ref and try_table catch paths. Malicious guests can reset consumed fuel after calls to run exponentially long on linear fuel, evading timeouts and periodic yields for denial of service.

Wasmtime before 36.0.16, 37.0.0 before 48.0.3, and 49.0.0 before 49.0.1 does not adequately account for host allocations when lifting guest values through the dynamically-typed Val API, bypassing the hostcall fuel limit. A malicious WebAssembly guest can return crafted values that allocate at least ~100x more host memory than tracked, causing denial of service.

wasmtime-wasi-http in Wasmtime does not enforce the wasi:io/streams check-write allowance for WASIp2 outgoing HTTP bodies, so oversized writes succeed instead of trapping. A malicious guest can pass large buffers to write on outgoing-body resources, holding host allocations for the store's lifetime and exhausting host memory.

Wasmtime contains a denial of service vulnerability in wasmtime-wasi that allows guest WASI programs to panic the host via overflowing filesystem timestamps. Attackers can pass atim or mtim values whose sub-second field overflows the seconds field to path_filestat_set_times, fd_filestat_set_times, set-times, or set-times-at, crashing the host.

Wasmtime contains a denial of service vulnerability in the wasmtime-wasi WASIp3 implementation that allows guests to abort the Unix host process. Guests with mutable preopened directory access can call set-times or set-times-at with negative seconds timestamps before the epoch, triggering an assertion failure that crashes the host.

Wasmtime contains an improper validation vulnerability that accepts components whose core modules import WebAssembly tags with a subtype of the original type. Malicious guests can mis-type exception object payloads to corrupt the GC heap, causing Wasmtime to panic when the exceptions proposal is enabled.

Wasmtime contains a denial-of-service vulnerability in its wasi:http implementation that allows guests to panic the host. Guests can specify a zero between-bytes-timeout request option, which is forwarded directly to a Tokio API that panics, crashing the host embedding.