CVE-2026-27204: Bytecodealliance Wasmtime DOS Vulnerability

CVE-2026-27204 Overview

CVE-2026-27204 is a Resource Exhaustion vulnerability in Wasmtime, a runtime for WebAssembly developed by Bytecode Alliance. The vulnerability exists in Wasmtime's implementation of WASI (WebAssembly System Interface) host interfaces, which are susceptible to guest-controlled resource exhaustion on the host system. Wasmtime failed to appropriately place limits on resource allocations requested by guest WebAssembly modules, allowing potentially malicious guests to consume excessive host resources and cause a Denial of Service condition.

Critical Impact
Malicious WebAssembly guests can exhaust host system resources through unrestricted allocation requests, leading to Denial of Service conditions affecting the host and potentially other guests running on the same Wasmtime instance.

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-27204 published to NVD
2026-02-25 - Last updated in NVD database

Technical Details for CVE-2026-27204

Vulnerability Analysis

This vulnerability (CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling) affects the core security boundary between WebAssembly guest code and the host system. Wasmtime serves as a sandboxed execution environment for WebAssembly modules, and the WASI interfaces provide controlled access to host system resources such as random number generation and resource tables.

The fundamental issue lies in the absence of appropriate resource allocation limits within the WASI host interface implementations. When guest WebAssembly modules request resources through these interfaces, the runtime did not enforce boundaries on the quantity or size of allocations, creating an exploitable attack surface for resource exhaustion.

Root Cause

The root cause stems from missing or inadequate resource limiting mechanisms in Wasmtime's WASI implementation. Specifically, the runtime lacked properly configured defaults for:

Maximum random data size that can be requested via max_random_size
Resource table capacity limits via set_max_capacity
Host call fuel consumption via set_hostcall_fuel

While configuration knobs existed to control these limits, they were not enabled by default in versions prior to 42.0.0, leaving deployments vulnerable unless explicitly hardened by embedders.

Attack Vector

The attack vector is network-accessible when Wasmtime is deployed in scenarios where untrusted WebAssembly modules can be uploaded and executed. An attacker can craft a malicious WebAssembly module that makes excessive resource allocation requests through WASI host interfaces.

The exploitation mechanism involves a guest module repeatedly calling WASI functions that allocate host resources without proper throttling. For example, requesting large amounts of random data or creating numerous entries in resource tables can rapidly exhaust available memory. The attack requires low privileges (the ability to execute a WebAssembly module) and some user interaction depending on the deployment context.

Since no verified proof-of-concept code is publicly available, the technical implementation details can be found in the GitHub Security Advisory GHSA-852m-cvvp-9p4w and the associated GitHub Issue #11552.

Detection Methods for CVE-2026-27204

Indicators of Compromise

Abnormal memory consumption by Wasmtime processes
Unusually high CPU utilization during WebAssembly module execution
System resource exhaustion events coinciding with guest module activity
Repeated WASI host calls for random data generation or resource table allocations

Detection Strategies

Monitor Wasmtime process memory and CPU consumption for anomalous spikes
Implement resource monitoring for systems hosting WebAssembly workloads
Review audit logs for unusual patterns in WebAssembly module uploads or executions
Deploy application-level monitoring to track WASI interface call frequencies

Monitoring Recommendations

Set up alerts for memory and CPU thresholds on Wasmtime host systems
Monitor for degraded service performance that may indicate resource exhaustion
Track resource table sizes and random data generation requests where possible
Implement logging for guest module lifecycle events and resource usage patterns

How to Mitigate CVE-2026-27204

Immediate Actions Required

Upgrade Wasmtime to version 24.0.6, 36.0.6, 40.0.4, 41.0.4, or 42.0.0 or later immediately
Configure resource limits using the available configuration knobs after upgrading
Review and audit all WebAssembly modules running in your environment
Implement additional host-level resource isolation if running untrusted guest code

Patch Information

The Bytecode Alliance has released patched versions addressing this vulnerability: 24.0.6, 36.0.6, 40.0.4, 41.0.4, and 42.0.0. These releases contain the fix implemented in GitHub Pull Request #12599. Note that versions prior to 42.0.0 do not enable protective defaults automatically to maintain backward compatibility, requiring manual configuration by embedders.

Starting with Wasmtime 42.0.0, the protective configuration knobs are tuned by default to prevent this issue.

Workarounds

There are no known workarounds without upgrading to a patched version
For versions before 42.0.0, embedders must explicitly configure resource limits after upgrading
Consider implementing host-level resource controls (cgroups, ulimits) as defense-in-depth

rust

// Recommended configuration for Wasmtime embedders
// See documentation for detailed configuration options:
// - max_random_size: https://docs.rs/wasmtime-wasi/latest/wasmtime_wasi/struct.WasiCtxBuilder.html#method.max_random_size
// - set_max_capacity: https://docs.rs/wasmtime/latest/wasmtime/component/struct.ResourceTable.html#method.set_max_capacity
// - set_hostcall_fuel: https://docs.rs/wasmtime/latest/wasmtime/struct.Store.html#method.set_hostcall_fuel