CVE-2026-108529

## Summary Inefficient Algorithmic Complexity vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to exhaust server CPU via small SETTINGS or connection-level WINDOW_UPDATE frames. The attacker opens thousands of streams whose responses block on the connection send window, then sends cheap frames that each make the server walk the whole queue of blocked sends. In the reporter's run, with 3,000 blocked streams a single 9-byte SETTINGS frame took 133 ms to process. `do_pending_sends/2` in `lib/bandit/http2/connection.ex` retries every queued send and, before each retry, removes that entry from the queue with `List.delete/2`, so one frame costs O(n²) list operations for n blocked streams. `max_concurrent_streams` defaults to `:infinity`, so the attacker chooses n. This issue affects bandit: from 0.3.4 before 1.14.0. ## Details **1. Blocked sends** A response that outruns the connection send window is queued in `pending_sends`. With `max_concurrent_streams` defaulting to `:infinity` and no connection-level `WINDOW_UPDATE` from the client, every one of n streams ends up queued. **2. Trigger** (`lib/bandit/http2/connection.ex`) Every non-ACK SETTINGS frame and every `WINDOW_UPDATE` on stream 0 calls `do_pending_sends/2`. SETTINGS handling also sends `deliver_send_window_update` to every stream even when the window delta is 0, so unread messages pile up in the mailboxes of blocked streams. **3. Quadratic drain** `do_pending_sends/2` walks the queue and calls `List.delete/2` on the whole list before retrying each entry, putting it back at the front if the send is still blocked. One frame therefore costs O(n²) list operations, about 10^8 at n = 10,000. ## Proof of concept 1. On one HTTP/2 connection, send 3,000 requests to an endpoint with a 20 KB response body, and send no connection-level `WINDOW_UPDATE`, so the responses queue in `pending_sends`. 2. Send an empty SETTINGS frame followed by a PING. 3. Time the PING acknowledgement. In the reporter's run, the single 9-byte SETTINGS frame delayed it by 133 ms. Repeating the frame keeps the connection process busy. ## Impact An unauthenticated remote client that keeps thousands of HTTP/2 response streams blocked makes each 9-byte SETTINGS or stream-0 WINDOW_UPDATE frame cost the server quadratic CPU work. A steady trickle of such frames keeps the connection process, and the scheduler running it, busy for as long as the attacker continues. ## Workarounds From 1.9.0, bound the number of streams a client can open, for example with `http_2_options: [default_local_settings: [max_concurrent_streams: 100]]`, which bounds the work each frame can cause. From 0.7.0, disabling HTTP/2 with `http_2_options: [enabled: false]` removes the vulnerable path.