JLSEC-2026-1363 Wasmtime has improperly masked return value from `table.grow` with Winch compiler backend

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...

JLSEC-2026-1359 Wasmtime has host panic when Winch compiler executes `table.fill`

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 i...

JLSEC-2026-1361 Wasmtime with Winch compiler backend on aarch64 may allow a sandbox-escaping memory access

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...

JLSEC-2026-1360 Wasmtime: Miscompiled guest heap access enables sandbox escape on aarch64 Cranelift

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...

JLSEC-2026-1350 Wasmtime provides unsound API access to a WebAssembly shared linear memory

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 paralle...

JLSEC-2026-1353 Wasmtime can panic when adding excessive fields to a `wasi:http/types.fields` instance

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...

JLSEC-2026-1354 Wasmtime: Heap OOB read in component model UTF-16 to latin1+utf16 string transcoding

Summary 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...

JLSEC-2026-1358 Wasmtime has host data leakage with 64-bit tables and Winch

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...

JLSEC-2026-1355 Wasmtime: Panic when transcoding misaligned utf-16 strings

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 ...

JLSEC-2026-1364 Wasmtime has out-of-bounds write or crash when transcoding component model strings

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...

JLSEC-2026-1348 Wasmtime doesn't fully sandbox all the Windows device filenames

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...

JLSEC-2026-1365 wasmtime has a panic when allocating a table exceeding the size of the host's address space

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 ca...

JLSEC-2026-1356 Wasmtime has a possible panic when lifting `flags` component value

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 pani...

JLSEC-2026-1351 Wasmtime is vulnerable to panic when dropping a `[Typed]Func::call_async` future

The affected versions of Wasmtime can panic if the host embedder drops the future returned by wasmtime::component::TypedFunc::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...

JLSEC-2026-1349 Wasmtime CLI is vulnerable to host panic through its fd_renumber function

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...

JLSEC-2026-1357 Wasmtime segfault or unused out-of-sandbox load with `f64x2.splat` operator on x86-64

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...

JLSEC-2026-1366 wasmtime-wasi: WASI path_open(TRUNCATE) bypasses `FilePerms::WRITE` host restriction

Summary In wasmtime-wasi, when a filesystem preopen is given DirPerms::all and FilePerms::READ without FilePerms::WRITE, this wasmtime-wasi enforced access control mechanism can be bypassed by using the wasip2 descriptor.open-at or wasip1 pathopen interfaces by opening a file with...

JLSEC-2026-1368

Wasmtime is a runtime for WebAssembly. Prior to 24.0.11, 36.0.12, 45.0.3, and 46.0.1, wasmtime-wasi hard-link creation and renaming check directory permissions but not matching FilePerms on source and destination preopens, allowing a WASI guest with a read-only source file capability to overwrite...

JLSEC-2026-1367

Wasmtime is a runtime for WebAssembly. All versions prior to 24.0.10; versions 25.0.0 through those before 36.0.11; versions 37.0.0 through those before 44.0.3; and versions 45.0.0 and 45.0.1 contain a native implementation of WASIp1 which suffers from a leak in the fdrenumber function where the...

JLSEC-2026-1352 Wasmtime WASI implementations are vulnerable to guest-controlled resource exhaustion

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...