Wasmtime is a runtime for WebAssembly. Prior to 36.0.19, 48.0.7, and 49.0.4, the Cranelift compiler backend on aarch64 can compile a Wasm br_table instruction with more than approximately 256,000 targets so that it has an incorrect conditional branch target. The branch can then jump to arbitrary other code at a user-controlled offset, allowing a user-controlled Wasm module to escape the sandbox on aarch64 engines using the default Cranelift backend. This issue is fixed in versions 36.0.19, 48.0.7, and 49.0.4.
Wasmtime is a runtime for WebAssembly. From 46.0.0 until 48.0.7 and 49.0.4, lowering a host-created component-model stream or future into a guest can omit a required payload-type check after the value passes through guest code and returns through StreamAny, FutureAny, Val::Stream, Val::Future, or an equivalent typed reader. A malicious guest that controls exported function types or returned values can cause the host to pass the type-erased value to a guest expecting a different payload type, which panics the Wasmtime host. This issue is fixed in versions 48.0.7 and 49.0.4.
Wasmtime is a runtime for WebAssembly. Prior to 36.0.19 and 43.0.0, the Cranelift compiler backend bit-packs SSA value indices in a way that can silently overflow in release builds when compiling a sufficiently large or specially crafted Wasm function with many SSA values. The overflow can make Cranelift reference incorrect IR values, causing arbitrary miscompilation, type confusion, and other attacker-controlled effects that may escape the Wasm sandbox on any architecture using the default Cranelift backend. This issue is fixed in versions 36.0.19 and 43.0.0.
CVE-2026-115387 is a denial of service vulnerability in the bytecodealliance wasmtime-wasi component. It allows guest WASI programs to cause the host to panic by passing filesystem timestamp values with overflowing sub-second fields, resulting in a crash. Multiple version ranges of wasmtime are affected, with fixes available in versions 36.0.16, 48.0.3, and 49.0.1.
CVE-2026-115382 is a denial-of-service vulnerability in the wasi:http implementation of wasmtime versions 46.0.0 before 48.0.4 and 49.0.0 before 49.0.2. It allows a guest to cause the host to panic and crash by specifying a zero between-bytes-timeout request option, which is passed directly to a Tokio API that triggers the panic.
CVE-2026-115381 is a medium severity vulnerability in the bytecodealliance wasmtime project affecting versions before 36.0.17, between 37.0.0 and 48.0.4, and between 49.0.0 and 49.0.2. It involves unbounded memory allocation in the wasmtime-wasi WASIp2 write-zeroes method of SinkOutputStream, which is used by default when stdout/stderr are not configured. A malicious WebAssembly guest can exploit this to request large zero-filled writes, exhausting host memory and causing a denial of service.
CVE-2026-115379 is a use-after-free vulnerability in bytecodealliance's wasmtime affecting versions 47.0.0 before 48.0.4 and 49.0.0 before 49.0.2. The vulnerability arises from missing garbage collection rooting that leaves references unrooted across try_call when compiling WebAssembly modules. This flaw can lead to garbage collection heap corruption or incorrect execution when attackers supply specially crafted Wasm modules. The issue has been fixed in versions 48.0.4 and 49.0.2.
Wasmtime, a WebAssembly runtime, contains a vulnerability in its handling of bulk-data-transfer instructions like memory.copy when combined with preemption via epochs or fuel and store state mutations or computation cancellations. This can lead to exposure of intermediate internal states, causing semantic inconsistencies and potential segfaults. The issue affects embedders using Store::epoch_deadline_callback and performing store mutations or resuming computations after cancellation. Wasmtime versions 46.0.0 up to but not including 46.0.2 and 47.0.0 up to but not including 47.0.3 are affected. The vulnerability is fixed in versions 46.0.2 and 47.0.3 by reverting to a behavior that avoids preemption points during these operations.
Wasmtime is a runtime for WebAssembly. Prior to 24.0.11, 36.0.12, 45.0.3, and 46.0.1, wasmtime-wasi hard-link creation and renaming check directory permissions but not matching FilePerms on source and destination preopens, allowing a WASI guest with a read-only source file capability to overwrite host files exposed as FilePerms::READ through wasip1, wasip2, or wasip3 filesystem interfaces. This issue is fixed in versions 24.0.11, 36.0.12, 45.0.3, and 46.0.1.
Wasmtime is a runtime for WebAssembly. All versions prior to 24.0.10; versions 25.0.0 through those before 36.0.11; versions 37.0.0 through those before 44.0.3; and versions 45.0.0 and 45.0.1 contain a native implementation of WASIp1 which suffers from a leak in the fd_renumber function where the file descriptor being renumbered to is not properly closed. Wasmtime's implementation erroneously only updated the table of descriptors for WASIp1 and didn't update the underlying table of descriptors used by the host. This behavior means that while fd_renumber works correctly from a guest's perspective it ends up leaking resources in the host that aren't cleaned up until the corresponding Store is destroyed. In a loop, guests can use fd_renumber to cause hosts to exhaust both resources and file descriptors. This bug only affects the native implementation of WASIp1, meaning that only runtimes which load core wasm modules and expose fd_renumber are affected. Runtimes are additionally only affected if they expose the ability to acquire a file descriptor, such as opening a file. For runtimes that deny access to files they are unaffected. This issue has been fixed in versions 24.0.10, 36.0.11, 44.0.3, and 45.0.2.
Wasmtime is a runtime for WebAssembly. From 25.0.0 to before 36.0.7, 42.0.2, and 43.0.1, Wasmtime's Winch compiler backend contains a bug where translating the table.grow operator causes the result to be incorrectly typed. For 32-bit tables this means that the result of the operator, internally in Winch, is tagged as a 64-bit value instead of a 32-bit value. This invalid internal representation of Winch's compiler state compounds into further issues depending on how the value is consumed. The primary consequence of this bug is that bytes in the host's address space can be stored/read from. This is only applicable to the 16 bytes before linear memory, however, as the only significant return value of table.grow that can be misinterpreted is -1. The bytes before linear memory are, by default, unmapped memory. Wasmtime will detect this fault and abort the process, however, because wasm should not be able to access these bytes. Overall this this bug in Winch represents a DoS vector by crashing the host process, a correctness issue within Winch, and a possible leak of up to 16-bytes before linear memory. Wasmtime's default compiler is Cranelift, not Winch, and Wasmtime's default settings are to place guard pages before linear memory. This means that Wasmtime's default configuration is not affected by this issue, and when explicitly choosing Winch Wasmtime's otherwise default configuration leads to a DoS. Disabling guard pages before linear memory is required to possibly leak up to 16-bytes of host data. This vulnerability is fixed in 36.0.7, 42.0.2, and 43.0.1.