CVE-2026-111101

## Summary Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/1.1 chunked body reader of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory and CPU via a request body made of many 1-byte chunks. The chunked reader in `lib/bandit/http1/socket.ex` keeps every chunk as its own list cell and binary term until `IO.iodata_to_binary/1` joins them, and nothing limits the number of chunks. The `:length` option of `read_body/2` counts only data bytes, so tiny chunks cost far more memory than their payload: 48 MB of 1-byte chunks grew one handler process to about 500 MB and took about 6 s of CPU. The route does not need to read the body, because on keep-alive connections `ensure_completed/1` drains unread bodies through the same reader. This issue affects bandit: from 0.1.0 before 1.14.0. ## Details **1. Per-chunk accumulation.** `do_read_chunked_data!` in `lib/bandit/http1/socket.ex` collects chunks as `[body | chunk]`, adding a cons cell and a binary term for every chunk. **2. Byte-only limit.** `:length` limits data bytes, not the number of chunks, so a body of `1\r\nx\r\n` chunks becomes an 8-million-element improper list before `IO.iodata_to_binary` runs. Sending 48 MB of 1-byte chunks grew the handler heap to about 500 MB and used about 6 s of CPU. The same body as one 8 MB chunk peaked at about 16 MB and took 5 ms. **3. No body read needed.** On keep-alive connections, `ensure_completed/1` drains unread bodies through the same path. Against a Plug that never calls `read_body`, the attack used about 417 MB. ## Proof of concept 1. Run Bandit with a Plug that calls `Plug.Conn.read_body(conn, length: 1_000_000, read_length: 1_000_000)`. 2. Send `POST /` with `Transfer-Encoding: chunked` and a body of 1,000,000 chunks of `1\r\nA\r\n`, followed by `0\r\n\r\n`. 3. When `read_body` returns the 1,000,000 body bytes, the handler process holds about 48 MB and BEAM memory has grown by about 55 MB, for 6 MB sent. ## Impact An unauthenticated client can make a single HTTP/1.1 request hold many times its body size in server memory (about 48 MB for a 1 MB body in the reporter's test), and keep CPU busy while the chunks are joined. This affects any Bandit server that accepts HTTP/1.1 requests, whether or not its routes read the body. ## Workarounds From 0.7.0, a server whose clients and proxies all speak HTTP/2 can disable HTTP/1 with `http_1_options: [enabled: false]`, so that the vulnerable chunked body reader never runs.