Live › vulnerability › CVE-2026-115382
Go to dashboardWasmtime versions 46.0.0 before 48.0.4 and 49.0.0 before 49.0.2 pass a guest-supplied zero between-bytes-timeout in wasi:http straight to a Tokio API that panics. A guest module can therefore crash the host process that embeds Wasmtime.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Teams that embed Wasmtime and expose the wasi:http implementation to guest code they do not fully trust, such as plugin or multi-tenant hosts. Standalone uses of Wasmtime that run only trusted modules, or that do not enable wasi:http, are less exposed.
No product ranges from the sources yet.
wasmtime --version on the host, or check the embedding application's pinned wasmtime crate version in Cargo.lock.48.0.4 or later on the 48 line, or to 49.0.2 or later on the 49 line.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
Wasmtime 46.0.0 before 48.0.4 and 49.0.0 before 49.0.2 contains a denial-of-service vulnerability in its wasi:http implementation that allows guests to panic the host. Guests can specify a zero between-bytes-timeout request option, which is forwarded directly to a Tokio API that panics, crashing the host embedding.
This page as .md · .json · in your agent: get_signal("CVE-2026-115382")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.