Wasmtime vulnerabilities

Wasmtime prior to 36.0.19, 48.0.7, and 49.0.4 has a flaw in the Cranelift compiler on aarch64. A br_table instruction with more than ~256,000 targets can be miscompiled, allowing a jump to arbitrary code and sandbox escape.

Wasmtime prior to 36.0.19 and 43.0.0 has a flaw in the Cranelift compiler where SSA value indices can silently overflow when compiling large Wasm functions. This can cause miscompilation, type confusion, and sandbox escape.

Wasmtime 39.0.0 before 48.0.4 and 49.0.0 before 49.0.2 contains a stack buffer overflow that allows malicious guests to write ~16KB to the native stack via unvalidated async callback result types. Attackers can supply components with mistyped component-model-async callback functions to overwrite return addresses, crashing the host or escaping the sandbox.

A vulnerability in the Wasmtime WebAssembly runtime affects its Winch (baseline) non-default compiler backend. It may allow properly constructed guest Wasm to access host memory outside of its linear-memory sandbox. Exploitation requires the Winch compiler (-Ccompiler=winch); the default Cranelift backend is not affected.

Wasmtime 46.0.0 before 48.0.6 and 49.0.0 before 49.0.3 contains a denial of service vulnerability that allows guest code to trigger a host panic through out-of-bounds zero-length stream operations. Malicious guests can perform zero-length component model stream reads or writes with unvalidated addresses, causing Direct{Source,Destination}::remaining to panic and crash WASIp3 embedders.

Wasmtime 46.0.0 before 48.0.6 and 49.0.0 before 49.0.3 contains a denial of service vulnerability where dropping the Future returned by TypedFunc::call_async can panic the host. When the guest task has not started, cleanup code searches only one location for work items and unwraps the resulting error, crashing embedders that cancel pending calls.

Wasmtime 46.0.0 before 48.0.6 and 49.0.0 before 49.0.3 contains a denial of service vulnerability that allows malicious Wasm modules to panic the host because the may_leave flag is not cleared during realloc. Attackers can call into the host from realloc while lowering stream or future results, such as cancelling the active read or re-waiting a waitable-set, crashing the host.

Wasmtime 46.0.0 before 48.0.6 and 49.0.0 before 49.0.3 contains a denial of service vulnerability that allows malicious components to panic the host via thread.yield in start functions. Attackers can supply a component whose start function calls an async-lowered import then thread.yield, causing an undisposed fiber drop that crashes embedders.

Wasmtime 46.0.0 before 48.0.6 and 49.0.0 before 49.0.3 contains a leftover assertion in component::Func::call that rejects guest exports using the async ABI option. An attacker who supplies a component with an async-lifted export can crash the host process when an embedder invokes that export through Func::call.

Wasmtime 46.0.0 before 48.0.6 and 49.0.0 before 49.0.3 contains a denial of service vulnerability that allows pending calls to trigger an assertion failure after a trap poisons the Store. Attackers supplying misbehaving guest code can cause a trap and let earlier calls proceed, crashing embedders that continue using the inconsistent Store.

Wasmtime 42.0.0 before 48.0.6 and 49.0.0 before 49.0.3 contains a stack overflow vulnerability that allows guests to crash the host through recursive type drops. Guests can define a long chain of recursive types so that removing the top-level type triggers unbounded recursive drops, exhausting the host stack.

Wasmtime 42.0.0 before 48.0.6 and 49.0.0 before 49.0.3 contains insufficient checks in Store when mixing async-style and sync-style WebAssembly calls. Embedders re-entering WebAssembly via sync APIs from host functions called asynchronously can trigger runtime panics or unsound cross-thread movement of !Send host variables.

Wasmtime 46.0.0 before 48.0.6 and 49.0.0 before 49.0.3 panics when the host reads a component model stream as a different Rust item type than it was created with, because the host-to-host read path asserts matching TypeIds instead of returning an error. Guest code can return a host-created StreamReader<U> that the embedder reads as StreamReader<T>, where both types map to the same component model type, crashing the embedding process.

Wasmtime before 36.0.18, 37.0.0 before 48.0.6, and 49.0.0 before 49.0.3 caps component-model resource handle tables only per component instance and does not charge handle allocations to any ResourceLimiter or StoreLimits. A malicious guest can repeatedly call resource.new and instantiate sub-components to exceed the per-instance cap many times over, causing unbounded host memory growth.

