CVE-2026-27572: Bytecodealliance Wasmtime DOS Vulnerability

CVE-2026-27572 Overview

CVE-2026-27572 is a Denial of Service vulnerability in Wasmtime, a standalone runtime for WebAssembly. The vulnerability exists in Wasmtime's implementation of the wasi:http/types.fields resource within the wasmtime-wasi-http crate. When a guest module adds too many fields to the set of HTTP headers, the underlying data structure panics due to reaching excessive capacity. This unhandled panic condition can be exploited by malicious WebAssembly modules to crash the Wasmtime runtime, causing service disruption for embedders.

Critical Impact
Malicious WebAssembly guests can trigger a panic in the Wasmtime runtime by adding excessive HTTP header fields, causing complete service denial for all hosted applications.

Affected Products

Bytecodealliance Wasmtime versions prior to 24.0.6
Bytecodealliance Wasmtime versions prior to 36.0.6
Bytecodealliance Wasmtime versions prior to 40.0.4, 41.0.4, and 42.0.0

Discovery Timeline

2026-02-24 - CVE-2026-27572 published to NVD
2026-02-25 - Last updated in NVD database

Technical Details for CVE-2026-27572

Vulnerability Analysis

This vulnerability is classified as CWE-770 (Allocation of Resources Without Limits or Throttling). The wasmtime-wasi-http crate provides WebAssembly System Interface (WASI) HTTP functionality, allowing guest modules to interact with HTTP headers through the wasi:http/types.fields resource. The underlying implementation uses a data structure that has inherent capacity limitations, as documented in the HTTP Header Limitations Documentation.

When a WebAssembly guest module repeatedly adds fields to an HTTP headers collection, the backing data structure can reach its maximum capacity. In vulnerable versions, this condition triggers an uncontrolled panic rather than returning an error to the guest. Since panics in WASI implementations propagate to the embedder's runtime, this allows untrusted guest code to cause a complete denial of service.

Root Cause

The root cause is improper error handling in the wasmtime-wasi-http crate when the HTTP header fields collection exceeds its capacity limits. The Rust http crate's header map implementation panics when it cannot allocate additional space for headers, and Wasmtime did not catch or handle this panic condition gracefully. This violates Wasmtime's security model, which requires that guest code should never be able to crash the host runtime.

Attack Vector

An attacker controlling a WebAssembly module executed by Wasmtime can exploit this vulnerability by:

Creating a wasi:http/types.fields resource (HTTP headers or trailers)
Repeatedly calling methods to add header fields to the collection
Continuing until the underlying data structure reaches capacity
Triggering an unhandled panic that crashes the Wasmtime runtime

The attack requires network access to submit a malicious WebAssembly module and low privileges to execute guest code, though some preconditions must be met for successful exploitation.

rust

// Security patch adding resource limits configuration
// Source: https://github.com/bytecodealliance/wasmtime/commit/301dc7162cca51def19131019af1187f45901c0a

         pub keyvalue_in_memory_data: Vec<KeyValuePair>,
         /// Enable support for WASIp3 APIs.
         pub p3: Option<bool>,
+        /// Maximum resources the guest is allowed to create simultaneously.
+        pub max_resources: Option<usize>,
+        /// Fuel to use for all hostcalls to limit guest<->host data transfer.
+        pub hostcall_fuel: Option<usize>,
+        /// Maximum value, in bytes, for a wasi-random 0.2
+        /// `get{,-insecure}-random-bytes` `len` parameter. Calls with a value
+        /// exceeding this limit will trap.
+        pub max_random_size: Option<u64>,
+        /// Maximum value, in bytes, for the contents of a wasi-http 0.2
+        /// `fields` resource (aka `headers` and `trailers`). `fields` methods
+        /// which cause the contents to exceed this size limit will trap.
+        pub max_http_fields_size: Option<usize>,
     }

     enum Wasi {

Detection Methods for CVE-2026-27572

Indicators of Compromise

Unexpected Wasmtime runtime crashes with panic stack traces referencing wasmtime-wasi-http or header field operations
WebAssembly modules making unusually high numbers of HTTP header field additions
Service disruptions correlated with specific guest module executions
Log entries showing panics in the http crate's header map implementation

Detection Strategies

Monitor Wasmtime processes for unexpected terminations and panic conditions
Implement logging around WASI HTTP operations to track header field creation patterns
Review WebAssembly modules for suspicious patterns of excessive header manipulation
Set up alerting for runtime crashes in production Wasmtime deployments

Monitoring Recommendations

Configure process monitoring to detect and alert on Wasmtime runtime panics
Implement application-level logging for WASI HTTP resource usage metrics
Track the number of header fields created per guest module session
Enable crash dump collection to analyze root causes of runtime terminations

How to Mitigate CVE-2026-27572

Immediate Actions Required

Upgrade Wasmtime to version 24.0.6, 36.0.6, 40.0.4, 41.0.4, or 42.0.0 depending on your current major version
Review and audit any untrusted WebAssembly modules currently deployed
Implement process isolation and restart mechanisms to limit DoS impact
Consider temporarily disabling WASI HTTP functionality for untrusted guests if upgrade is delayed

Patch Information

Bytecode Alliance has released patched versions that properly handle the capacity limit condition by returning a trap to the guest instead of panicking. The fix introduces new configuration options including max_http_fields_size to limit the maximum bytes allowed in a fields resource. The security patch is available in commit 301dc7162cca51def19131019af1187f45901c0a.

Patched releases are available:

For complete details, see the GitHub Security Advisory GHSA-243v-98vx-264h.

Workarounds

There are no known workarounds for this vulnerability at this time
Embedders are strongly encouraged to upgrade to a patched version of Wasmtime
Consider running Wasmtime instances in isolated containers with automatic restart policies to limit DoS impact
Implement external rate limiting on WebAssembly module submissions from untrusted sources

bash

# Update Wasmtime to patched version using Cargo
cargo update -p wasmtime@41.0.3 --precise 41.0.4

# Alternatively, update Cargo.toml dependency
# wasmtime = "41.0.4"  # or 24.0.6, 36.0.6, 40.0.4, 42.0.0

# Verify installed version
cargo tree -i wasmtime | head -n 1