Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
62 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-vqjp-4c8c-hfgg For more information see the GitHub-hosted security advisory.
Recommended action: Upgrade to 47.0.4, 46.0.3, 36.0.14 or 24.0.13 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
This is an entry in the RustSec database for the Wasmtime security advisory located at https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hgjw-h833-99q9 For more information see the GitHub-hosted security advisory.
Recommended action: Upgrade to 47.0.3, 46.0.2, 36.0.13 or 24.0.12 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Wasmtime's allocation logic for a WebAssembly table contained checked arithmetic which panicked on overflow. This overflow is possible to trigger, and thus panic, when a table with an extremely large size is allocated. This is possible with the WebAssembly memory64 proposal where tables can have sizes in the 64-bit range as opposed to the previous 32-bit range which would not overflow. The panic happens when attempting to create a very large table, such as when instantiating a WebAssembly module or component. This bug does not affect the pooling allocator which limits tables sizes to much less than the required amount to trigger the overflow. This bug is only present for the on-demand instance allocator, which is Wasmtime's default allocator. This bug also requires the memory64 WebAssembly feature to be enabled, which is on-by-default. Panicking in the host process is considered a denial-of-service vector for Wasmtime. Patches Wasmtime 36.0.8, 43.0.2, and 44.0.1 have all been…
Recommended action: Upgrade to 43.0.2 or 36.0.8 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. One example can be seen when the result of table.grow is used as the address of a load operation. The load operation is tricked into thinking the address is a 64-bit value, not a 32-bit value, which means that the final address to load from is calculated incorrectly. This can lead to a situation where the bytes before the start of linear memory can be loaded/stored to. 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…
Recommended action: Upgrade to 43.0.1, 42.0.2 or 36.0.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Wasmtime with its Winch (baseline) non-default compiler backend may allow properly constructed guest Wasm to access host memory outside of its linear-memory sandbox. This vulnerability requires use of the Winch compiler (-Ccompiler=winch). By default, Wasmtime uses its Cranelift backend, not Winch. With Winch, the same incorrect assumption is present in theory on both aarch64 and x86-64. The aarch64 case has an observed-working proof of concept, while the x86-64 case is theoretical and may not be reachable in practice. This Winch compiler bug can allow the Wasm guest to access memory before or after the linear-memory region, independently of whether pre- or post-guard regions are configured. The accessible range in the initial bug proof-of-concept is up to 32KiB before the start of memory, or ~4GiB after the start of memory, independently of the size of pre- or post-guard regions or the use of explicit or guard-region-based bounds checking. However, the underlying bug assumes…
Recommended action: Upgrade to 43.0.1, 42.0.2 or 36.0.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Wasmtime's implementation of transcoding strings between components contains a bug where the return value of a guest component's realloc is not validated before the host attempts to write 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. These writes on the host could hit unmapped memory or could corrupt host data structures depending on Wasmtime's configuration. Wasmtime by default reserves 4GiB of virtual memory for a guest's linear memory meaning that this bug will by default on hosts cause the host to hit unmapped memory and abort the process due to an unhandled fault. Wasmtime can be configured, however, to reserve less memory for a guest and to remove all guard pages, so some configurations of Wasmtime may lead to corruption of data outside of a guest's linear memory, such as host data structures or other guests's linear memories. Patches Wasmtime…
Recommended action: Upgrade to 43.0.1, 42.0.2, 36.0.7 or 24.0.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Wasmtime's implementation of its pooling allocator contains a bug where in certain configurations the contents of linear memory can be leaked from one instance to the next. The implementation of resetting the virtual memory permissions for linear memory used the wrong predicate to determine if resetting was necessary, where the compilation process used a different predicate. This divergence meant that the pooling allocator incorrectly deduced at runtime that resetting virtual memory permissions was not necessary while compile-time determine that virtual memory could be relied upon. Exposing this bug requires specific configuration values to be used. If any of these configurations are not applicable then this bug does not happen: The pooling allocator must be in use. The Config::memoryguardsize configuration option must be 0. The Config::memoryreservation configuration must be less than 4GiB. The pooling allocator must be configured with maxmemorysize the same as the…
Recommended action: Upgrade to 43.0.1, 42.0.2 or 36.0.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Wasmtime's Cranelift compilation backend contains a bug on aarch64 when performing a certain shape of heap accesses which means that the wrong address is accessed. When combined with explicit bounds checks a guest WebAssembly module this can create a situation where there are two diverging computations for the same address: one for the address to bounds-check and one for the address to load. This difference in address being operated on means that a guest module can pass a bounds check but then load a different address. Combined together this enables an arbitrary read/write primitive for guest WebAssembly when accesssing host memory. This is a sandbox escape as guests are able to read/write arbitrary host memory. This vulnerability has a few ingredients, all of which must be met, for this situation to occur and bypass the sandbox restrictions: This miscompiled shape of load only occurs on 64-bit WebAssembly linear memories, or when Config::wasmmemory64 is enabled. 32-bit…
Recommended action: Upgrade to 43.0.1, 42.0.2 or 36.0.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Wasmtime's Winch compiler contains a vulnerability where the compilation of the table.fill instruction can result in a host panic. This means that a valid guest can be compiled with Winch, on any architecture, and cause the host to panic. This represents a denial-of-service vulnerability in Wasmtime due to guests being able to trigger a panic. The specific issue is that a historical refactoring, #11254, changed how compiled code referenced tables within the table. instructions. This refactoring forgot to update the Winch code paths associated as well, meaning that Winch was using the wrong indexing scheme. Due to the feature support of Winch the only problem that can result is tables being mixed up or nonexistent tables being used, meaning that the guest is limited to panicking the host (using a nonexistent table), or executing spec-incorrect behavior and modifying the wrong table. Patches Wasmtime 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are…
Recommended action: Upgrade to 43.0.1, 42.0.2 or 36.0.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Wasmtime's Winch compiler contains a bug where a 64-bit table, part of the memory64 proposal of WebAssembly, incorrectly translated the table.size instruction. This bug could lead to disclosing data on the host's stack to WebAssembly guests. The host's stack can possibly contain sensitive data related to other host-originating operations which is not intended to be disclosed to guests. This bug specifically arose from a mistake where the return value of table.size was statically typed as a 32-bit integer, as opposed to consulting the table's index type to see how large the returned register could be. When combined with details about Wnich's ABI, such as multi-value returns, this can be combined to read stack data from the host, within a guest. This information disclosure should not be possible in WebAssembly, violates spec semantics, and is a vulnerability in Wasmtime. Patches Wasmtime 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update…
Recommended action: Upgrade to 43.0.1, 42.0.2 or 36.0.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
On x86-64 platforms with SSE3 disabled Wasmtime's compilation of the f64x2.splat WebAssembly instruction with Cranelift may load 8 more bytes than is necessary. When signals-based-traps are disabled this can result in a uncaught segfault due to loading from unmapped guard pages. With guard pages disabled it's possible for out-of-sandbox data to be loaded, but this data is not visible to WebAssembly guests. Details The f64x2.splat operator, when operating on a value loaded from a memory (for example with f64.load), compiles with Cranelift to code on x86-64 without SSE3 that loads 128 bits (16 bytes) rather than the expected 64 bits (8 bytes) from memory. When the address is in-bounds for a (correct) 8-byte load but not an (incorrect) 16-byte load, this can load beyond memory by up to 8 bytes. This can result in three different behaviors depending on Wasmtime's configuration: 1. If guard pages are disabled then this extra data will be loaded. The extra data is present in the upper bits…
Recommended action: Upgrade to 43.0.1, 42.0.2, 36.0.7 or 24.0.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Wasmtime contains a possible panic which can happen when a flags-typed component model value is lifted with the Val type. If bits are set outside of the set of flags the component model specifies that these bits should be ignored but Wasmtime will panic when this value is lifted. This panic only affects wasmtime's implementation of lifting into Val, not when using the flags! macro. This additionally only affects flags-typed values which are part of a WIT interface. This has the risk of being a guest-controlled panic within the host which Wasmtime considers a DoS vector. Patches Wasmtime 24.0.7, 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update to these patched versions of Wasmtime. Workarounds There is no workaround for this bug if a host meets the criteria to be affected. To be affected a host must be using wasmtime::component::Val and possibly work with a flags type in the component model.
Recommended action: Upgrade to 43.0.1, 42.0.2, 36.0.7 or 24.0.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Wasmtime's implementation of transcoding strings into the Component Model's utf16 or latin1+utf16 encodings improperly verified the alignment of reallocated strings. This meant that unaligned pointers could be passed to the host for transcoding which would trigger a host panic. This panic is possible to trigger from malicious guests which transfer very specific strings across components with specific addresses. Host panics are considered a DoS vector in Wasmtime as the panic conditions are controlled by the guest in this situation. Patches Wasmtime 24.0.7, 36.0.7, 42.0.2, and 43.0.1 have been issued to fix this bug. Users are recommended to update to these patched versions of Wasmtime. Workarounds There is no workaround for this bug. Hosts are recommended to updated to a patched version of Wasmtime.
Recommended action: Upgrade to 43.0.1, 42.0.2, 36.0.7 or 24.0.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Wasmtime contains a vulnerability where when transcoding a UTF-16 string to the latin1+utf16 component-model encoding it would incorrectly validate the byte length of the input string when performing a bounds check. Specifically the number of code units were checked instead of the byte length, which is twice the size of the code units. This vulnerability can cause the host to read beyond the end of a WebAssembly's linear memory in an attempt to transcode nonexistent bytes. In Wasmtime's default configuration this will read unmapped memory on a guard page, terminating the process with a segfault. Wasmtime can be configured, however, without guard pages which would mean that host memory beyond the end of linear memory may be read and interpreted as UTF-16. A host segfault is a denial-of-service vulnerability in Wasmtime, and possibly being able to read beyond the end of linear memory is additionally a vulnerability. Note that reading beyond the end of linear memory requires…
Recommended action: Upgrade to 43.0.1, 42.0.2, 36.0.7 or 24.0.7 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Wasmtime's implementation of the wasi:http/types.fields resource is susceptible to panics when too many fields are added to the set of headers. Wasmtime's implementation in the wasmtime-wasi-http crate is backed by a data structure which panics when it reaches excessive capacity and this condition was not handled gracefully in Wasmtime. Panicking in a WASI implementation is a Denial of Service vector for embedders and is treated as a security vulnerability in Wasmtime. Patches Wasmtime 24.0.6, 36.0.6, 40.0.4, 41.0.4, and 42.0.0 patch this vulnerability and return a trap to the guest instead of panicking. Workarounds There are no known workarounds at this time, embedders are encouraged to update to a patched version of Wasmtime. Resources Limitations of http::HeaderMap
Recommended action: Upgrade to 40.0.4, 36.0.6 or 24.0.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Wasmtime's implementation of WASI host interfaces are susceptible to guest-controlled resource exhaustion on the host. Wasmtime did not appropriately place limits on resource allocations requested by the guests. This serves as a Denial of Service vector where a guest can induce a range of crashing behaviors on the host such as: Allocating arbitrarily large amounts of host memory. Causing an allocation failure on the host, which in Rust defaults to aborting the process. Causing a panic on the host due to over-large allocations being performed. Cause degredation in performance of the host by holding excessive host memory alive. Wasmtime's security bug policy considers all of these behaviors a security vulnerability. Wasmtime's implementation of WASI has a number of different ways that resource exhaustion could happen, and fixing any one of them is insufficient from solving this vulnerability. A number of individual issues are grouped within this advisory and as a whole represent…
Recommended action: Upgrade to 40.0.4, 36.0.6 or 24.0.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The affected versions of Wasmtime can panic if the host embedder drops the future returned by wasmtime::component::[Typed]Func::callasync before it resolves. Details Starting with Wasmtime 39.0.0, the component-model-async feature became the default, which brought with it a new implementation of [Typed]Func::callasync which made it capable of calling async-typed guest export functions. However, that implementation had a bug leading to a panic under certain circumstances: 1. The host embedding calls [Typed]Func::callasync on a function exported by a component, polling the returned Future once. 2. The component function yields control to the async runtime (e.g. Tokio), e.g. due to a call to host function registered using LinkerInstance::funcwrapasync which yields, or due an epoch interruption. 3. The host embedding drops the Future after polling it once. This leaves the component instance in a non-reenterable state since the call never had a chance to complete. 4. The host embedding…
Recommended action: Upgrade to 41.0.4 or 40.0.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
On x86-64 platforms with AVX Wasmtime's compilation of the f64.copysign WebAssembly instruction with Cranelift may load 8 more bytes than is necessary. When [signals-based-traps] are disabled this can result in a uncaught segfault due to loading from unmapped guard pages. With guard pages disabled it's possible for out-of-sandbox data to be loaded, but unless there is another bug in Cranelift this data is not visible to WebAssembly guests. Details The f64.copysign operator, when operating on a value loaded from a memory (for example with f64.load), compiles with Cranelift to code on x86-64 with AVX that loads 128 bits (16 bytes) rather than the expected 64 bits (8 bytes) from memory. When the address is in-bounds for a (correct) 8-byte load but not an (incorrect) 16-byte load, this can load beyond memory by up to 8 bytes. This can result in three different behaviors depending on Wasmtime's configuration: 1. If guard pages are disabled then this extra data will be loaded. The extra…
Recommended action: Upgrade to 41.0.1, 40.0.3 or 36.0.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Wasmtime's Rust embedder API contains an unsound interaction where a WebAssembly shared linear memory could be viewed as a type which provides safe access to the host (Rust) to the contents of the linear memory. This is not sound for shared linear memories, which could be modified in parallel, and this could lead to a data race in the host. Wasmtime has a wasmtime::Memory type which represents linear memories in a WebAssembly module. Wasmtime also has wasmtime::SharedMemory, however, which represents shared linear memories introduced in the WebAssembly threads proposal. The API of SharedMemory does not provide accessors which return &[u8] in Rust, for example, as that's not a sound type signature when other threads could be modifying memory. The wasmtime::Memory type, however, does provide this API as it's intended to be used with non-shared memories where static knowledge is available that no concurrent or parallel reads or writes are happening. This means that it's not sound…
Recommended action: Upgrade to 38.0.4, 37.0.3, 36.0.3 or 24.0.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact The implementation of component-model related host-to-wasm trampolines in Wasmtime contained a bug where it's possible to carefully craft a component, which when called in a specific way, would crash the host with a segfault or assert failure. This bug was introduced in the release of Wasmtime 38.0.0 and affects it subsequent patch releases of 38.0.1 and 38.0.2. No other versions of Wasmtime are affected. In Wasmtime 38 the implementation of host-to-wasm trampolines was refactored to remove the old usage of setjmp and longjmp to unwind the stack. In this transition, however, trampolines for component-model intrinsics were accidentally not updated meaning that they didn't update runtime data structures as the other host-to-wasm trampolines did. If an error ocurred during execution of wasm it would then try to read this runtime data which isn't present, and processing it could then result in a crash. For example one piece of runtime data is where to jump to in the case of a…
Recommended action: Upgrade to 38.0.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A bug in Wasmtime's implementation of the WASIp1 set of import functions can lead to a WebAssembly guest inducing a panic in the host (embedder). The specific bug is triggered by calling pathopen after calling fdrenumber with either: - two equal argument values - second argument being equal to a previously-closed file descriptor number value The corrupt state introduced in fdrenumber will lead to the subsequent opening of a file descriptor to panic. This panic cannot introduce memory unsafety or allow WebAssembly to break outside of its sandbox, however. There is no possible heap corruption or memory unsafety from this panic. This bug is in the implementation of Wasmtime's wasmtime-wasi crate which provides an implementation of WASIp1. The bug requires a specially crafted call to fdrenumber in addition to the ability to open a subsequent file descriptor. Opening a second file descriptor is only possible when a preopened directory was provided to the guest, and this is common…
Recommended action: Upgrade to 34.0.2, 33.0.2 or 24.0.4 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Wasmtime's filesystem sandbox implementation on Windows blocks access to special device filenames such as "COM1", "COM2", "LPT0", "LPT1", and so on, however it did not block access to the special device filenames which use superscript digits, such as "COM¹", "COM²", "LPT⁰", "LPT¹", and so on. Untrusted Wasm programs that are given access to any filesystem directory could bypass the sandbox and access devices through those special device filenames with superscript digits, and through them gain access peripheral devices connected to the computer, or network resources mapped to those devices. This can include modems, printers, network printers, and any other device connected to a serial or parallel port, including emulated USB serial ports. Patches Patch releases for Wasmtime have been issued as 24.0.2, 25.0.3, and 26.0.1. Users of Wasmtime 23.0.x and prior are recommended to upgrade to one of these patched versions. Workarounds There are no known workarounds for this issue.…
Recommended action: Upgrade to 26.0.1, 25.0.3 or 24.0.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
24.0.121.0.222.0.125.0.223.0.3· Vendor fix available
Issue
Impact Under certain concurrent event orderings, a wasmtime::Engine's internal type registry was susceptible to double-unregistration bugs due to a race condition, leading to panics and potentially type registry corruption. That registry corruption could, following an additional and particular sequence of concurrent events, lead to violations of WebAssembly's control-flow integrity (CFI) and type safety. Users that do not use wasmtime::Engine across multiple threads are not affected. Users that only create new modules across threads over time are additionally not affected. Reproducing this bug requires creating and dropping multiple type instances (such as wasmtime::FuncType or wasmtime::ArrayType) concurrently on multiple threads, where all types are associated with the same wasmtime::Engine. Wasm guests cannot trigger this bug. See the "References" section below for a list of Wasmtime types-related APIs that are affected. Wasmtime maintains an internal registry of types within a…
Recommended action: Upgrade to 25.0.2, 24.0.1, 23.0.3 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
24.0.121.0.222.0.125.0.223.0.3· Vendor fix available
Issue
Impact Wasmtime's implementation of WebAssembly tail calls combined with stack traces can result in a runtime crash in certain WebAssembly modules. The runtime crash may be undefined behavior if Wasmtime was compiled with Rust 1.80 or prior. The runtime crash is a deterministic process abort when Wasmtime is compiled with Rust 1.81 and later. WebAssembly tail calls are a proposal which relatively recently reached stage 4 in the standardization process. Wasmtime first enabled support for tail calls by default in Wasmtime 21.0.0, although that release contained a bug where it was only on-by-default for some configurations. In Wasmtime 22.0.0 tail calls were enabled by default for all configurations. The specific crash happens when an exported function in a WebAssembly module (or component) performs a returncall (or returncallindirect or returncallref) to an imported host function which captures a stack trace (for example, the host function raises a trap). In this situation, the…
Recommended action: Upgrade to 25.0.2, 24.0.1, 23.0.3 or 2 more by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact There is a bug in Wasmtime's C API implementation where the definition of the wasmtimetrapcode does not match its declared signature in the wasmtime/trap.h header file. This discrepancy causes the function implementation to perform a 4-byte write into a 1-byte buffer provided by the caller. This can lead to three zero bytes being written beyond the 1-byte location provided by the caller. Patches This bug has been patched and users should upgrade to Wasmtime 2.0.2. Workarounds This can be worked around by providing a 4-byte buffer casted to a 1-byte buffer when calling wasmtimetrapcode. Users of the wasmtime crate are not affected by this issue, only users of the C API function wasmtimetrapcode are affected. References Definition of wasmtimetrapcode Mailing list announcement Patch to fix for main branch For more information If you have any questions or comments about this advisory: Reach out to us on the Bytecode Alliance Zulip chat Open an issue in the…
Recommended action: Upgrade to 2.0.2 or 1.0.2 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.