Live › vulnerability › CVE-2026-115388
Go to dashboardWasmtime's wasi-http implementation does not enforce the check-write limit for outgoing HTTP bodies under WASIp2, so oversized writes succeed instead of trapping. A malicious guest module can use this to hold host memory for the lifetime of its store and exhaust the host's memory.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Only hosts that run untrusted or third-party WebAssembly guests with the WASIp2 outgoing HTTP interface are exposed, because the guest must be able to write to outgoing-body resources. Teams running only their own trusted guest modules, or not using wasi-http at all, can deprioritize this.
No product ranges from the sources yet.
wasmtime --version and compare against the affected ranges: before 36.0.16, 37.0.0 through before 48.0.3, and 49.0.0 through before 49.0.1.wasmtime-wasi-http in those ranges.36.0.16, 48.0.3, or 49.0.1, matching your release line.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
wasmtime-wasi-http in Wasmtime before 36.0.16, 37.0.0 before 48.0.3, and 49.0.0 before 49.0.1 does not enforce the wasi:io/streams check-write allowance for WASIp2 outgoing HTTP bodies, so oversized writes succeed instead of trapping. A malicious guest can pass large buffers to write on outgoing-body resources, holding host allocations for the store's lifetime and exhausting host memory.
This page as .md · .json · in your agent: get_signal("CVE-2026-115388")
NVD data is provided by NIST and is public domain · EPSS scores by FIRST, used with attribution. Posts quoted belong to their authors.