Wasmtime
Monthly
Sandbox escape in Wasmtime on aarch64 lets a user-supplied WebAssembly module redirect an oversized br_table branch to attacker-chosen code when the default Cranelift backend compiles a table with more than roughly 256,000 targets. The flaw affects Wasmtime/Cranelift builds supporting aarch64 since 2020 up to the fixed releases 36.0.19, 48.0.7, and 49.0.4; x86-64 engines and non-Cranelift backends are outside the affected configuration. CVSS 9.9 reflects scope change with high confidentiality, integrity, and availability impact, and the issue carries an act_now priority; no public exploit was identified at time of analysis.
Wasmtime versions before 36.0.19, and the 37.0.0 through 42.x line, can silently miscompile attacker-supplied WebAssembly because Cranelift's SSA value-index packing overflows in release builds, letting a specially crafted or very large function make the compiler reference the wrong IR value and produce type confusion that may cross the Wasm sandbox boundary on any architecture using the default Cranelift backend. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:C) reflects that a low-privileged position plus control of the compiled module is enough to reach a scope-changing impact, and the flaw is only reachable when the host actually compiles untrusted guests; hosts that only run first-party modules are not exposed. The vendor has released 36.0.19 and 43.0.0, and the priority label is act_now, though no public exploit has been 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.
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 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.
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 46.0.0 through 48.0.6 and 49.0.0 through 49.0.3 can be panicked by a malicious guest that induces a type mismatch when a host-created component-model stream or future is lowered back into guest code with a different payload type. Exposure is narrow: only embedders that create streams or futures with StreamReader::new or FutureReader::new, pass them through guest code, receive them back through a type-erased path such as StreamAny, FutureAny, Val::Stream or Val::Future, and then forward them to a guest function expecting a different payload type are affected; the result is a host crash (denial of service) with no code execution or data exposure. The issue is fixed in 48.0.7 and 49.0.4, and no public exploit was identified at the time of analysis.
Invalid intermediate VM state can be exposed in Wasmtime 46.0.0 through 46.0.1 and 47.0.0 through 47.0.2 when an embedder mutates a Store from inside its fuel or epoch preemption callback - or keeps using the Store after a trap/cancellation - while a guest is mid-way through a bulk operation such as memory.copy, table.grow, table.fill, or array.copy. Hitting that preemption window can leave null elements in a non-nullable table, invalidate retained raw pointers after linear-memory growth during memory.copy, or invalidate GC pointers when the callback triggers garbage collection during array.copy, yielding a crash, invalid memory access, or GC heap corruption (integrity and availability impact only, no confidentiality loss). Exploitation is gated on a non-default embedding configuration (assessed CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:L; PR:H in the assessed vector), requires winning a timing race, and no public exploit has been identified at time of analysis. Vendor-released patches are available in Wasmtime 46.0.2 and 47.0.3.
Resource exhaustion in Wasmtime's native WASIp1 implementation allows low-privileged WebAssembly guests to exhaust host-level file descriptors and OS resources by repeatedly invoking fd_renumber in a loop. The affected versions span four distinct release branches - all pre-24.0.10, 25.x-35.x, 37.x-44.x, and 45.0.0-45.0.1 - but only runtimes that both expose fd_renumber and grant guests the ability to open files are vulnerable. No public exploit code exists and the issue is not listed in CISA KEV; however, the attack is mechanically straightforward once the conditions are met, making patching the primary defense.
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.
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.
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.
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 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.
Crashes the host process in Wasmtime 38.0.0 through 38.0.2 when a deliberately hand-crafted WebAssembly component bypasses normal toolchain output to invoke a component-model intrinsic (for example resource.rep) through the host-to-wasm trampoline, and then a trap or error occurs while that intrinsic executes - the trampoline fails to populate the runtime trap-dispatch data, so execution jumps to address 0 and the host dies with a segfault or a Rust assertion failure. The prerequisites are narrow and must all line up: the vulnerable 38.x release, a component no conventional toolchain would emit, a host embedder that calls the intrinsic with exactly the right type signatures, and a subsequent wasm error on the affected path, which is why the independent assessment rates this as a low-priority, availability-only defect rather than a broadly exploitable flaw. The Rust crate was fixed in 38.0.3, no workarounds are offered by the vendor, the EPSS score is 0.43% (35th percentile), and no public exploit code identified at time of analysis.
Wasmtime is a fast and secure runtime for WebAssembly. Rated low severity (CVSS 2.3), this vulnerability is remotely exploitable, low attack complexity.
Wasmtime is an open source runtime for WebAssembly. Rated low severity (CVSS 2.9). No vendor patch available.
Wasmtime is an open source runtime for WebAssembly. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity.
wasmtime is a runtime for WebAssembly. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity. Public exploit code available.
Wasmtime is a standalone runtime for WebAssembly. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Wasmtime is a standalone runtime for WebAssembly. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity.
wasmtime is a fast and secure runtime for WebAssembly. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity.
wasmtime is a fast and secure runtime for WebAssembly. Rated critical severity (CVSS 9.9), this vulnerability is remotely exploitable, low attack complexity. This Out-of-bounds Read vulnerability could allow attackers to read data from memory outside the intended buffer boundaries.
Wasmtime is a standalone runtime for WebAssembly. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Out-of-bounds Write vulnerability could allow attackers to write data beyond allocated buffer boundaries leading to code execution or crashes.
Wasmtime is a standalone runtime for WebAssembly. Rated high severity (CVSS 8.6), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Wasmtime is a standalone runtime for WebAssembly. Rated high severity (CVSS 7.4), this vulnerability is remotely exploitable, no authentication required. This Buffer Overflow vulnerability could allow attackers to corrupt memory to execute arbitrary code or crash the application.
Wasmtime is a standalone runtime for WebAssembly. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Wasmtime is a standalone runtime for WebAssembly. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Wasmtime is a standalone runtime for WebAssembly. Rated medium severity (CVSS 5.6), this vulnerability is remotely exploitable, no authentication required.
Wasmtime is a standalone JIT-style runtime for WebAssembly, using Cranelift. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Use After Free vulnerability could allow attackers to access freed memory to execute arbitrary code or crash the application.
Wasmtime is an open source runtime for WebAssembly & WASI. Rated medium severity (CVSS 6.3). This Out-of-bounds Read vulnerability could allow attackers to read data from memory outside the intended buffer boundaries.
Wasmtime is an open source runtime for WebAssembly & WASI. Rated medium severity (CVSS 6.3). This Access of Resource Using Incompatible Type (Type Confusion) vulnerability could allow attackers to execute arbitrary code by exploiting type confusion in the application.
Wasmtime is an open source runtime for WebAssembly & WASI. Rated medium severity (CVSS 6.3). No vendor patch available.
Sandbox escape in Wasmtime on aarch64 lets a user-supplied WebAssembly module redirect an oversized br_table branch to attacker-chosen code when the default Cranelift backend compiles a table with more than roughly 256,000 targets. The flaw affects Wasmtime/Cranelift builds supporting aarch64 since 2020 up to the fixed releases 36.0.19, 48.0.7, and 49.0.4; x86-64 engines and non-Cranelift backends are outside the affected configuration. CVSS 9.9 reflects scope change with high confidentiality, integrity, and availability impact, and the issue carries an act_now priority; no public exploit was identified at time of analysis.
Wasmtime versions before 36.0.19, and the 37.0.0 through 42.x line, can silently miscompile attacker-supplied WebAssembly because Cranelift's SSA value-index packing overflows in release builds, letting a specially crafted or very large function make the compiler reference the wrong IR value and produce type confusion that may cross the Wasm sandbox boundary on any architecture using the default Cranelift backend. The CVSS vector (AV:N/AC:L/PR:L/UI:N/S:C) reflects that a low-privileged position plus control of the compiled module is enough to reach a scope-changing impact, and the flaw is only reachable when the host actually compiles untrusted guests; hosts that only run first-party modules are not exposed. The vendor has released 36.0.19 and 43.0.0, and the priority label is act_now, though no public exploit has been 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.
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 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.
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 46.0.0 through 48.0.6 and 49.0.0 through 49.0.3 can be panicked by a malicious guest that induces a type mismatch when a host-created component-model stream or future is lowered back into guest code with a different payload type. Exposure is narrow: only embedders that create streams or futures with StreamReader::new or FutureReader::new, pass them through guest code, receive them back through a type-erased path such as StreamAny, FutureAny, Val::Stream or Val::Future, and then forward them to a guest function expecting a different payload type are affected; the result is a host crash (denial of service) with no code execution or data exposure. The issue is fixed in 48.0.7 and 49.0.4, and no public exploit was identified at the time of analysis.
Invalid intermediate VM state can be exposed in Wasmtime 46.0.0 through 46.0.1 and 47.0.0 through 47.0.2 when an embedder mutates a Store from inside its fuel or epoch preemption callback - or keeps using the Store after a trap/cancellation - while a guest is mid-way through a bulk operation such as memory.copy, table.grow, table.fill, or array.copy. Hitting that preemption window can leave null elements in a non-nullable table, invalidate retained raw pointers after linear-memory growth during memory.copy, or invalidate GC pointers when the callback triggers garbage collection during array.copy, yielding a crash, invalid memory access, or GC heap corruption (integrity and availability impact only, no confidentiality loss). Exploitation is gated on a non-default embedding configuration (assessed CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:U/C:N/I:L/A:L; PR:H in the assessed vector), requires winning a timing race, and no public exploit has been identified at time of analysis. Vendor-released patches are available in Wasmtime 46.0.2 and 47.0.3.
Resource exhaustion in Wasmtime's native WASIp1 implementation allows low-privileged WebAssembly guests to exhaust host-level file descriptors and OS resources by repeatedly invoking fd_renumber in a loop. The affected versions span four distinct release branches - all pre-24.0.10, 25.x-35.x, 37.x-44.x, and 45.0.0-45.0.1 - but only runtimes that both expose fd_renumber and grant guests the ability to open files are vulnerable. No public exploit code exists and the issue is not listed in CISA KEV; however, the attack is mechanically straightforward once the conditions are met, making patching the primary defense.
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.
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.
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.
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 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.
Crashes the host process in Wasmtime 38.0.0 through 38.0.2 when a deliberately hand-crafted WebAssembly component bypasses normal toolchain output to invoke a component-model intrinsic (for example resource.rep) through the host-to-wasm trampoline, and then a trap or error occurs while that intrinsic executes - the trampoline fails to populate the runtime trap-dispatch data, so execution jumps to address 0 and the host dies with a segfault or a Rust assertion failure. The prerequisites are narrow and must all line up: the vulnerable 38.x release, a component no conventional toolchain would emit, a host embedder that calls the intrinsic with exactly the right type signatures, and a subsequent wasm error on the affected path, which is why the independent assessment rates this as a low-priority, availability-only defect rather than a broadly exploitable flaw. The Rust crate was fixed in 38.0.3, no workarounds are offered by the vendor, the EPSS score is 0.43% (35th percentile), and no public exploit code identified at time of analysis.
Wasmtime is a fast and secure runtime for WebAssembly. Rated low severity (CVSS 2.3), this vulnerability is remotely exploitable, low attack complexity.
Wasmtime is an open source runtime for WebAssembly. Rated low severity (CVSS 2.9). No vendor patch available.
Wasmtime is an open source runtime for WebAssembly. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity.
wasmtime is a runtime for WebAssembly. Rated medium severity (CVSS 5.5), this vulnerability is low attack complexity. Public exploit code available.
Wasmtime is a standalone runtime for WebAssembly. Rated medium severity (CVSS 5.3), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Wasmtime is a standalone runtime for WebAssembly. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity.
wasmtime is a fast and secure runtime for WebAssembly. Rated medium severity (CVSS 4.3), this vulnerability is remotely exploitable, low attack complexity.
wasmtime is a fast and secure runtime for WebAssembly. Rated critical severity (CVSS 9.9), this vulnerability is remotely exploitable, low attack complexity. This Out-of-bounds Read vulnerability could allow attackers to read data from memory outside the intended buffer boundaries.
Wasmtime is a standalone runtime for WebAssembly. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Out-of-bounds Write vulnerability could allow attackers to write data beyond allocated buffer boundaries leading to code execution or crashes.
Wasmtime is a standalone runtime for WebAssembly. Rated high severity (CVSS 8.6), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Wasmtime is a standalone runtime for WebAssembly. Rated high severity (CVSS 7.4), this vulnerability is remotely exploitable, no authentication required. This Buffer Overflow vulnerability could allow attackers to corrupt memory to execute arbitrary code or crash the application.
Wasmtime is a standalone runtime for WebAssembly. Rated high severity (CVSS 7.5), this vulnerability is remotely exploitable, no authentication required, low attack complexity.
Wasmtime is a standalone runtime for WebAssembly. Rated high severity (CVSS 8.8), this vulnerability is remotely exploitable, low attack complexity. No vendor patch available.
Wasmtime is a standalone runtime for WebAssembly. Rated medium severity (CVSS 5.6), this vulnerability is remotely exploitable, no authentication required.
Wasmtime is a standalone JIT-style runtime for WebAssembly, using Cranelift. Rated critical severity (CVSS 9.8), this vulnerability is remotely exploitable, no authentication required, low attack complexity. This Use After Free vulnerability could allow attackers to access freed memory to execute arbitrary code or crash the application.
Wasmtime is an open source runtime for WebAssembly & WASI. Rated medium severity (CVSS 6.3). This Out-of-bounds Read vulnerability could allow attackers to read data from memory outside the intended buffer boundaries.
Wasmtime is an open source runtime for WebAssembly & WASI. Rated medium severity (CVSS 6.3). This Access of Resource Using Incompatible Type (Type Confusion) vulnerability could allow attackers to execute arbitrary code by exploiting type confusion in the application.
Wasmtime is an open source runtime for WebAssembly & WASI. Rated medium severity (CVSS 6.3). No vendor patch available.