Wasmtime issues multiple advisories fixing panics and WASI resource exhaustion

Multiple Wasmtime advisories were published to the GitHub Advisory Database on Feb 24, 2026 by @alexcrichton, assigning GHSA-852m-cvvp-9p4w and registering CVE-2026-27204 and CVE-2026-27572; Wasmtime release versions 24.0.6, 36.0.6, 40.0.4, 41.0.4, and 42.0.0 are cited as containing the fixes. The advisories group several distinct implementation faults in Wasmtime’s WASI host interfaces and the wasmtime-wasi-http crate and call out that "Wasmtime’s security bug policy considers all of these behaviors a security vulnerability."

CVE-2026-27204 describes guest-controlled resource exhaustion in Wasmtime’s WASI host interfaces with affected version ranges listed as "< 24.0.6", ">= 25.0.0, < 36.0.6", ">= 37.0.0, < 40.0.4", and ">= 41.0.0, < 41.0.4." The advisory text states that "Wasmtime did not appropriately place limits on resource allocations requested by the guests. This serves as a Denial of Service vector." GitLab’s mirror reports a CVSS vector of CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:N/I:N/A:H and an impact score of 6.8 MEDIUM, while the GitHub advisory labels severity as Moderate; NVD received the CVE record from GitHub on 2/24/2026 5:16:32 PM and is listed as "undergoing analysis."

One concrete root cause fixed in the patchwork is a memory leak in poll_oneoff. Commit e2dda9ede6b35a7002e3b24e814dcd82602a4869 modifies the poll_oneoff function in crates/wasi/src/p1.rs; before the change the function would create pollable resources, store them in ResourceTable, and never remove them, allowing a guest to continuously allocate host resources until exhaustion. That change is referenced by pull request #12599, and the advisory groups that fix with broader resource-capacity changes alongside issue discussions such as bytecodealliance/wasmtime#11552.

CVE-2026-27572 covers a separate failure mode in the wasmtime-wasi-http crate: "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." The advisory explains the crate’s backing data structure "panics when it reaches excessive capacity and this condition was not handled gracefully in Wasmtime." The patched behavior in the listed releases returns a trap to the guest instead of panicking the host.

Wasmtime’s advisories and mirrored pages emphasize configuration knobs embedders can use immediately: Store::set_hostcall_fuel, ResourceTable::set_max_capacity, and WasiCtxBuilder::max_random_size. Advisories warn that "There are no known workarounds for this issue without upgrading. Embedders are recommended to upgrade and configure their embeddings as necessary to prevent possibly-malicious guests from triggering this issue." The Bytecode Alliance notes that Wasmtime 42.0.0-and-later will have these knobs tuned by default to reduce exposure.

For maintainers and embedders, the actionable steps are clear: upgrade to the patched Wasmtime releases (24.0.6, 36.0.6, 40.0.4, 41.0.4, or 42.0.0), review ResourceTable limits and Store::set_hostcall_fuel settings in your embedding, and inspect PR #12599 and commit e2dda9e... in crates/wasi/src/p1.rs for the poll_oneoff fix. The advisories group multiple independent issues under CVE-2026-27204, so verify each embedding’s resource knobs rather than assuming a single patch fully eliminates all exhaustion vectors.