Wasmtime 47.0.0 before 48.0.6 and 49.0.0 before 49.0.3 contains a memory misalignment flaw in the VMContext layout that causes undefined behavior when modules contain an odd number of exception tags. A WebAssembly module with an odd tag count misaligns subsequent host fields in embedders with exceptions enabled, although no exploitation path is currently known.

Wasmtime from 49.0.0 before 49.0.3 contains a denial-of-service vulnerability that allows a WebAssembly guest to trigger a host panic by transcoding overlapping strings in fused adapters. Attackers can make a same-instance component-to-component call transferring a string whose source and destination alias each other, crashing the host instead of raising a trap.

Wasmtime 46.0.0 before 48.0.6 and 49.0.0 before 49.0.3 contains a denial of service vulnerability in wasmtime-wasi-http that lets guests crash the host by sending long request URLs. Guests can use set-path-with-query with a '?' after byte 65535, overflowing a u16 index in the http crate and triggering a host panic.

Wasmtime before 36.0.18, 37.0.0 before 48.0.6, and 49.0.0 before 49.0.3 does not verify that set-path-with-query values in wasmtime-wasi-http are paths, so absolute-form URLs are written verbatim as the HTTP/1.1 request target while the connection uses the allowed authority. A malicious guest can supply an absolute URL that a forward proxy or gateway at that authority honors, reaching hosts disallowed by embedder filtering policies.

wasmtime-wasi in Wasmtime before 36.0.18, 37.0.0 before 48.0.6, and 49.0.0 before 49.0.3 re-appends a trailing slash to rename source paths, causing renameat on macOS and FreeBSD hosts to follow directory symlinks. A guest with sandbox write access can rename a relative symlink such as "up/" to move host directories into its sandbox and read or write them.

Wasmtime from 46.0.0 until 48.0.7 and 49.0.4, when 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 via StreamAny, FutureAny, Val::Stream, Val::Future, or an equivalent typed reader; a malicious guest can panic the Wasmtime host.

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 before 36.0.17, 37.0.0 before 48.0.4, and 49.0.0 before 49.0.2 contains an information disclosure vulnerability in the WASIp1 fd_readdir implementation that copies uninitialized struct padding into guest memory. Guests with a preopened directory can list entries to receive three bytes of leftover host stack or heap memory per directory entry.

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.

Wasmtime contains an unbounded memory allocation in the wasmtime-wasi WASIp2 write-zeroes method of SinkOutputStream, the default stream used when stdout/stderr are not configured. A malicious WebAssembly guest can request huge zero-filled writes, exhausting host memory and causing denial of service.

Wasmtime contains a denial of service vulnerability in the wasmtime-wasi WASI preview 0 poll_oneoff adapter, which performs O(n) host work per subscription without consuming or checking fuel. Malicious guest modules can pass many subscriptions to force long-running host computation that ignores configured fuel limits.

Wasmtime contains a missing GC rooting vulnerability that leaves references live across try_call unrooted when compiling Wasm modules. Attackers can supply Wasm modules whose callee triggers garbage collection, leaving stale or dangling references that cause GC heap corruption or incorrect execution.

Wasmtime is a runtime for WebAssembly. From 46.0.0 until 46.0.2 and 47.0.3, fuel and epoch preemption checks inside bulk operations including memory.copy, table.grow, and array.copy can expose invalid intermediate state when an embedder mutates a Store in Store::epoch_deadline_callback or continues using a Store after cancellation or a trap. This can result in a crash, invalid memory access, or GC heap corruption.

Wasmtime is a runtime for WebAssembly. Prior to versions 24.0.11, 36.0.12, 45.0.3, and 46.0.1, the wasmtime-wasi component checked directory permissions but not matching FilePerms on source and destination preopens during hard-link creation and renaming. This allowed a WASI guest with read-only source file capability to overwrite host files exposed as FilePerms::READ through wasip1, wasip2, or wasip3 filesystem interfaces.

Wasmtime prior to versions 24.0.10, 36.0.11, 44.0.3, and 45.0.2 contains a vulnerability in the native WASIp1 implementation where the fd_renumber function fails to properly close the target file descriptor. This causes resource leaks in the host system, potentially leading to exhaustion of file descriptors and resources.

Wasmtime, a runtime for WebAssembly, has a vulnerability in versions prior to 24.0.9, 36.0.10, and 44.0.2 that allows bypassing the access control mechanism using the wasip2 descriptor.open-at or wasip1 path_open interfaces. The issue arises from a missing assignment in the open mode handling, allowing files to be opened with the OpenFlags::TRUNCATE flag without the necessary write permissions.

