Wasmtime is a runtime for WebAssembly. From 32.0.0 to before 36.0.7, 42.0.2, and 43.0.1, 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 WebAssembly is not affected. Spectre mitigations or signals-based-traps must be disabled. When spectre mitigations are enabled then the offending shape of load is not generated. When signals-based-traps are disabled then spectre mitigations are also automatically disabled. The specific bug in Cranelift is a miscompile of a load of the shape load(iadd(base, ishl(index, amt))) where amt is a constant. The amt value is masked incorrectly to test if it's a certain value, and this incorrect mask means that Cranelift can pattern-match this lowering rule during instruction selection erroneously, diverging from WebAssembly's and Cranelift's semantics. This incorrect lowering would, for example, load an address much further away than intended as the correct address's computation would have wrapped around to a smaller value insetad. This vulnerability is fixed in 36.0.7, 42.0.2, and 43.0.1.

Wasmtime is a runtime for WebAssembly. From 30.0.0 to 36.0.8, 43.0.2, and 44.0.1, 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 vulnerability is fixed in 36.0.8, 43.0.2, and 44.0.1.

Summary

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 amongst embeddings. A panic in the host is considered a denial-of-service vector for WebAssembly embedders and is thus a security issue in Wasmtime.

This bug does not affect WASIp2 and embedders using components.

Patches

In accordance with Wasmtime's release process patch releases are available as 24.0.4, 33.0.2, and 34.0.2. Users of other release of Wasmtime are recommended to move to a supported release of Wasmtime.

Workarounds

Embedders who are using components or are not providing guest access to create more file descriptors (e.g. via a preopened filesystem directory) are not affected by this issue. Otherwise there is no workaround at this time and affected embeddings are recommended to update to a patched version which will not cause a panic in the host.

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 trap, and this is intended to be updated by trampolines during their execution. In this situation the trampoline didn't do anything meaning that the value was left set to 0 meaning that execution would jump to the 0 address and deterministically crash the program with a segfault.

Component intrinsic host-to-wasm trampolines are not typically used in most situations. These only exist for carefully crafted components no toolchain would conventionally produce. For example if the resource.rep intrinsic were directly lifted without having any other wasm in play then it would use the component intrinsic host-to-wasm trampoline. This effectively means that any component required to trigger this bug would have to be carefully crafted for this specific issue. Furthermore triggering this bug would require that these intrinsics are called from the host which requires specific type signatures to be used. Not all embeddings may be invoking functions with exactly the right type signatures, meaning that even if a component could be crafted a pre-built embedding may still not be able to run the component.

Overall the goal of Wasmtime's API is that, without unsafe in Rust, it should not be possible to crash the runtime. With Wasmtime 38.0.{0,1,2} it is possible to crash the runtime, however, hence this security issue. Actually exploiting this in practice would require (a) carefully crafted components, (b) a very specific host embedder using the right type signatures, and (c) a host that updated to 38.0.{0,1,2} within the last few days (38.0.0 was released on 2025-10-20, and this is being published on 2025-10-24). This likely means that almost no embedding is affected, but this security issue is nonetheless being posted for awareness.

Patches

Wasmtime 38.0.3 has been released and is patched to fix this issue.

Workarounds

Affected embeddings have no workaround other than updating to 38.0.3. Users of 37.0.x and prior are not affected. Embeddings that only work with core wasm are not affected. Embeddings may only be affected if functions of specific component type signatures are used/invoked, meaning that if all the prior conditions hold the embedding would need to be audited to see if it's affected.

References

The PR which refactored setjmp/longjmp usage and introduced this issue is https://github.com/bytecodealliance/wasmtime/pull/11592.

Impact

Wasmtime's native implementation of WASIp1 suffers from a leak in the fdrenumber 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 fdrenumber 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. This means that guests can, in a loop, use fdrenumber to cause hosts to exhaust resources or exhaust file descriptors.

