CVE-2026-115381 in Wasmtime
Summary
by MITRE • 10/23/2026
Wasmtime before 36.0.17, 37.0.0 before 48.0.4, and 49.0.0 before 49.0.2 contains an unbounded memory allocation in the wasmtime-wasi WASIp2 write-zeroes method of SinkOutputStream, the default stream used when stdout/stderr are not configured. A malicious WebAssembly guest can request huge zero-filled writes, exhausting host memory and causing denial of service.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/23/2026
The vulnerability identified involves a critical resource management flaw within the Wasmtime runtime environment, specifically affecting versions prior to 36.0.17, 37.0.0 through 48.0.4, and 49.0.0 through 49.0.2. This issue centers on an unbounded memory allocation mechanism located in the wasmtime-wasi implementation of the WASIp2 write-zeroes method within the SinkOutputStream class. The SinkOutputStream serves as the default stream for handling standard output and standard error when these are not explicitly configured by the host application, making it a frequently utilized component during typical WebAssembly guest execution scenarios.
From a technical perspective, the core deficiency lies in the lack of input validation regarding the size parameter passed to the write-zeroes operation. When a malicious WebAssembly guest invokes this method with an excessively large value for the number of bytes to be written as zeros, the runtime attempts to allocate that exact amount of memory on the host system without imposing any upper limits or sanity checks. This behavior deviates from secure coding practices which dictate that all external inputs, particularly those defining resource consumption such as buffer sizes, must be strictly bounded against known safe thresholds or available system resources before allocation occurs.
The operational impact of this flaw is a severe denial of service condition for the host environment. By requesting huge zero-filled writes, an attacker can rapidly exhaust the memory capacity allocated to the Wasmtime process or even the entire host machine if limits are not enforced at that level. This leads to out-of-memory errors, application crashes, and potential instability in surrounding services depending on how the runtime handles such failures. Since this affects default streams, it is particularly dangerous as it may be triggered by seemingly benign operations that inadvertently escalate into malicious resource exhaustion attacks.
This vulnerability aligns with CWE-789: Uncontrolled Memory Allocation, which describes situations where software allocates memory based on user input without proper validation of the size or range. Furthermore, in the context of attack tactics and techniques, this flaw facilitates Denial of Service via Resource Exhaustion, a common vector used to disrupt availability by consuming critical system resources such as CPU cycles, bandwidth, or memory. The ATT&CK framework categorizes similar behaviors under resource hijacking techniques where adversaries leverage legitimate processes to consume excessive resources for disruptive purposes.
To mitigate this risk, organizations utilizing Wasmtime must upgrade immediately to version 36.0.17 and later, 48.0.4 and later, or 49.0.2 and later, as these releases contain the necessary patches to enforce proper bounds checking on memory allocation requests within the WASIp2 implementation. Additionally, developers should implement host-side resource limits using Wasmtime's configuration options to cap maximum linear memory size and other runtime parameters. This defense-in-depth approach ensures that even if a vulnerability exists in the guest code or library logic, the host environment remains protected from catastrophic resource exhaustion by enforcing strict quotas on what any single WebAssembly module can consume.