CVE-2026-27572: 
Rust vulnerability analysis and mitigation

CVE-2026-27572 is a Denial of Service vulnerability in Wasmtime's wasi:http/types.fields resource implementation, where adding an excessive number of HTTP header fields causes the runtime to panic rather than handling the condition gracefully. It affects the wasmtime-wasi-http crate across multiple version ranges: all versions before 24.0.6, versions 25.0.0 through 36.0.5, versions 37.0.0 through 40.0.3, and versions 41.0.0 through 41.0.3. The vulnerability was disclosed on February 24, 2026, by Bytecode Alliance contributor alexcrichton. It carries a CVSS v3.1 base score of 7.5 (High) and a CVSS v4.0 base score of 6.9 (Medium) (GitHub Advisory).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): the wasmtime-wasi-http crate backs the wasi:http/types.fields resource with an http::HeaderMap data structure that panics when it reaches its internal capacity limit, a known limitation of the underlying http crate. Because Wasmtime did not intercept or handle this panic condition, a guest WebAssembly module could trigger an uncontrolled panic in the host embedder process simply by appending a large number of header fields. The fix modifies the implementation to catch this condition and return a WebAssembly trap to the guest instead of propagating the panic to the host (GitHub Advisory, Patch Commit). New CLI knobs such as -Smax-http-fields-size were also introduced to allow embedders to set explicit limits on wasi:http fields size (Patch Commit).

Successful exploitation results in a Denial of Service condition for any application or service embedding Wasmtime with the wasmtime-wasi-http crate enabled. A malicious or compromised WebAssembly guest can crash the host Wasmtime runtime process by triggering the panic, rendering the embedding application unavailable. There is no impact on confidentiality or integrity — the vulnerability is purely an availability issue (GitHub Advisory).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time (GitHub Advisory). The EPSS score is approximately 0.062%, indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Identify a target: Locate an application or service that embeds Wasmtime with the wasmtime-wasi-http crate enabled and exposes an interface allowing guest WebAssembly modules to make or handle HTTP requests (e.g., a WASI HTTP proxy or serverless function runtime).
2. Craft a malicious WebAssembly module: Write or compile a WebAssembly component that uses the wasi:http/types.fields API to repeatedly call fields.append() or equivalent methods, adding header entries in a loop until the underlying http::HeaderMap reaches its internal capacity limit.
3. Deploy or submit the module: Submit the crafted WebAssembly module to the target embedder — for example, by uploading it as a serverless function, a proxy handler, or any other guest execution context.
4. Trigger the panic: Execute the module. When the HeaderMap capacity is exceeded, the Wasmtime host process panics and crashes, causing a Denial of Service for all users of the embedding application (GitHub Advisory, Patch Commit).

• Logs: Rust panic messages in host process logs referencing http::HeaderMap capacity overflow or wasmtime-wasi-http stack traces; abrupt process termination logs from the Wasmtime embedder.
• Process: Unexpected crash or restart of the Wasmtime host process; crash dump files generated by the OS for the embedder process.
• Network: Unusual HTTP requests or WebAssembly module submissions containing payloads designed to generate large numbers of HTTP header fields.

Embedders should upgrade to one of the patched Wasmtime releases: 24.0.6, 36.0.6, 40.0.4, 41.0.4, or 42.0.0. There are no known workarounds for unpatched versions — updating is the only remediation (GitHub Advisory). After upgrading, embedders should also consider opting into the new resource-limiting CLI knobs (e.g., -Smax-http-fields-size) to enforce explicit bounds on wasi:http fields size, as these limits are not enabled by default for backwards compatibility (Wasmtime v24.0.6 Release, Wasmtime v40.0.4 Release).

The vulnerability was noted on social media platforms including Mastodon and Bluesky by security news accounts such as The Hacker Wire shortly after disclosure. Coverage was also picked up by vulnerability aggregators including RustSec (RUSTSEC-2026-0021), INCIBE-CERT, and VulnDB. No significant independent researcher commentary or vendor statements beyond the official Bytecode Alliance advisory have been identified.