EEF-CVE-2026-115701

Dashboard / Vulnerabilities / EEF-CVE-2026-115701

EEF-CVE-2026-115701

Summary: Cowboy HTTP/1.1 Unbounded Buffering of Pipelined Data During Request Handling Enables Memory Exhaustion

Details: ## 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 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 `cowboy_req: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:process_info/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 `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.

References: https://cna.erlef.org/cves/CVE-2026-115701.html, https://github.com/ninenines/cowboy/commit/faf5594fbf74530ace90b0c46c936bdc2cf82081, https://github.com/ninenines/cowboy/commit/3a630c07e1521abf63a1b9ea080509aa1337b60d, https://hex.pm/packages/cowboy