This bug only affects the native implementation of WASIp1. This means that only runtimes which load core wasm modules and expose fdrenumber 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.

Patches

Wasmtime 24.0.10, 36.0.11, 44.0.3, and 45.0.2 have been released which fix this issue.

Workarounds

There are no workarounds for this issue and hosts are recommended to update.

Impact

Wasmtime 37.0.0 and 37.0.1 have memory leaks in the C/C++ API when using bindings for the anyref or externref WebAssembly values. This is caused by a regression introduced during the development of 37.0.0 and all prior versions of Wasmtime are unaffected. If anyref or externref is not used in the C/C++ API then embeddings are also unaffected by the leaky behavior. The wasmtime Rust crate is unaffected by this leak.

Development of Wasmtime 37.0.0 included a refactoring in Rust of changing the old ManuallyRooted<T> type to a new OwnedRooted<T> type. This change was integrated into Wasmtime's C API but left the C API in a state which had memory leaks. Additionally the new ownership semantics around this type were not reflected into the C++ API, making it leak-prone. A short version of the change is that previously ManuallyRooted<T>, as the name implies, required manual calls to an "unroot" operation. If this was forgotten then the memory was still cleaned up when the wasmtimestoret itself was destroyed eventually. Documentation of when to "unroot" was sparse and there were already situations prior to 37.0.0 where memory would be leaked until the store was destroyed anyway. All memory, though, was always bound by the store, and destroying the store would guarantee that there were no memory leaks.

In migrating to OwnedRooted<T> the usage of the type in Rust changed. A manual "unroot" operation is no longer required and it happens naturally as a destructor of the OwnedRooted<T> type in Rust itself. These new resource ownership semantics were not fully integrated into the preexisting semantics of the C/C++ APIs in Wasmtime. A crucial distinction of OwnedRooted<T> vs ManuallyRooted<T> is that the OwnedRooted<T> type allocates host memory outside of the store. This means that if an OwnedRooted<T> is leaked then destroying a store does not release this memory and it's a permanent memory leak on the host. This led to a few distinct, but related, issues arising:

A typo in the wasmtimevalunroot function in the C API meant that it did not actually unroot anything. This meant that even if embedders faithfully call the function then memory will be leaked. If a host-defined function returned a wasmtime{externref,anyref}t value then the value was never unrooted. The C/C++ API no longer has access to the value and the Rust implementation did not unroot. This meant that any values returned this way were never unrooted. The goal of the C++ API of Wasmtime is to encode automatic memory management in the type system, but the C++ API was not updated when OwnedRooted<T> was added. This meant that idiomatic usage of the C++ API would leak memory due to a lack of destructors on values.

These issues have all been fixed in a 37.0.2 release of Wasmtime. The implementation of the C and C++ APIs have been updated accordingly and respectively to account for the changes of ownership here. For example wasmtimevalunroot has been fixed to unroot, the Rust-side implementation of calling an embedder-defined function will unroot return values, and the C++ API now has destructors on the ExternRef, AnyRef, and Val types. These changes have been made to the 37.0.x release branch in a non-API-breaking fashion. Changes to the 38.0.0 release branch (and main in the Wasmtime repository) include minor API updates to better accomodate the API semantic changes.

Patches

Wasmtime 37.0.2 has been released which fixes these issues. Users of 37.0.0 and 37.0.1 are recommended to upgrade. Users of 36.0.x and prior are unaffected and need not upgrade.

Workarounds

The only known workaround at this time is to avoid using externref and anyref in the C/C++ API of Wasmtime. If avoiding those types is not possible then it's required for users to update to mitigate the leak issue.

Remediations

The Wasmtime project will be looking more closely into improving the situation around testing the C and C++ APIs of Wasmtime in the near future. For example we plan to integrate ASAN testing to discover leaks and errors earlier on in the development process. We're also going to look into expanding the test coverage of the C/C++ APIs to catch issues like this earlier on in development in the future.