CVE-2026-115391 in Wasmtime
Summary
by MITRE • 10/22/2026
Wasmtime 46.0.0 before 46.0.3 and 47.0.0 before 47.0.4 contains an uncontrolled resource allocation vulnerability in its WASIp3 implementation that buffers guest-specified-length writes on the host without limit. Malicious guests can offer large buffers to WASIp3 file or HTTP write streams, causing the host to copy and buffer all bytes, bounded only by guest linear memory, exhausting host memory.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in Wasmtime versions 46.0.0 through 46.0.2 and 47.0.0 through 47.0.3 represents a critical uncontrolled resource allocation flaw within the WASIp3 implementation, specifically affecting file system operations and HTTP write streams. This security defect stems from an architectural oversight where the host environment fails to enforce limits on buffer sizes provided by guest applications during write operations. In standard WebAssembly execution models, guests operate within isolated linear memory spaces that are strictly bounded, preventing them from directly accessing or corrupting host resources beyond their allocated slice. However, in this specific implementation of WASIp3, when a guest application initiates a write to a file descriptor or an HTTP stream, the runtime accepts buffers specified by the guest without validating whether those buffer sizes exceed reasonable thresholds for resource consumption on the host side.
The technical mechanism of exploitation relies on the ability of malicious guests to allocate large data structures within their own linear memory and then invoke WASIp3 functions that trigger bulk writes from these oversized buffers to the host system. Because the runtime does not impose a cap on the amount of data copied during this process, it proceeds to copy every byte specified by the guest length parameter into host-side buffers or temporary storage areas intended for processing the write operation. This behavior effectively bypasses the protective boundaries typically enforced by WebAssembly sandboxes, allowing the guest application to dictate the volume of memory resources consumed by the host runtime engine itself rather than just its own isolated environment.
The operational impact of this vulnerability is severe, primarily manifesting as a denial-of-service condition through resource exhaustion. By repeatedly or continuously sending large buffers for writing, an attacker can force the Wasmtime host process to allocate and retain vast amounts of memory until system limits are reached. This leads to significant performance degradation, eventual crash of the hosting application due out-of-memory errors, or complete unavailability of services relying on the WebAssembly runtime. In cloud-native environments where multiple tenants might share underlying infrastructure running Wasmtime instances, such an attack could potentially affect other workloads if resource isolation is not strictly enforced at a higher orchestration layer, thereby compromising availability and reliability for all users sharing that host node.
This flaw aligns with Common Weakness Enumeration (CWE) category CWE-789: Uncontrolled Memory Allocation, which describes situations where software allocates memory without proper bounds checking or size validation relative to available resources. From a threat modeling perspective consistent with the MITRE ATT&CK framework, this vulnerability facilitates resource exhaustion attacks that can be categorized under techniques aimed at disrupting service availability rather than gaining unauthorized access to data. The lack of input validation regarding buffer sizes in system-level API calls like file writes and HTTP stream handling represents a fundamental failure in secure coding practices for sandboxed environments where trust boundaries must be rigorously maintained between guest code and host resources.
Mitigation strategies require immediate updates to the Wasmtime runtime environment, specifically upgrading to version 46.0.3 or later, which includes patches that enforce strict limits on buffer sizes during WASIp3 operations. For organizations unable to upgrade immediately due to dependency constraints, implementing network-level rate limiting and request size restrictions at the proxy layer preceding the WebAssembly host can provide a partial defense in depth by preventing excessively large payloads from reaching the vulnerable runtime functions additionally deploying resource quotas and memory monitoring tools allows for early detection of anomalous memory consumption patterns indicative of such exploitation attempts. Long-term remediation should involve enforcing stricter input validation policies within any custom WASIp3 implementations or wrappers, ensuring that all buffer lengths are validated against predefined maximum thresholds before being passed to underlying system calls.