EEF-CVE-2026-115701: Cowboy HTTP/1.1 Unbounded Buffering of Pipelined Data During Request Handling Enables Memory Exhaustion

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, cowboyhttp:parse/2 in src/cowboyhttp.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: maxrequestlinelength, maxheaders and the other parser limits only take effect once the handler returns and parsing resumes, and the only timer in this state is idletimeout (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 cowboyhttp finishes reading a request it moves the parser to the psnextrequest state while the stream for that request is still alive. The connection process keeps the socket in active mode (setoptsactive/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 instate=psnextrequest with a live #stream{} returns straight to beforeloop/1 with the enlarged buffer, deferring all parsing until the current stream stops. The parser limits (maxrequestlinelength, maxheadernamelength, maxheadervaluelength, maxheaders) are enforced only by the parsing clauses that run after that point, and maxskipbodylength 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 idletimeout (default 60 seconds), and settimeout/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

1. Start a cowboy HTTP/1.1 listener with a handler that takes time to reply, for example one that sleeps 20 seconds before calling cowboyreq:reply/4. 2. Open one TCP connection and send a complete GET / HTTP/1.1 request with a Host header. 3. While the handler is still running, keep writing arbitrary bytes on the same connection, for example 300 one-megabyte chunks. 4. Inspect the connection process with erlang:processinfo/2 while the handler runs: its referenced binaries grow by the amount sent and erlang:memory(binary) rises by the same amount. No parser limit or timeout interrupts the transfer. 5. 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 cowboyloop, streamed responses via cowboyreq:streamreply/3, or slow backend calls, give an attacker the time to buffer significant memory. HTTP/2 connections are not affected.