Wasmtime

Wasmtime prior to versions 24.0.7, 36.0.7, 42.0.2, and 43.0.1 allows authenticated remote attackers to corrupt memory by providing malicious realloc return values during string transcoding between WebAssembly components, enabling writes to arbitrary memory locations up to 4GiB away from linear memory base. On default configurations with 4GiB virtual memory reservation and guard pages, exploitation typically triggers process abort via unmapped memory access; however, configurations with reduced memory reservation and disabled guard pages risk corruption of host data structures or other guest linear memories.

Wasmtime versions 25.0.0 through 36.0.6, 42.0.0-42.0.1, and 43.0.0 contain a compiler type-checking bug in the Winch backend where the table.grow operator returns incorrectly typed 64-bit values instead of 32-bit values for 32-bit tables, enabling read/write access to 16 bytes of host memory preceding linear memory and resulting in denial of service when Wasmtime detects the unauthorized access. The vulnerability requires explicit selection of the non-default Winch compiler backend and either disabled guard pages or modified memory layout to achieve information disclosure; default Wasmtime configurations using the Cranelift compiler and standard guard page placement are unaffected. No public exploit code or active exploitation has been identified, though the attack vector is remote and requires low-privilege authenticated access.

Wasmtime's pooling allocator leaks linear memory contents between WebAssembly instances when configured with specific non-default settings (memory_guard_size=0, memory_reservation<4GiB, max_memory_size=memory_reservation). Affected versions 28.0.0 through 36.0.6, 42.0.0-42.0.1, and 43.0.0 allow authenticated local attackers with high attack complexity to read sensitive data from previously-mapped memory due to incorrect virtual memory permission reset logic. Vendor-released patches: 36.0.7, 42.0.2, and 43.0.1. No public exploit identified at time of analysis.

Memory sandbox escape in Wasmtime's Winch compiler (versions 25.0.0 to before 36.0.7, 42.0.2, 43.0.1) enables authenticated WebAssembly guests to access arbitrary host process memory outside linear-memory boundaries. Exploitation requires non-default Winch backend activation via -Ccompiler=winch flag. Attackers can read up to 32KiB before memory start or ~4GiB after, with theoretical potential for unlimited in-process memory access due to improper 32-bit offset handling in 64-bit registers. Consequences include host process crashes (DoS), sensitive data exfiltration, or remote code execution through memory writes. Affects aarch64 (confirmed PoC) and x86-64 (theoretical). Publicly available exploit code exists.

Wasmtime 43.0.0 contains a use-after-free vulnerability in the Linker cloning mechanism that allows host embedders to trigger memory corruption through a specific sequence of API calls: cloning a wasmtime::Linker, dropping the original instance, and then using the cloned instance. This vulnerability is not exploitable by guest WebAssembly programs and requires deliberate misuse of the host API. The flaw is fixed in Wasmtime 43.0.1. Despite the use-after-free nature (CWE-416), the CVSS 4.0 score of 1.0 reflects the extremely limited attack surface: physical or local access is required (AV:P), attack complexity is high (AC:H), high privilege level is needed (PR:H), and user interaction is required (UI:A), resulting in minimal confidentiality, integrity, and availability impact.

Arbitrary memory read/write vulnerability in Bytecode Alliance Wasmtime versions 32.0.0 through 36.0.6, 42.0.0-42.0.1, and 43.0.0 allows authenticated remote attackers to escape WebAssembly sandbox restrictions. The Cranelift compilation backend on aarch64 architecture miscompiles specific heap access patterns, creating divergent address computations where bounds checks validate one address while loads access another, enabling sandbox escape through unrestricted host memory access. Exploitation requires 64-bit WebAssembly linear memories with Spectre mitigations and signals-based-traps disabled. No public exploit identified at time of analysis.

Wasmtime's Winch compiler (versions 25.0.0 through 36.0.6, 42.0.0-42.0.1, and 43.0.0) contains a table indexing vulnerability in the table.fill instruction that causes host panic when compiled by Winch on any architecture. A valid WebAssembly guest can trigger this denial-of-service condition due to incorrect table reference indexing left behind after a historical refactoring. EPSS score of 5.9 reflects medium exploitability, and the vulnerability is patched in Wasmtime 36.0.7, 42.0.2, and 43.0.1.

