EEF-CVE-2026-116078

Dashboard / Vulnerabilities / EEF-CVE-2026-116078

EEF-CVE-2026-116078

Summary: HTTP/2 request bodies made of 1-byte DATA frames amplify memory use in Bandit

Details: ## Summary Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 request body reader of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via a request body sent as many 1-byte DATA frames. `do_read_data/5` in `lib/bandit/http2/stream.ex` keeps every DATA frame payload as its own list element until the read returns. The `:length` option of `read_body/2` counts body bytes, not frames, so a body of 1-byte frames costs a list cell and a binary term per byte. Interleaving the frames across up to 500 concurrent streams per connection keeps each stream consuming its frames as they arrive; in the reporter's test, 100 streams held 25 to 40 MiB of stream process memory for 5 MB sent. Only routes whose Plug reads the request body are affected, which includes any route behind `Plug.Parsers`. This issue affects bandit: from 0.3.1 before 1.14.1. ## Details **1. Per-frame accumulation.** `Bandit.HTTP2.Stream.read_data/2` calls `do_read_data/5` in `lib/bandit/http2/stream.ex`, which prepends each `{:data, data, stream}` payload to a list (`[data | acc]`) and reverses it when the read returns. Each 1-byte payload arrives as a separate message from the connection process, so the stream heap holds a cons cell and a heap binary per frame. **2. Byte-only limit.** `:length` (default 8,000,000) is decremented by `byte_size(data)` and bounds body bytes, not the number of frames. A read ends at `:length` or at its `read_timeout` deadline, and 1-byte frames add no measurable deadline credit, so a stream holds whatever arrives within the deadline at the per-frame overhead ratio. `Plug.Parsers` answers 413 on `:more`, and the client continues on a new stream. **3. Interleaving defeats connection buffering.** The connection buffers DATA for a stream only once that stream has 16 messages outstanding. A stream that keeps up never reaches this, and interleaving one frame per stream per round across many streams keeps every stream under it regardless of TCP segment size. **4. Measurements on 1.14.0.** 100 streams of 5,000 interleaved 1-byte frames (5,000,000 bytes on the wire, 488 KiB of body) held 25 to 40 MiB in stream processes, with empty mailboxes. One stream of 60,000 frames sent one per write held 2 to 4 MiB for 58 KiB of body. ## Proof of concept 1. Run Bandit with HTTP/2 enabled and a Plug that calls `Plug.Conn.read_body(conn)` with default options. 2. Open an h2c connection, exchange prefaces and SETTINGS, and send HEADERS for `POST /` without END_STREAM on 100 streams (IDs 1, 3, 5, ...). 3. Send 5,000 rounds of 1-byte DATA frames, one frame per stream per round, batched into writes of 100 frames. 4. Three seconds later, while the reads are still open, the 100 stream processes hold 25 to 40 MiB combined with empty mailboxes, for about 5 MB sent. ## Impact An unauthenticated client can make a Bandit HTTP/2 server hold about 5 to 8 times the bytes it sends in stream process memory, across up to 500 streams per connection and many connections, for as long as each body read runs. This affects any Bandit server with HTTP/2 enabled whose routes read request bodies, which `Plug.Parsers` does for POST, PUT and PATCH. ## Workarounds From 0.7.0, disable HTTP/2 with `http_2_options: [enabled: false]`, so that the vulnerable body reader never runs.

References: https://github.com/mtrudel/bandit/security/advisories/GHSA-pxjf-g536-7r93, https://cna.erlef.org/cves/CVE-2026-116078.html, https://github.com/mtrudel/bandit/commit/c8dc1e97050cf359f61ed6cdd110f3cdaf1d6f5f, https://github.com/mtrudel/bandit/commit/327bb02ff84171237e1aeff787930debd16155ee, https://hex.pm/packages/bandit