Wasmtime versions 30.0.0 through 36.0.8, 43.0.2, and 44.0.1 contain a vulnerability where allocation logic for WebAssembly tables panics on overflow. This panic can be triggered when allocating extremely large tables (64-bit range via memory64 proposal). An attacker can cause a denial of service by providing a WebAssembly module or component that requests such a large table.

In Wasmtime prior to 24.0.7, 36.0.7, 42.0.2, and 43.0.1, the implementation of transcoding strings between components does not validate the return value of a guest component's realloc before the host writes through the pointer. This enables a guest to cause the host to write arbitrary transcoded string bytes to an arbitrary location up to 4GiB away from the base of linear memory, potentially hitting unmapped memory or corrupting host data structures.

A vulnerability in Wasmtime's Winch compiler backend (versions 25.0.0 to before 36.0.7, 42.0.2, and 43.0.1) causes the result of the table.grow operator to be incorrectly typed. For 32-bit tables, the result is internally tagged as a 64-bit value, leading to compiler state corruption and potentially allowing read/write of up to 16 bytes before linear memory. The default Wasmtime configuration (Cranelift compiler, guard pages) is not affected; the issue occurs when Winch is explicitly chosen.

A vulnerability in Wasmtime (versions 28.0.0 to before 36.0.7, 42.0.2, and 43.0.1) in the pooling allocator implementation incorrectly determines whether to reset virtual memory permissions for linear memory. Due to a divergence between compile-time and runtime predicates, under specific configurations (memory_guard_size=0, memory_reservation < 4GiB, max_memory_size equal to memory_reservation) linear memory contents can leak between instances. This breaks WebAssembly semantics and the Wasmtime sandbox.

In Wasmtime 43.0.0, cloning a wasmtime::Linker is unsound and can result in use-after-free bugs. The bug is not controllable by guest Wasm programs; it can only be triggered by a specific sequence of embedder API calls by the host: clone a Linker, drop the original, then use the clone. The vulnerability is fixed in 43.0.1.

Wasmtime versions 32.0.0 through 36.0.7, 42.0.2, and 43.0.1 have a bug in the Cranelift compiler on aarch64 that miscalculates memory addresses during heap access. This allows WebAssembly modules to bypass bounds checks and access arbitrary host memory, resulting in a sandbox escape.

Wasmtime's Winch compiler contains an indexing bug when compiling the table.fill instruction, caused by a historical refactoring that failed to update Winch code paths. A valid guest can cause a host panic or modify the wrong table. The vulnerability is fixed in 36.0.7, 42.0.2, and 43.0.1.

Wasmtime from 25.0.0 to before 36.0.7, 42.0.2, and 43.0.1 has a bug in the Winch compiler where a 64-bit table (part of the memory64 proposal) incorrectly translates the table.size instruction. This can disclose host stack data to WebAssembly guests. The bug arose from statically typing the return value as a 32-bit integer instead of consulting the table's index type.

Wasmtime, a WebAssembly runtime, prior to 24.0.7, 36.0.7, 42.0.2, and 43.0.1 on x86-64 platforms with SSE3 disabled may load 8 more bytes than necessary when compiling the f64x2.splat instruction with Cranelift. With signals-based traps disabled this can cause an uncaught segfault, and with guard pages disabled out-of-sandbox data may be loaded (not visible to WebAssembly guests).

In Wasmtime prior to 24.0.7, 36.0.7, 42.0.2, and 43.0.1, the implementation of transcoding strings into the Component Model's utf16 or latin1+utf16 encodings improperly verified the alignment of reallocated strings. Unaligned pointers could be passed to the host for transcoding, triggering a host panic that a malicious guest can deliberately cause.

Wasmtime contains a byte-length validation flaw when transcoding a UTF-16 string to the latin1+utf16 component-model encoding. It checks the number of code units instead of the byte length, which can cause reads beyond the end of WebAssembly linear memory. In the default configuration this triggers a segfault (denial of service), and with guard pages disabled it may allow reading host memory.

In Wasmtime, a WebAssembly runtime, versions prior to 38.0.4, 37.0.3, 36.0.3, and 24.0.5 contain an unsound interaction in the Rust embedder API. A WebAssembly shared linear memory could be viewed as a type providing safe host access to its contents, leading to a data race in the host when modified in parallel.