Wasmtime's Winch compiler in versions 25.0.0 through 36.0.6, 42.0.1, and 43.0.0 incorrectly translates the WebAssembly table.size instruction for 64-bit tables under the memory64 proposal, allowing WebAssembly guests to read sensitive data from the host's stack. The vulnerability stems from static typing the return value as 32-bit instead of consulting the table's actual index type, which when combined with Winch's multi-value return ABI mechanics enables stack data disclosure. This is fixed in Wasmtime 36.0.7, 42.0.2, and 43.0.1; no public exploit code or active exploitation has been identified at time of analysis, but the low CVSS score (2.3) reflects limited real-world impact due to authentication requirements and limited technical scope.

Wasmtime's Cranelift compiler generates inefficient code for the f64x2.splat WebAssembly instruction on x86-64 platforms with SSE3 disabled, causing it to load 8 excess bytes beyond the intended operand. On systems with signals-based traps disabled, this overflow access can trigger segmentation faults from unmapped guard pages; with guard pages also disabled, out-of-sandbox memory is accessible to the runtime (though not to WebAssembly guests themselves). The vulnerability affects Wasmtime versions prior to 24.0.7, 36.0.7, 42.0.2, and 43.0.1, and is fixed in those releases. No public exploit code or active exploitation (KEV) is documented.

Wasmtime runtime before versions 24.0.7, 36.0.7, 42.0.2, and 43.0.1 panics when lifting component model flags-typed values with out-of-specification bit patterns, enabling guest-controlled denial-of-service in the host environment. The vulnerability requires high privilege and user interaction but affects a critical WebAssembly runtime used in production systems. No public exploit code is confirmed at time of analysis.

Wasmtime prior to versions 24.0.7, 36.0.7, 42.0.2, and 43.0.1 fails to properly validate pointer alignment when transcoding strings into UTF-16 or Latin-1+UTF-16 encodings within the Component Model, allowing authenticated malicious WebAssembly guests to trigger host panics by passing specially crafted unaligned pointers across component boundaries. This denial-of-service vulnerability requires authenticated access and specific string configurations but results in controllable host crashes. CVSS score 5.9 reflects moderate severity with attack vector network and authentication requirement; SSVC framework rates exploitation as not yet observed with non-automatable exploitation.

Wasmtime runtime versions prior to 24.0.7, 36.0.7, 42.0.2, and 43.0.1 incorrectly validate UTF-16 string byte lengths during component-model encoding transcoding, causing out-of-bounds memory reads that trigger process termination via segfault in default configurations or potentially expose host memory when guard pages are disabled. Authenticated users with UI interaction can trigger this denial-of-service vulnerability; reading beyond linear memory requires non-standard Wasmtime configuration without guard pages. No public exploit code has been identified at time of analysis.

Wasmtime's HTTP header handling in the wasmtime-wasi-http crate crashes when processing excessive header fields, allowing remote attackers to trigger denial of service against applications embedding Wasmtime. The vulnerability affects versions prior to 24.0.6, 36.0.6, 40.0.4, 41.0.4, and 42.0.0, and has been patched to return a controlled trap instead of panicking. Embedders should update immediately to mitigate this DoS vector.

Uncontrolled resource allocation in Wasmtime's WASI host interfaces allows authenticated guests to trigger denial of service on the host system by exhausting resources without proper limits. Affected versions prior to 24.0.6, 36.0.6, 40.0.4, 41.0.4, and 42.0.0 require explicit configuration to mitigate this issue, though Wasmtime 42.0.0 and later provide secure defaults. No patch is currently available for older versions, and resource exhaustion protections must be manually enabled.

Wasmtime versions 39.0.0 and later experience a denial-of-service panic when async WebAssembly component functions are called and then abandoned by the host before completion, such as when the Future is dropped after a single poll during an async yield. This affects applications using Wasmtime's component model with async support, allowing an attacker to crash the runtime through specially crafted async function invocations. A patch is available to address this stability issue.

Wasmtime versions 29.0.0 through 41.0.0 on x86-64 platforms with AVX contain an out-of-bounds memory read in the f64.copysign instruction compilation that can cause application crashes when signal-based traps are disabled. In configurations with disabled guard pages, this vulnerability could potentially leak out-of-sandbox data, though the data remains inaccessible to WebAssembly guests without additional Cranelift bugs. Patches are available in versions 36.0.5, 40.0.3, and 41.0.1.