PT-2026-137922
CVE-2026-115701
·
Published
2026-11-06
·
Updated
2026-11-06
Description by
CVSS 4.0
8.2
HighMetricsAV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Summary
Allocation of Resources Without Limits or Throttling vulnerability in ninenines cowboy allows an unauthenticated remote attacker to exhaust connection process memory over HTTP/1.1.
Once a request has been received in full and its handler is still running,
cowboy http:parse/2 in src/cowboy http.erl appends every further byte that arrives on the keep-alive connection to the connection buffer and returns to the receive loop without parsing it. The socket stays in active mode and no limit applies to this buffer: max request line length, max headers and the other parser limits only take effect once the handler returns and parsing resumes, and the only timer in this state is idle timeout (default 60 seconds), which is reset on every received chunk. A client can therefore send an arbitrary amount of data on one connection for as long as the handler runs, and a few connections to an endpoint that holds requests open can drive the Erlang VM into out-of-memory conditions.This issue affects cowboy: from 2.18.0 onward.
Details
1. Request completes, handler runs. When
cowboy http finishes reading a request it moves the parser to the ps next request state while the stream for that request is still alive. The connection process keeps the socket in active mode (setopts active/1 re-arms {active, N} whenever a passive notification arrives), so the VM continues to deliver socket data to the process.2. Data is appended, never parsed. Each incoming chunk reaches
loop/1, which concatenates it onto the connection buffer and calls parse/2. The parse/2 clause for in state=ps next request with a live #stream{} returns straight to before loop/1 with the enlarged buffer, deferring all parsing until the current stream stops. The parser limits (max request line length, max header name length, max header value length, max headers) are enforced only by the parsing clauses that run after that point, and max skip body length only covers an unread body of the current request, not bytes after it.3. No timer bounds the window. While a stream is live the connection runs on
idle timeout (default 60 seconds), and set timeout/2 resets it on every received chunk. The attacker therefore keeps the window open by continuing to send. Only the handler finishing ends it, at which point parsing resumes, the buffered bytes fail the request-line checks, and the connection closes with a 4xx response. By then the data has been held for the full handler duration.4. Introduction. The behaviour arrived with the change that removed concurrent processing of pipelined HTTP/1.1 requests (first shipped in 2.18.0). Earlier releases parsed pipelined data as it arrived, so excess bytes hit the request-line limit immediately and the connection was closed with
414 Request-URI Too Long before any significant amount was buffered. The introducing commit describes the intended behaviour as stopping reads from the socket until the stream stops, but the code keeps the socket active and buffers instead.Proof of concept
- Start a cowboy HTTP/1.1 listener with a handler that takes time to reply, for example one that sleeps 20 seconds before calling
cowboy req:reply/4. - Open one TCP connection and send a complete
GET / HTTP/1.1request with aHostheader. - While the handler is still running, keep writing arbitrary bytes on the same connection, for example 300 one-megabyte chunks.
- Inspect the connection process with
erlang:process info/2while the handler runs: its referenced binaries grow by the amount sent anderlang:memory(binary)rises by the same amount. No parser limit or timeout interrupts the transfer. - When the handler replies, the client still receives the
200 OK; only afterwards does the buffered data get parsed and rejected.
On 2.16.1 and 2.17.0 step 3 is cut short: the server answers
414 Request-URI Too Long with connection: close as soon as the first chunk arrives and holds nothing.Impact
An unauthenticated remote client can make one connection process hold an arbitrary amount of memory by sending data after a request while its handler runs. A few such connections to an endpoint that holds requests open exhaust node memory and terminate every connection served by that node.
Configurations
The amount of data buffered scales with how long the current handler keeps the connection busy. Any HTTP/1.1 endpoint exposes a window, but deployments with handlers that hold a request open, such as long polling with
cowboy loop, streamed responses via cowboy req:stream reply/3, or slow backend calls, give an attacker the time to buffer significant memory. HTTP/2 connections are not affected. Found an issue in the description? Have something to add? Feel free to write us 👾