bandit

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.

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.

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.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to grow per-connection memory and CPU cost without bound via a large SETTINGS_HEADER_TABLE_SIZE. Bandit resizes its HPACK encoder table to whatever size the client advertises, up to 2^32-1 bytes, and indexes response headers into it. Because responses carry distinct values such as date or content-length, nothing is evicted and the table grows with every response for the life of the connection, while each lookup scans it linearly.

The SETTINGS handling in Bandit.HTTP2.Connection (lib/bandit/http2/connection.ex) passes remote_settings.header_table_size to HPAX.resize/2 with no server-side cap, and encode_headers encodes every response header as :store. Serving N responses on one connection therefore costs O(N²) CPU in the connection process.

This issue affects bandit: from 0.3.6 before 1.14.0.

Details

1. Table size (lib/bandit/http2/connection.ex)

On every SETTINGS frame, Bandit.HTTP2.Connection passes the peer's SETTINGS_HEADER_TABLE_SIZE straight to HPAX.resize/2 for the encoder table, accepting values up to 2^32-1. No server-side limit is applied.

2. Indexing

encode_headers encodes every response header as :store, adding it to the dynamic table. Headers whose values differ per response (date, content-length, set-cookie, x-request-id, a reflected location) produce new entries, and with a limit of about 4 GB none are evicted.

3. Cost

HPAX's lookup_by_header scans the table linearly for each header it encodes, so every response costs more than the one before it. Serving N responses on one connection costs O(N²) CPU in the connection process, and the table holds every entry for as long as the connection stays open.

Proof of concept

1. Open an HTTP/2 connection and advertise a SETTINGS_HEADER_TABLE_SIZE of 4294967295 in the initial SETTINGS frame.
2. Send cheap requests one after another on that connection, each to an endpoint whose response carries a header value that changes per request.
3. Time the round trips. In the reporter's run, the last 1,000 of 12,000 requests took 3.68 times as long as the first 1,000.

Impact

An unauthenticated remote client that keeps an HTTP/2 connection busy with cheap requests makes every response on it progressively more expensive, because the encoder table it enlarged never shrinks. Holding several such connections open ties up server CPU and memory for as long as the attacker keeps them alive.

Workarounds

From 0.7.0, cap the requests one HTTP/2 connection may serve, for example with http_2_options: [max_requests: 1000], so each connection and its encoder table is closed before the cost grows large. Alternatively, disable HTTP/2 with http_2_options: [enabled: false].

Summary

Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via a small HPACK-compressed HEADERS block. The block stores one large cookie value in the HPACK dynamic table and then references it tens of thousands of times with 1-byte indexed fields. In the reporter's run, a 49 KB block made a server with default settings allocate a 183 MB cookie binary before any application code ran, and every concurrent stream can repeat the cost.

Bandit.HTTP2.Connection caps only the compressed block (max_header_block_size), and its check of the decoded list against max_header_list_size never fires because that setting defaults to :infinity. combine_cookie_crumbs/1 in lib/bandit/http2/stream.ex then joins every crumb into one binary.

This issue affects bandit: from 0.3.3 before 1.14.0.

Details

1. Compression

The attacker's header block, split across HEADERS and CONTINUATION frames, stays under the 50,000-byte max_header_block_size. It inserts one 4,058-byte cookie into the 4,096-byte dynamic table, the largest value that fits, then references it about 45,000 times with 1-byte indexed representations. HPAX.decode returns a list whose entries all point at the same binary, so decoding itself stays cheap.

2. Missing decoded limit (lib/bandit/http2/connection.ex, lib/bandit/http2/settings.ex)

After decoding, the connection compares header_list_size(headers) against local_settings.max_header_list_size. That setting defaults to :infinity, and in Erlang term order every integer sorts below an atom, so the comparison never rejects a list. The limit is enforced only when an operator sets it.

3. Expansion (lib/bandit/http2/stream.ex)

read_headers calls combine_cookie_crumbs/1, which joins every crumb with Enum.map_join/3 into a single binary of about 183 MB before Plug.call/2 runs. max_concurrent_streams also defaults to :infinity, so N streams allocate N times as much.

Proof of concept

1. Against a Bandit server with default HTTP/2 settings, build an HPACK header block with the request pseudo-headers plus a 4,058-byte cookie stored in the dynamic table and then referenced about 45,000 times with indexed representations. The block is about 49 KB.
2. Send it on one stream as a HEADERS frame followed by CONTINUATION frames of at most 16,384 bytes, with END_HEADERS on the last.
3. The request reaches the plug with a cookie header of about 183 MB, and VM memory grows by about the same amount. Repeat on further streams to multiply it.

Impact

An unauthenticated remote client can make any Bandit server with default HTTP/2 settings allocate a cookie binary thousands of times larger than the header block it sent, before any application code runs. Repeating it across concurrent streams exhausts the BEAM node's memory, taking down every application on the node.

Workarounds

On 1.12.2 and later, set a finite decoded header list limit, for example http_2_options: [default_local_settings: [max_header_list_size: 65_536]], which resets the stream before the cookie crumbs are joined. From 0.7.0, disabling HTTP/2 with http_2_options: [enabled: false] removes the vulnerable path.

Summary

Improper Cleanup on Thrown Exception vulnerability in the HTTP/2 handler of mtrudel bandit allows an unauthenticated remote attacker to bypass per-connection resource limits via a single TCP write that carries several frames, one of which raises a stream error.

When a frame raises StreamError partway through a chunk, Bandit.HTTP2.Handler.handle_data/3 sends RST_STREAM and continues with the connection state from before the chunk, dropping the rest of it. Streams opened by earlier frames in the chunk keep running their Plug calls, but the stream counts, last_stream_id, the rapid-reset timestamps, the HPACK decoder state and the buffer roll back, so max_concurrent_streams, max_requests and the rapid-reset limiter never see those streams. A client that sends one HEADERS frame more than max_concurrent_streams in each write has the extra refused and the others forgotten: with a limit of 10, five such writes run 50 Plug calls at once.

This issue affects bandit: from 1.9.0 before 1.14.0.

Details

1. Function-level rescue. Bandit.HTTP2.Handler.handle_data/3 in lib/bandit/http2/handler.ex deserializes every frame in a TCP chunk inside an Enum.reduce_while/3 and wraps the whole function in a rescue. Inside that rescue, state is the original function argument, not the reduce_while accumulator.

2. Rollback on StreamError. When Bandit.HTTP2.Connection.handle_frame/3 raises StreamError partway through the chunk, rescue_stream_error/3 sends RST_STREAM and returns {:continue, state} with the connection as it was before the chunk. The rest of the chunk is dropped.

3. Lost bookkeeping. Frames already handled keep their side effects: their stream processes are running the Plug. But the stream counts, last_stream_id, reset_stream_timestamps, recv_hpack_state and buffer are rolled back, so max_concurrent_streams, max_requests and the rapid-reset limiter no longer count those streams. The same rollback drops HPACK table updates, which can mix up headers between requests, misaligns frame parsing, and sends a stale last_stream_id in GOAWAY.

Proof of concept

1. Run Bandit with a Plug that blocks until released and with http_2_options: [default_local_settings: [max_concurrent_streams: 10]].
2. Open an HTTP/2 connection with prior knowledge and complete the SETTINGS exchange.
3. In one TCP write, send 11 HEADERS frames with END_HEADERS and END_STREAM on streams 1, 3, ..., 21, each carrying a header block encoded without indexing. The eleventh is refused with REFUSED_STREAM, and the server forgets the ten streams before it.
4. Send the same write four more times. The Plug runs 50 times concurrently against a limit of 10.

Impact

An unauthenticated client can run more concurrent Plug calls on one HTTP/2 connection than the configured max_concurrent_streams allows (five times the limit in the reporter's test), tying up the server processes, CPU and memory the limit is meant to cap. Servers that serve HTTP/2 with a finite max_concurrent_streams are affected.

Workarounds

Disable HTTP/2 with http_2_options: [enabled: false], so that the vulnerable HTTP/2 handler never runs.

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.

Summary

Inefficient Algorithmic Complexity vulnerability in the header integer parser of mtrudel bandit allows an unauthenticated remote attacker to consume server CPU via a content-length value or a Host or :authority port made of thousands of digits.

Bandit.Headers.parse_integer/2 in lib/bandit/headers.ex builds the number one digit at a time with no limit on the digit count, allocating a new bignum at each step, so one value costs time quadratic in its length. It runs on raw request input over HTTP/1 and HTTP/2, before any range check. Over HTTP/2, a 4,000-digit value can be stored once in the HPACK dynamic table and re-sent on each new stream for about one byte: 124 KB of traffic kept the server busy for 27.9 s.

This issue affects bandit: from 1.0.0-pre.7 before 1.14.0.

Details

1. Unbounded digit loop. Bandit.Headers.parse_integer/2 in lib/bandit/headers.ex builds the number with total * 10 + digit - ?0 and has no limit on the digit count. Each step allocates a new bignum, so parsing one value costs O(n²). On OTP 28, 10,000 digits take about 10 ms, 50,000 about 250 ms and 80,000 about 560 ms, where String.to_integer/1 handles the same inputs in 1 to 3 ms.

2. Reached on raw input. It is called from get_content_length/1 and parse_hostlike_header!/1 on raw request input, before any range check. An all-digit content-length is returned as {:ok, huge_int}, and the is_port_number guard only runs after the whole number is built.

3. HPACK amplification. Over HTTP/2, a 4,000-digit value (about 1.1 ms to parse) can be stored once in the HPACK dynamic table and then re-sent on each new stream for about one byte.

Proof of concept

1. Run Bandit with any Plug.
2. Open an HTTP/2 connection with prior knowledge and complete the SETTINGS exchange.
3. In one write, send 5,000 HEADERS frames for POST / on new streams, each carrying a content-length of 4,000 9 digits encoded with HPACK indexing, so that every frame after the first refers to the stored value.
4. The 124,003 bytes take 27.9 s to process before all 5,000 requests reach the Plug.

Impact

An unauthenticated client can make the server spend CPU time out of all proportion to the traffic it sends (27.9 s for 124 KB in the reporter's test). This affects any Bandit server reachable by untrusted clients over HTTP/1 or HTTP/2, with no special configuration.

Summary

Client-Side Enforcement of Server-Side Security vulnerability in the WebSocket connection handling of mtrudel bandit allows a remote client to keep running WebSock handler code after the server has stopped its connection, via data frames sent after ignoring the server's Close frame.

When a WebSock callback returns {:stop, ...}, Bandit.WebSocket.Connection calls terminate/2, sends Close and shuts down the write side, but keeps the connection process running in a :closing state. handle_frame/3 and handle_info/3 never check that state, so later frames still reach handle_in/2 and later messages reach handle_info/2, with the state from the stop tuple, until the client sends Close, TCP drops or the idle timeout fires. A client refused in init/1 after a failed token check could still run an admin-only action.

This issue affects bandit: from 0.5.1 before 1.14.0.

Details

1. Stop without close. In Bandit.WebSocket.Connection, do_stop/4 calls terminate/2, sends the Close frame and runs shutdown(:write). It then returns {:continue, %{connection | state: :closing}}, so Bandit.WebSocket.Handler keeps the process alive.

2. No state check. handle_frame/3 and handle_info/3 never check connection.state. Every later data frame still reaches handle_in/2, and every later message still reaches handle_info/2, with the state from the stop tuple.

3. Client-controlled lifetime. The connection ends only when the client sends Close, TCP drops, or the idle timeout fires, and each client frame resets that timeout. All stops through do_stop are affected: {:stop, :normal, ...}, {:stop, {:shutdown, :disconnected}, ...} and {:stop, {:shutdown, :restart}, ...}, which is what Phoenix's :socket_drain returns. A banned user who was kicked kept posting for longer than the idle timeout.

Proof of concept

1. Serve a WebSock whose init/1 returns {:stop, :normal, {4401, "unauthorized"}, state} for a wrong token, and whose handle_in/2 runs an admin-only delete_all_users action when user_id is admin.
2. Upgrade with ?user_id=admin&token=wrong. The server calls terminate/2 and sends a Close frame with code 4401.
3. Ignore the Close frame and send a masked text frame delete_all_users.
4. handle_in/2 runs delete_all_users as admin.

Impact

A remote client that ignores the Close frame can keep invoking a WebSock application's handlers after the application refused or ended its session, bypassing an authorization check in init/1 or a kick or ban. This affects WebSock applications that rely on {:stop, ...} to end a session.

Workarounds

Mark the WebSock state as stopped whenever a callback returns {:stop, ...}, and have handle_in/2 and handle_info/2 return {:ok, state} without acting while that mark is set.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in the WebSocket fragment reassembly of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via a fragmented message made of many 1-byte continuation frames.

Bandit.WebSocket.Connection checks max_fragmented_message_size against the payload bytes received, but keeps every non-final continuation frame as a new list cell around its own binary, and nothing limits the number of fragments. A 1-byte fragment costs 7 bytes on the wire but about 150 to 170 bytes of server memory, so one connection can hold about 150 times the configured limit, roughly 1.2 to 1.4 GB at the default 8 MB. Ping frames between fragments keep the connection alive past the idle timeout.

This issue affects bandit: from 1.11.0 before 1.14.0.

Details

1. Byte-only limit. In Bandit.WebSocket.Connection (lib/bandit/websocket/connection.ex), the fragment limit is checked against fragment_size, which only adds up payload bytes (IO.iodata_length(frame.data)).

2. Per-fragment accumulation. Each non-final continuation frame is stored as a new cons cell around its own binary, [connection.fragment_frame.data | frame.data]. Only zero-length fragments are kept out, so 1-byte fragments are accepted. Each costs 7 bytes on the wire but keeps about 150 to 170 bytes in memory. Against 1.12.5, 1M fragments kept about 169 MB and 3M kept about 450 MB, growing linearly, and about 56 MB of traffic reaches the 8 MB payload cap.

3. Kept alive. Ping frames sent between fragments are handled by handle_control_frame without touching the fragment state, so they keep the connection alive past the idle timeout.

Proof of concept

1. Run Bandit with default settings and a WebSock that accepts every connection.
2. Complete the WebSocket upgrade and send a non-final text frame with a 1-byte payload.
3. Send 500,000 masked non-final continuation frames with 1-byte payloads, 3.5 MB in all.
4. Send a Ping. The server answers with a Pong, and BEAM memory has grown by about 82 MB while the message is still far below the 8 MB cap.

Impact

An unauthenticated client can make one WebSocket connection hold about 150 times max_fragmented_message_size in server memory (about 82 MB for 3.5 MB of traffic in the reporter's test). This affects any Bandit server that accepts WebSocket upgrades with default settings, including Phoenix LiveView and Channels apps.

Workarounds

Lower websocket_options: [max_fragmented_message_size: ...] to the largest fragmented message the application needs, for example 65_536. Memory per connection stays at about 150 times this limit, so a lower limit lowers the ceiling.

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in the HTTP/1.1 chunked body reader of mtrudel bandit allows an unauthenticated remote attacker to smuggle a second request past a front-end proxy via a chunk extension that contains a bare LF.

The chunked reader in lib/bandit/http1/socket.ex takes the chunk-size line to be everything up to the first CRLF and discards everything after ; without checking it against the RFC 9112 chunk-ext grammar, so bare LF, bare CR and other control bytes pass. A proxy that ends the size line at a bare LF reads 2;\nxx\r\n40\r\n... as one request whose second chunk holds a GET /admin, while Bandit ends the body early and dispatches GET /admin as a separate pipelined request. Deployments without such a proxy in front of Bandit are not affected.

This issue affects bandit: from 1.12.4 before 1.14.0.

Details

1. Unchecked extension. In lib/bandit/http1/socket.ex, the chunked body reader takes the chunk-size line to be everything up to the first CRLF. Anything after ; is thrown away without being checked against the RFC 9112 §7.1.1 chunk-ext grammar, so bare LF, bare CR and other control bytes are accepted. The 16-byte size-line cap does not help, because the payload needs only 5 bytes.

2. Bandit's reading. For the body 2;\nxx\r\n40\r\n0\r\n\r\nGET /admin ..., Bandit takes 2;\nxx as the size line and 40 as the 2-byte chunk, and the embedded 0\r\n\r\n ends the body. Bandit then runs GET /admin as a second pipelined request.

3. The proxy's reading. A proxy that ends the size line at the bare LF sees only one POST, with the chunk xx and a 0x40-byte chunk that holds the GET /admin bytes.

Proof of concept

1. Run Bandit with a Plug that reads the body and records each request's method and path.
2. On one connection, send POST /public with Transfer-Encoding: chunked and the body 2;\nxx\r\n40\r\n0\r\n\r\n, followed directly by GET /admin HTTP/1.1 with Content-Length: 7 and the body \r\n0\r\n\r\n.
3. Bandit dispatches both POST /public with the body 40 and GET /admin. A proxy that ends lines at a bare LF would have forwarded the same bytes as the single POST /public.

Impact

Behind a front-end proxy that treats a bare LF as a line ending and forwards chunked bodies unchanged, an unauthenticated attacker can have Bandit run requests the proxy never saw, getting past the proxy's access controls.

Workarounds

Where the front-end proxy can reach Bandit over HTTP/2, disable HTTP/1 with http_1_options: [enabled: false], so that the chunked body reader never runs.

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 hold stream processes open indefinitely via WINDOW_UPDATE or empty SETTINGS frames sent while a Plug reads the request body.

Bandit.HTTP2.Stream.do_read_data/4 in lib/bandit/http2/stream.ex waits for each frame with a fresh read_timeout. A stream WINDOW_UPDATE, or the zero-delta window update that every empty SETTINGS frame delivers to all streams, ends the wait without delivering any body data, and the loop starts a new full countdown. A client that sends one of these 9-byte frames before each countdown expires keeps read_body blocked, together with the stream process and whatever the application holds while reading, for as long as it likes.

This issue affects bandit: from 1.4.0 before 1.14.0.

Details

1. Per-receive timeout. Bandit.HTTP2.Stream.read_data/2 passes a flat read_timeout (default 15,000 ms) to do_read_data/4, which blocks in do_recv/2's receive ... after timeout.

2. Non-progress frames end the wait. A stream WINDOW_UPDATE, delivered through Bandit.HTTP2.Connection.handle_frame/3, or an empty SETTINGS frame, which delivers a zero-delta window update to every stream, is matched inside that receive. do_recv_send_window_update/2 returns a bare %Stream{}, and do_read_data/4 recurses with the identical timeout, restarting the countdown.

3. Nothing else bounds the read. The transport read timeout fires only when no bytes arrive, max_bytes is decremented only by DATA frames, and neither WINDOW_UPDATE nor SETTINGS frames are rate limited. The send path in do_send_data/4 uses a progress-based deadline; the read path does not.

Proof of concept

1. Run Bandit with a Plug that calls Plug.Conn.read_body/2.
2. Open an HTTP/2 connection and send HEADERS for POST / on stream 1 without END_STREAM.
3. Every 10 seconds, send a WINDOW_UPDATE on stream 1 with an increment of 1.
4. The stream stays open for 120 s, eight times the default 15 s read_timeout. Without the WINDOW_UPDATE frames, the server ends the read after about 15 s.

Impact

An unauthenticated client can keep a Bandit HTTP/2 stream, and whatever its request handler holds while reading the body, occupied indefinitely for 9 bytes per read_timeout, and repeat this across many streams and connections. This affects any Bandit server with HTTP/2 enabled whose routes read request bodies, which Plug.Parsers does for POST, PUT and PATCH.

Workarounds

Disable HTTP/2 with http_2_options: [enabled: false], so that the vulnerable read path never runs.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via DATA frames sent past the advertised receive window. The attacker requests a response larger than the 65,535-byte initial window and withholds WINDOW_UPDATE, so the stream process blocks while sending and stops reading, then floods small DATA frames on that stream. Every frame is queued in the stream's mailbox until the BEAM node runs out of memory.

Bandit.HTTP2.Connection.handle_frame/3 in lib/bandit/http2/connection.ex forwards each DATA frame to the stream process without consulting the receive window, and Bandit.HTTP2.FlowControl.compute_recv_window/2 replenishes the window as data arrives rather than as it is consumed, and never answers a violation with FLOW_CONTROL_ERROR.

This issue affects bandit: from 0.3.1 before 1.14.0.

Details

1. Connection-level window (lib/bandit/http2/connection.ex, lib/bandit/http2/flow_control.ex)

The handle_frame/3 clause for DATA frames sends the payload to the stream process before any window is checked. It then calls compute_recv_window/2, which subtracts the frame size and, once the window drops below 2^30, advertises a WINDOW_UPDATE back up to 2^31-1. A negative window is accepted, so a peer that overruns the window is never refused, and the window refills when data arrives rather than when it is consumed.

2. Stream-level window (lib/bandit/http2/stream.ex)

The stream receive window is debited only when the stream process reads the DATA message, and it never rejects a violation either.

3. Accumulation

While send_data/3 waits for send window, its selective receive matches only window updates and resets, so DATA messages pile up unread in the mailbox. A stream WINDOW_UPDATE of 1 byte, sent at intervals under the 15-second send timeout, keeps the stream alive while the attacker floods 1-byte DATA frames.

Proof of concept

1. On an HTTP/2 connection, request a resource whose response exceeds 65,535 bytes and send no WINDOW_UPDATE. The server sends one window's worth and the stream blocks in send_data/3.
2. Send 1-byte DATA frames on that stream in batches, ignoring the server's receive windows.
3. Between batches, at intervals under 15 seconds, send a stream WINDOW_UPDATE with an increment of 1 to keep the blocked send alive.
4. Send a PING. It is acknowledged, and the server has sent neither FLOW_CONTROL_ERROR nor GOAWAY while its memory grows with every frame.

Impact

An unauthenticated remote client can exhaust the memory of any Bandit server with HTTP/2 enabled by flooding DATA frames on a stream that is not reading its request body, such as one stalled sending a large response. The queued frames live in the BEAM node's memory, so exhausting it takes down every application on the node, not just the HTTP listener.

Workarounds

From 0.7.0, disable HTTP/2 with http_2_options: [enabled: false], which removes the vulnerable path.

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.

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.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to grow per-connection memory and CPU cost without bound via a large SETTINGS_HEADER_TABLE_SIZE. Bandit resizes its HPACK encoder table to whatever size the client advertises, up to 2^32-1 bytes, and indexes response headers into it. Because responses carry distinct values such as date or content-length, nothing is evicted and the table grows with every response for the life of the connection, while each lookup scans it linearly.

The SETTINGS handling in Bandit.HTTP2.Connection (lib/bandit/http2/connection.ex) passes remote_settings.header_table_size to HPAX.resize/2 with no server-side cap, and encode_headers encodes every response header as :store. Serving N responses on one connection therefore costs O(N²) CPU in the connection process.

This issue affects bandit: from 0.3.6 before 1.14.0.

Details

1. Table size (lib/bandit/http2/connection.ex)

On every SETTINGS frame, Bandit.HTTP2.Connection passes the peer's SETTINGS_HEADER_TABLE_SIZE straight to HPAX.resize/2 for the encoder table, accepting values up to 2^32-1. No server-side limit is applied.

2. Indexing

encode_headers encodes every response header as :store, adding it to the dynamic table. Headers whose values differ per response (date, content-length, set-cookie, x-request-id, a reflected location) produce new entries, and with a limit of about 4 GB none are evicted.

3. Cost

HPAX's lookup_by_header scans the table linearly for each header it encodes, so every response costs more than the one before it. Serving N responses on one connection costs O(N²) CPU in the connection process, and the table holds every entry for as long as the connection stays open.

Proof of concept

1. Open an HTTP/2 connection and advertise a SETTINGS_HEADER_TABLE_SIZE of 4294967295 in the initial SETTINGS frame.
2. Send cheap requests one after another on that connection, each to an endpoint whose response carries a header value that changes per request.
3. Time the round trips. In the reporter's run, the last 1,000 of 12,000 requests took 3.68 times as long as the first 1,000.

Impact

An unauthenticated remote client that keeps an HTTP/2 connection busy with cheap requests makes every response on it progressively more expensive, because the encoder table it enlarged never shrinks. Holding several such connections open ties up server CPU and memory for as long as the attacker keeps them alive.

Workarounds

From 0.7.0, cap the requests one HTTP/2 connection may serve, for example with http_2_options: [max_requests: 1000], so each connection and its encoder table is closed before the cost grows large. Alternatively, disable HTTP/2 with http_2_options: [enabled: false].

Summary

Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via a small HPACK-compressed HEADERS block. The block stores one large cookie value in the HPACK dynamic table and then references it tens of thousands of times with 1-byte indexed fields. In the reporter's run, a 49 KB block made a server with default settings allocate a 183 MB cookie binary before any application code ran, and every concurrent stream can repeat the cost.

Bandit.HTTP2.Connection caps only the compressed block (max_header_block_size), and its check of the decoded list against max_header_list_size never fires because that setting defaults to :infinity. combine_cookie_crumbs/1 in lib/bandit/http2/stream.ex then joins every crumb into one binary.

This issue affects bandit: from 0.3.3 before 1.14.0.

Details

1. Compression

The attacker's header block, split across HEADERS and CONTINUATION frames, stays under the 50,000-byte max_header_block_size. It inserts one 4,058-byte cookie into the 4,096-byte dynamic table, the largest value that fits, then references it about 45,000 times with 1-byte indexed representations. HPAX.decode returns a list whose entries all point at the same binary, so decoding itself stays cheap.

2. Missing decoded limit (lib/bandit/http2/connection.ex, lib/bandit/http2/settings.ex)

After decoding, the connection compares header_list_size(headers) against local_settings.max_header_list_size. That setting defaults to :infinity, and in Erlang term order every integer sorts below an atom, so the comparison never rejects a list. The limit is enforced only when an operator sets it.

3. Expansion (lib/bandit/http2/stream.ex)

read_headers calls combine_cookie_crumbs/1, which joins every crumb with Enum.map_join/3 into a single binary of about 183 MB before Plug.call/2 runs. max_concurrent_streams also defaults to :infinity, so N streams allocate N times as much.

Proof of concept

1. Against a Bandit server with default HTTP/2 settings, build an HPACK header block with the request pseudo-headers plus a 4,058-byte cookie stored in the dynamic table and then referenced about 45,000 times with indexed representations. The block is about 49 KB.
2. Send it on one stream as a HEADERS frame followed by CONTINUATION frames of at most 16,384 bytes, with END_HEADERS on the last.
3. The request reaches the plug with a cookie header of about 183 MB, and VM memory grows by about the same amount. Repeat on further streams to multiply it.

Impact

An unauthenticated remote client can make any Bandit server with default HTTP/2 settings allocate a cookie binary thousands of times larger than the header block it sent, before any application code runs. Repeating it across concurrent streams exhausts the BEAM node's memory, taking down every application on the node.

Workarounds

On 1.12.2 and later, set a finite decoded header list limit, for example http_2_options: [default_local_settings: [max_header_list_size: 65_536]], which resets the stream before the cookie crumbs are joined. From 0.7.0, disabling HTTP/2 with http_2_options: [enabled: false] removes the vulnerable path.

Summary

Improper Cleanup on Thrown Exception vulnerability in the HTTP/2 handler of mtrudel bandit allows an unauthenticated remote attacker to bypass per-connection resource limits via a single TCP write that carries several frames, one of which raises a stream error.

When a frame raises StreamError partway through a chunk, Bandit.HTTP2.Handler.handle_data/3 sends RST_STREAM and continues with the connection state from before the chunk, dropping the rest of it. Streams opened by earlier frames in the chunk keep running their Plug calls, but the stream counts, last_stream_id, the rapid-reset timestamps, the HPACK decoder state and the buffer roll back, so max_concurrent_streams, max_requests and the rapid-reset limiter never see those streams. A client that sends one HEADERS frame more than max_concurrent_streams in each write has the extra refused and the others forgotten: with a limit of 10, five such writes run 50 Plug calls at once.

This issue affects bandit: from 1.9.0 before 1.14.0.

Details

1. Function-level rescue. Bandit.HTTP2.Handler.handle_data/3 in lib/bandit/http2/handler.ex deserializes every frame in a TCP chunk inside an Enum.reduce_while/3 and wraps the whole function in a rescue. Inside that rescue, state is the original function argument, not the reduce_while accumulator.

2. Rollback on StreamError. When Bandit.HTTP2.Connection.handle_frame/3 raises StreamError partway through the chunk, rescue_stream_error/3 sends RST_STREAM and returns {:continue, state} with the connection as it was before the chunk. The rest of the chunk is dropped.

3. Lost bookkeeping. Frames already handled keep their side effects: their stream processes are running the Plug. But the stream counts, last_stream_id, reset_stream_timestamps, recv_hpack_state and buffer are rolled back, so max_concurrent_streams, max_requests and the rapid-reset limiter no longer count those streams. The same rollback drops HPACK table updates, which can mix up headers between requests, misaligns frame parsing, and sends a stale last_stream_id in GOAWAY.

Proof of concept

1. Run Bandit with a Plug that blocks until released and with http_2_options: [default_local_settings: [max_concurrent_streams: 10]].
2. Open an HTTP/2 connection with prior knowledge and complete the SETTINGS exchange.
3. In one TCP write, send 11 HEADERS frames with END_HEADERS and END_STREAM on streams 1, 3, ..., 21, each carrying a header block encoded without indexing. The eleventh is refused with REFUSED_STREAM, and the server forgets the ten streams before it.
4. Send the same write four more times. The Plug runs 50 times concurrently against a limit of 10.

Impact

An unauthenticated client can run more concurrent Plug calls on one HTTP/2 connection than the configured max_concurrent_streams allows (five times the limit in the reporter's test), tying up the server processes, CPU and memory the limit is meant to cap. Servers that serve HTTP/2 with a finite max_concurrent_streams are affected.

Workarounds

Disable HTTP/2 with http_2_options: [enabled: false], so that the vulnerable HTTP/2 handler never runs.

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.

Summary

Inefficient Algorithmic Complexity vulnerability in the header integer parser of mtrudel bandit allows an unauthenticated remote attacker to consume server CPU via a content-length value or a Host or :authority port made of thousands of digits.

Bandit.Headers.parse_integer/2 in lib/bandit/headers.ex builds the number one digit at a time with no limit on the digit count, allocating a new bignum at each step, so one value costs time quadratic in its length. It runs on raw request input over HTTP/1 and HTTP/2, before any range check. Over HTTP/2, a 4,000-digit value can be stored once in the HPACK dynamic table and re-sent on each new stream for about one byte: 124 KB of traffic kept the server busy for 27.9 s.

This issue affects bandit: from 1.0.0-pre.7 before 1.14.0.

Details

1. Unbounded digit loop. Bandit.Headers.parse_integer/2 in lib/bandit/headers.ex builds the number with total * 10 + digit - ?0 and has no limit on the digit count. Each step allocates a new bignum, so parsing one value costs O(n²). On OTP 28, 10,000 digits take about 10 ms, 50,000 about 250 ms and 80,000 about 560 ms, where String.to_integer/1 handles the same inputs in 1 to 3 ms.

2. Reached on raw input. It is called from get_content_length/1 and parse_hostlike_header!/1 on raw request input, before any range check. An all-digit content-length is returned as {:ok, huge_int}, and the is_port_number guard only runs after the whole number is built.

3. HPACK amplification. Over HTTP/2, a 4,000-digit value (about 1.1 ms to parse) can be stored once in the HPACK dynamic table and then re-sent on each new stream for about one byte.

Proof of concept

1. Run Bandit with any Plug.
2. Open an HTTP/2 connection with prior knowledge and complete the SETTINGS exchange.
3. In one write, send 5,000 HEADERS frames for POST / on new streams, each carrying a content-length of 4,000 9 digits encoded with HPACK indexing, so that every frame after the first refers to the stored value.
4. The 124,003 bytes take 27.9 s to process before all 5,000 requests reach the Plug.

Impact

An unauthenticated client can make the server spend CPU time out of all proportion to the traffic it sends (27.9 s for 124 KB in the reporter's test). This affects any Bandit server reachable by untrusted clients over HTTP/1 or HTTP/2, with no special configuration.

Summary

Client-Side Enforcement of Server-Side Security vulnerability in the WebSocket connection handling of mtrudel bandit allows a remote client to keep running WebSock handler code after the server has stopped its connection, via data frames sent after ignoring the server's Close frame.

When a WebSock callback returns {:stop, ...}, Bandit.WebSocket.Connection calls terminate/2, sends Close and shuts down the write side, but keeps the connection process running in a :closing state. handle_frame/3 and handle_info/3 never check that state, so later frames still reach handle_in/2 and later messages reach handle_info/2, with the state from the stop tuple, until the client sends Close, TCP drops or the idle timeout fires. A client refused in init/1 after a failed token check could still run an admin-only action.

This issue affects bandit: from 0.5.1 before 1.14.0.

Details

1. Stop without close. In Bandit.WebSocket.Connection, do_stop/4 calls terminate/2, sends the Close frame and runs shutdown(:write). It then returns {:continue, %{connection | state: :closing}}, so Bandit.WebSocket.Handler keeps the process alive.

2. No state check. handle_frame/3 and handle_info/3 never check connection.state. Every later data frame still reaches handle_in/2, and every later message still reaches handle_info/2, with the state from the stop tuple.

3. Client-controlled lifetime. The connection ends only when the client sends Close, TCP drops, or the idle timeout fires, and each client frame resets that timeout. All stops through do_stop are affected: {:stop, :normal, ...}, {:stop, {:shutdown, :disconnected}, ...} and {:stop, {:shutdown, :restart}, ...}, which is what Phoenix's :socket_drain returns. A banned user who was kicked kept posting for longer than the idle timeout.

Proof of concept

1. Serve a WebSock whose init/1 returns {:stop, :normal, {4401, "unauthorized"}, state} for a wrong token, and whose handle_in/2 runs an admin-only delete_all_users action when user_id is admin.
2. Upgrade with ?user_id=admin&token=wrong. The server calls terminate/2 and sends a Close frame with code 4401.
3. Ignore the Close frame and send a masked text frame delete_all_users.
4. handle_in/2 runs delete_all_users as admin.

Impact

A remote client that ignores the Close frame can keep invoking a WebSock application's handlers after the application refused or ended its session, bypassing an authorization check in init/1 or a kick or ban. This affects WebSock applications that rely on {:stop, ...} to end a session.

Workarounds

Mark the WebSock state as stopped whenever a callback returns {:stop, ...}, and have handle_in/2 and handle_info/2 return {:ok, state} without acting while that mark is set.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in the WebSocket fragment reassembly of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via a fragmented message made of many 1-byte continuation frames.

Bandit.WebSocket.Connection checks max_fragmented_message_size against the payload bytes received, but keeps every non-final continuation frame as a new list cell around its own binary, and nothing limits the number of fragments. A 1-byte fragment costs 7 bytes on the wire but about 150 to 170 bytes of server memory, so one connection can hold about 150 times the configured limit, roughly 1.2 to 1.4 GB at the default 8 MB. Ping frames between fragments keep the connection alive past the idle timeout.

This issue affects bandit: from 1.11.0 before 1.14.0.

Details

1. Byte-only limit. In Bandit.WebSocket.Connection (lib/bandit/websocket/connection.ex), the fragment limit is checked against fragment_size, which only adds up payload bytes (IO.iodata_length(frame.data)).

2. Per-fragment accumulation. Each non-final continuation frame is stored as a new cons cell around its own binary, [connection.fragment_frame.data | frame.data]. Only zero-length fragments are kept out, so 1-byte fragments are accepted. Each costs 7 bytes on the wire but keeps about 150 to 170 bytes in memory. Against 1.12.5, 1M fragments kept about 169 MB and 3M kept about 450 MB, growing linearly, and about 56 MB of traffic reaches the 8 MB payload cap.

3. Kept alive. Ping frames sent between fragments are handled by handle_control_frame without touching the fragment state, so they keep the connection alive past the idle timeout.

Proof of concept

1. Run Bandit with default settings and a WebSock that accepts every connection.
2. Complete the WebSocket upgrade and send a non-final text frame with a 1-byte payload.
3. Send 500,000 masked non-final continuation frames with 1-byte payloads, 3.5 MB in all.
4. Send a Ping. The server answers with a Pong, and BEAM memory has grown by about 82 MB while the message is still far below the 8 MB cap.

Impact

An unauthenticated client can make one WebSocket connection hold about 150 times max_fragmented_message_size in server memory (about 82 MB for 3.5 MB of traffic in the reporter's test). This affects any Bandit server that accepts WebSocket upgrades with default settings, including Phoenix LiveView and Channels apps.

Workarounds

Lower websocket_options: [max_fragmented_message_size: ...] to the largest fragmented message the application needs, for example 65_536. Memory per connection stays at about 150 times this limit, so a lower limit lowers the ceiling.

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in the HTTP/1.1 chunked body reader of mtrudel bandit allows an unauthenticated remote attacker to smuggle a second request past a front-end proxy via a chunk extension that contains a bare LF.

The chunked reader in lib/bandit/http1/socket.ex takes the chunk-size line to be everything up to the first CRLF and discards everything after ; without checking it against the RFC 9112 chunk-ext grammar, so bare LF, bare CR and other control bytes pass. A proxy that ends the size line at a bare LF reads 2;\nxx\r\n40\r\n... as one request whose second chunk holds a GET /admin, while Bandit ends the body early and dispatches GET /admin as a separate pipelined request. Deployments without such a proxy in front of Bandit are not affected.

This issue affects bandit: from 1.12.4 before 1.14.0.

Details

1. Unchecked extension. In lib/bandit/http1/socket.ex, the chunked body reader takes the chunk-size line to be everything up to the first CRLF. Anything after ; is thrown away without being checked against the RFC 9112 §7.1.1 chunk-ext grammar, so bare LF, bare CR and other control bytes are accepted. The 16-byte size-line cap does not help, because the payload needs only 5 bytes.

2. Bandit's reading. For the body 2;\nxx\r\n40\r\n0\r\n\r\nGET /admin ..., Bandit takes 2;\nxx as the size line and 40 as the 2-byte chunk, and the embedded 0\r\n\r\n ends the body. Bandit then runs GET /admin as a second pipelined request.

3. The proxy's reading. A proxy that ends the size line at the bare LF sees only one POST, with the chunk xx and a 0x40-byte chunk that holds the GET /admin bytes.

Proof of concept

1. Run Bandit with a Plug that reads the body and records each request's method and path.
2. On one connection, send POST /public with Transfer-Encoding: chunked and the body 2;\nxx\r\n40\r\n0\r\n\r\n, followed directly by GET /admin HTTP/1.1 with Content-Length: 7 and the body \r\n0\r\n\r\n.
3. Bandit dispatches both POST /public with the body 40 and GET /admin. A proxy that ends lines at a bare LF would have forwarded the same bytes as the single POST /public.

Impact

Behind a front-end proxy that treats a bare LF as a line ending and forwards chunked bodies unchanged, an unauthenticated attacker can have Bandit run requests the proxy never saw, getting past the proxy's access controls.

Workarounds

Where the front-end proxy can reach Bandit over HTTP/2, disable HTTP/1 with http_1_options: [enabled: false], so that the chunked body reader never runs.

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 hold stream processes open indefinitely via WINDOW_UPDATE or empty SETTINGS frames sent while a Plug reads the request body.

Bandit.HTTP2.Stream.do_read_data/4 in lib/bandit/http2/stream.ex waits for each frame with a fresh read_timeout. A stream WINDOW_UPDATE, or the zero-delta window update that every empty SETTINGS frame delivers to all streams, ends the wait without delivering any body data, and the loop starts a new full countdown. A client that sends one of these 9-byte frames before each countdown expires keeps read_body blocked, together with the stream process and whatever the application holds while reading, for as long as it likes.

This issue affects bandit: from 1.4.0 before 1.14.0.

Details

1. Per-receive timeout. Bandit.HTTP2.Stream.read_data/2 passes a flat read_timeout (default 15,000 ms) to do_read_data/4, which blocks in do_recv/2's receive ... after timeout.

2. Non-progress frames end the wait. A stream WINDOW_UPDATE, delivered through Bandit.HTTP2.Connection.handle_frame/3, or an empty SETTINGS frame, which delivers a zero-delta window update to every stream, is matched inside that receive. do_recv_send_window_update/2 returns a bare %Stream{}, and do_read_data/4 recurses with the identical timeout, restarting the countdown.

3. Nothing else bounds the read. The transport read timeout fires only when no bytes arrive, max_bytes is decremented only by DATA frames, and neither WINDOW_UPDATE nor SETTINGS frames are rate limited. The send path in do_send_data/4 uses a progress-based deadline; the read path does not.

Proof of concept

1. Run Bandit with a Plug that calls Plug.Conn.read_body/2.
2. Open an HTTP/2 connection and send HEADERS for POST / on stream 1 without END_STREAM.
3. Every 10 seconds, send a WINDOW_UPDATE on stream 1 with an increment of 1.
4. The stream stays open for 120 s, eight times the default 15 s read_timeout. Without the WINDOW_UPDATE frames, the server ends the read after about 15 s.

Impact

An unauthenticated client can keep a Bandit HTTP/2 stream, and whatever its request handler holds while reading the body, occupied indefinitely for 9 bytes per read_timeout, and repeat this across many streams and connections. This affects any Bandit server with HTTP/2 enabled whose routes read request bodies, which Plug.Parsers does for POST, PUT and PATCH.

Workarounds

Disable HTTP/2 with http_2_options: [enabled: false], so that the vulnerable read path never runs.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via DATA frames sent past the advertised receive window. The attacker requests a response larger than the 65,535-byte initial window and withholds WINDOW_UPDATE, so the stream process blocks while sending and stops reading, then floods small DATA frames on that stream. Every frame is queued in the stream's mailbox until the BEAM node runs out of memory.

Bandit.HTTP2.Connection.handle_frame/3 in lib/bandit/http2/connection.ex forwards each DATA frame to the stream process without consulting the receive window, and Bandit.HTTP2.FlowControl.compute_recv_window/2 replenishes the window as data arrives rather than as it is consumed, and never answers a violation with FLOW_CONTROL_ERROR.

This issue affects bandit: from 0.3.1 before 1.14.0.

Details

1. Connection-level window (lib/bandit/http2/connection.ex, lib/bandit/http2/flow_control.ex)

The handle_frame/3 clause for DATA frames sends the payload to the stream process before any window is checked. It then calls compute_recv_window/2, which subtracts the frame size and, once the window drops below 2^30, advertises a WINDOW_UPDATE back up to 2^31-1. A negative window is accepted, so a peer that overruns the window is never refused, and the window refills when data arrives rather than when it is consumed.

2. Stream-level window (lib/bandit/http2/stream.ex)

The stream receive window is debited only when the stream process reads the DATA message, and it never rejects a violation either.

3. Accumulation

While send_data/3 waits for send window, its selective receive matches only window updates and resets, so DATA messages pile up unread in the mailbox. A stream WINDOW_UPDATE of 1 byte, sent at intervals under the 15-second send timeout, keeps the stream alive while the attacker floods 1-byte DATA frames.

Proof of concept

1. On an HTTP/2 connection, request a resource whose response exceeds 65,535 bytes and send no WINDOW_UPDATE. The server sends one window's worth and the stream blocks in send_data/3.
2. Send 1-byte DATA frames on that stream in batches, ignoring the server's receive windows.
3. Between batches, at intervals under 15 seconds, send a stream WINDOW_UPDATE with an increment of 1 to keep the blocked send alive.
4. Send a PING. It is acknowledged, and the server has sent neither FLOW_CONTROL_ERROR nor GOAWAY while its memory grows with every frame.

Impact

An unauthenticated remote client can exhaust the memory of any Bandit server with HTTP/2 enabled by flooding DATA frames on a stream that is not reading its request body, such as one stalled sending a large response. The queued frames live in the BEAM node's memory, so exhausting it takes down every application on the node, not just the HTTP listener.

Workarounds

From 0.7.0, disable HTTP/2 with http_2_options: [enabled: false], which removes the vulnerable path.

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.

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.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to grow per-connection memory and CPU cost without bound via a large SETTINGS_HEADER_TABLE_SIZE. Bandit resizes its HPACK encoder table to whatever size the client advertises, up to 2^32-1 bytes, and indexes response headers into it. Because responses carry distinct values such as date or content-length, nothing is evicted and the table grows with every response for the life of the connection, while each lookup scans it linearly.

The SETTINGS handling in Bandit.HTTP2.Connection (lib/bandit/http2/connection.ex) passes remote_settings.header_table_size to HPAX.resize/2 with no server-side cap, and encode_headers encodes every response header as :store. Serving N responses on one connection therefore costs O(N²) CPU in the connection process.

This issue affects bandit: from 0.3.6 before 1.14.0.

Details

1. Table size (lib/bandit/http2/connection.ex)

On every SETTINGS frame, Bandit.HTTP2.Connection passes the peer's SETTINGS_HEADER_TABLE_SIZE straight to HPAX.resize/2 for the encoder table, accepting values up to 2^32-1. No server-side limit is applied.

2. Indexing

encode_headers encodes every response header as :store, adding it to the dynamic table. Headers whose values differ per response (date, content-length, set-cookie, x-request-id, a reflected location) produce new entries, and with a limit of about 4 GB none are evicted.

3. Cost

HPAX's lookup_by_header scans the table linearly for each header it encodes, so every response costs more than the one before it. Serving N responses on one connection costs O(N²) CPU in the connection process, and the table holds every entry for as long as the connection stays open.

Proof of concept

1. Open an HTTP/2 connection and advertise a SETTINGS_HEADER_TABLE_SIZE of 4294967295 in the initial SETTINGS frame.
2. Send cheap requests one after another on that connection, each to an endpoint whose response carries a header value that changes per request.
3. Time the round trips. In the reporter's run, the last 1,000 of 12,000 requests took 3.68 times as long as the first 1,000.

Impact

An unauthenticated remote client that keeps an HTTP/2 connection busy with cheap requests makes every response on it progressively more expensive, because the encoder table it enlarged never shrinks. Holding several such connections open ties up server CPU and memory for as long as the attacker keeps them alive.

Workarounds

From 0.7.0, cap the requests one HTTP/2 connection may serve, for example with http_2_options: [max_requests: 1000], so each connection and its encoder table is closed before the cost grows large. Alternatively, disable HTTP/2 with http_2_options: [enabled: false].

Summary

Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via a small HPACK-compressed HEADERS block. The block stores one large cookie value in the HPACK dynamic table and then references it tens of thousands of times with 1-byte indexed fields. In the reporter's run, a 49 KB block made a server with default settings allocate a 183 MB cookie binary before any application code ran, and every concurrent stream can repeat the cost.

Bandit.HTTP2.Connection caps only the compressed block (max_header_block_size), and its check of the decoded list against max_header_list_size never fires because that setting defaults to :infinity. combine_cookie_crumbs/1 in lib/bandit/http2/stream.ex then joins every crumb into one binary.

This issue affects bandit: from 0.3.3 before 1.14.0.

Details

1. Compression

The attacker's header block, split across HEADERS and CONTINUATION frames, stays under the 50,000-byte max_header_block_size. It inserts one 4,058-byte cookie into the 4,096-byte dynamic table, the largest value that fits, then references it about 45,000 times with 1-byte indexed representations. HPAX.decode returns a list whose entries all point at the same binary, so decoding itself stays cheap.

2. Missing decoded limit (lib/bandit/http2/connection.ex, lib/bandit/http2/settings.ex)

After decoding, the connection compares header_list_size(headers) against local_settings.max_header_list_size. That setting defaults to :infinity, and in Erlang term order every integer sorts below an atom, so the comparison never rejects a list. The limit is enforced only when an operator sets it.

3. Expansion (lib/bandit/http2/stream.ex)

read_headers calls combine_cookie_crumbs/1, which joins every crumb with Enum.map_join/3 into a single binary of about 183 MB before Plug.call/2 runs. max_concurrent_streams also defaults to :infinity, so N streams allocate N times as much.

Proof of concept

1. Against a Bandit server with default HTTP/2 settings, build an HPACK header block with the request pseudo-headers plus a 4,058-byte cookie stored in the dynamic table and then referenced about 45,000 times with indexed representations. The block is about 49 KB.
2. Send it on one stream as a HEADERS frame followed by CONTINUATION frames of at most 16,384 bytes, with END_HEADERS on the last.
3. The request reaches the plug with a cookie header of about 183 MB, and VM memory grows by about the same amount. Repeat on further streams to multiply it.

Impact

An unauthenticated remote client can make any Bandit server with default HTTP/2 settings allocate a cookie binary thousands of times larger than the header block it sent, before any application code runs. Repeating it across concurrent streams exhausts the BEAM node's memory, taking down every application on the node.

Workarounds

On 1.12.2 and later, set a finite decoded header list limit, for example http_2_options: [default_local_settings: [max_header_list_size: 65_536]], which resets the stream before the cookie crumbs are joined. From 0.7.0, disabling HTTP/2 with http_2_options: [enabled: false] removes the vulnerable path.

Summary

Improper Cleanup on Thrown Exception vulnerability in the HTTP/2 handler of mtrudel bandit allows an unauthenticated remote attacker to bypass per-connection resource limits via a single TCP write that carries several frames, one of which raises a stream error.

When a frame raises StreamError partway through a chunk, Bandit.HTTP2.Handler.handle_data/3 sends RST_STREAM and continues with the connection state from before the chunk, dropping the rest of it. Streams opened by earlier frames in the chunk keep running their Plug calls, but the stream counts, last_stream_id, the rapid-reset timestamps, the HPACK decoder state and the buffer roll back, so max_concurrent_streams, max_requests and the rapid-reset limiter never see those streams. A client that sends one HEADERS frame more than max_concurrent_streams in each write has the extra refused and the others forgotten: with a limit of 10, five such writes run 50 Plug calls at once.

This issue affects bandit: from 1.9.0 before 1.14.0.

Details

1. Function-level rescue. Bandit.HTTP2.Handler.handle_data/3 in lib/bandit/http2/handler.ex deserializes every frame in a TCP chunk inside an Enum.reduce_while/3 and wraps the whole function in a rescue. Inside that rescue, state is the original function argument, not the reduce_while accumulator.

2. Rollback on StreamError. When Bandit.HTTP2.Connection.handle_frame/3 raises StreamError partway through the chunk, rescue_stream_error/3 sends RST_STREAM and returns {:continue, state} with the connection as it was before the chunk. The rest of the chunk is dropped.

3. Lost bookkeeping. Frames already handled keep their side effects: their stream processes are running the Plug. But the stream counts, last_stream_id, reset_stream_timestamps, recv_hpack_state and buffer are rolled back, so max_concurrent_streams, max_requests and the rapid-reset limiter no longer count those streams. The same rollback drops HPACK table updates, which can mix up headers between requests, misaligns frame parsing, and sends a stale last_stream_id in GOAWAY.

Proof of concept

1. Run Bandit with a Plug that blocks until released and with http_2_options: [default_local_settings: [max_concurrent_streams: 10]].
2. Open an HTTP/2 connection with prior knowledge and complete the SETTINGS exchange.
3. In one TCP write, send 11 HEADERS frames with END_HEADERS and END_STREAM on streams 1, 3, ..., 21, each carrying a header block encoded without indexing. The eleventh is refused with REFUSED_STREAM, and the server forgets the ten streams before it.
4. Send the same write four more times. The Plug runs 50 times concurrently against a limit of 10.

Impact

An unauthenticated client can run more concurrent Plug calls on one HTTP/2 connection than the configured max_concurrent_streams allows (five times the limit in the reporter's test), tying up the server processes, CPU and memory the limit is meant to cap. Servers that serve HTTP/2 with a finite max_concurrent_streams are affected.

Workarounds

Disable HTTP/2 with http_2_options: [enabled: false], so that the vulnerable HTTP/2 handler never runs.

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.

Summary

Inefficient Algorithmic Complexity vulnerability in the header integer parser of mtrudel bandit allows an unauthenticated remote attacker to consume server CPU via a content-length value or a Host or :authority port made of thousands of digits.

Bandit.Headers.parse_integer/2 in lib/bandit/headers.ex builds the number one digit at a time with no limit on the digit count, allocating a new bignum at each step, so one value costs time quadratic in its length. It runs on raw request input over HTTP/1 and HTTP/2, before any range check. Over HTTP/2, a 4,000-digit value can be stored once in the HPACK dynamic table and re-sent on each new stream for about one byte: 124 KB of traffic kept the server busy for 27.9 s.

This issue affects bandit: from 1.0.0-pre.7 before 1.14.0.

Details

1. Unbounded digit loop. Bandit.Headers.parse_integer/2 in lib/bandit/headers.ex builds the number with total * 10 + digit - ?0 and has no limit on the digit count. Each step allocates a new bignum, so parsing one value costs O(n²). On OTP 28, 10,000 digits take about 10 ms, 50,000 about 250 ms and 80,000 about 560 ms, where String.to_integer/1 handles the same inputs in 1 to 3 ms.

2. Reached on raw input. It is called from get_content_length/1 and parse_hostlike_header!/1 on raw request input, before any range check. An all-digit content-length is returned as {:ok, huge_int}, and the is_port_number guard only runs after the whole number is built.

3. HPACK amplification. Over HTTP/2, a 4,000-digit value (about 1.1 ms to parse) can be stored once in the HPACK dynamic table and then re-sent on each new stream for about one byte.

Proof of concept

1. Run Bandit with any Plug.
2. Open an HTTP/2 connection with prior knowledge and complete the SETTINGS exchange.
3. In one write, send 5,000 HEADERS frames for POST / on new streams, each carrying a content-length of 4,000 9 digits encoded with HPACK indexing, so that every frame after the first refers to the stored value.
4. The 124,003 bytes take 27.9 s to process before all 5,000 requests reach the Plug.

Impact

An unauthenticated client can make the server spend CPU time out of all proportion to the traffic it sends (27.9 s for 124 KB in the reporter's test). This affects any Bandit server reachable by untrusted clients over HTTP/1 or HTTP/2, with no special configuration.

Summary

Client-Side Enforcement of Server-Side Security vulnerability in the WebSocket connection handling of mtrudel bandit allows a remote client to keep running WebSock handler code after the server has stopped its connection, via data frames sent after ignoring the server's Close frame.

When a WebSock callback returns {:stop, ...}, Bandit.WebSocket.Connection calls terminate/2, sends Close and shuts down the write side, but keeps the connection process running in a :closing state. handle_frame/3 and handle_info/3 never check that state, so later frames still reach handle_in/2 and later messages reach handle_info/2, with the state from the stop tuple, until the client sends Close, TCP drops or the idle timeout fires. A client refused in init/1 after a failed token check could still run an admin-only action.

This issue affects bandit: from 0.5.1 before 1.14.0.

Details

1. Stop without close. In Bandit.WebSocket.Connection, do_stop/4 calls terminate/2, sends the Close frame and runs shutdown(:write). It then returns {:continue, %{connection | state: :closing}}, so Bandit.WebSocket.Handler keeps the process alive.

2. No state check. handle_frame/3 and handle_info/3 never check connection.state. Every later data frame still reaches handle_in/2, and every later message still reaches handle_info/2, with the state from the stop tuple.

3. Client-controlled lifetime. The connection ends only when the client sends Close, TCP drops, or the idle timeout fires, and each client frame resets that timeout. All stops through do_stop are affected: {:stop, :normal, ...}, {:stop, {:shutdown, :disconnected}, ...} and {:stop, {:shutdown, :restart}, ...}, which is what Phoenix's :socket_drain returns. A banned user who was kicked kept posting for longer than the idle timeout.

Proof of concept

1. Serve a WebSock whose init/1 returns {:stop, :normal, {4401, "unauthorized"}, state} for a wrong token, and whose handle_in/2 runs an admin-only delete_all_users action when user_id is admin.
2. Upgrade with ?user_id=admin&token=wrong. The server calls terminate/2 and sends a Close frame with code 4401.
3. Ignore the Close frame and send a masked text frame delete_all_users.
4. handle_in/2 runs delete_all_users as admin.

Impact

A remote client that ignores the Close frame can keep invoking a WebSock application's handlers after the application refused or ended its session, bypassing an authorization check in init/1 or a kick or ban. This affects WebSock applications that rely on {:stop, ...} to end a session.

Workarounds

Mark the WebSock state as stopped whenever a callback returns {:stop, ...}, and have handle_in/2 and handle_info/2 return {:ok, state} without acting while that mark is set.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in the WebSocket fragment reassembly of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via a fragmented message made of many 1-byte continuation frames.

Bandit.WebSocket.Connection checks max_fragmented_message_size against the payload bytes received, but keeps every non-final continuation frame as a new list cell around its own binary, and nothing limits the number of fragments. A 1-byte fragment costs 7 bytes on the wire but about 150 to 170 bytes of server memory, so one connection can hold about 150 times the configured limit, roughly 1.2 to 1.4 GB at the default 8 MB. Ping frames between fragments keep the connection alive past the idle timeout.

This issue affects bandit: from 1.11.0 before 1.14.0.

Details

1. Byte-only limit. In Bandit.WebSocket.Connection (lib/bandit/websocket/connection.ex), the fragment limit is checked against fragment_size, which only adds up payload bytes (IO.iodata_length(frame.data)).

2. Per-fragment accumulation. Each non-final continuation frame is stored as a new cons cell around its own binary, [connection.fragment_frame.data | frame.data]. Only zero-length fragments are kept out, so 1-byte fragments are accepted. Each costs 7 bytes on the wire but keeps about 150 to 170 bytes in memory. Against 1.12.5, 1M fragments kept about 169 MB and 3M kept about 450 MB, growing linearly, and about 56 MB of traffic reaches the 8 MB payload cap.

3. Kept alive. Ping frames sent between fragments are handled by handle_control_frame without touching the fragment state, so they keep the connection alive past the idle timeout.

Proof of concept

1. Run Bandit with default settings and a WebSock that accepts every connection.
2. Complete the WebSocket upgrade and send a non-final text frame with a 1-byte payload.
3. Send 500,000 masked non-final continuation frames with 1-byte payloads, 3.5 MB in all.
4. Send a Ping. The server answers with a Pong, and BEAM memory has grown by about 82 MB while the message is still far below the 8 MB cap.

Impact

An unauthenticated client can make one WebSocket connection hold about 150 times max_fragmented_message_size in server memory (about 82 MB for 3.5 MB of traffic in the reporter's test). This affects any Bandit server that accepts WebSocket upgrades with default settings, including Phoenix LiveView and Channels apps.

Workarounds

Lower websocket_options: [max_fragmented_message_size: ...] to the largest fragmented message the application needs, for example 65_536. Memory per connection stays at about 150 times this limit, so a lower limit lowers the ceiling.

Summary

Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling') vulnerability in the HTTP/1.1 chunked body reader of mtrudel bandit allows an unauthenticated remote attacker to smuggle a second request past a front-end proxy via a chunk extension that contains a bare LF.

The chunked reader in lib/bandit/http1/socket.ex takes the chunk-size line to be everything up to the first CRLF and discards everything after ; without checking it against the RFC 9112 chunk-ext grammar, so bare LF, bare CR and other control bytes pass. A proxy that ends the size line at a bare LF reads 2;\nxx\r\n40\r\n... as one request whose second chunk holds a GET /admin, while Bandit ends the body early and dispatches GET /admin as a separate pipelined request. Deployments without such a proxy in front of Bandit are not affected.

This issue affects bandit: from 1.12.4 before 1.14.0.

Details

1. Unchecked extension. In lib/bandit/http1/socket.ex, the chunked body reader takes the chunk-size line to be everything up to the first CRLF. Anything after ; is thrown away without being checked against the RFC 9112 §7.1.1 chunk-ext grammar, so bare LF, bare CR and other control bytes are accepted. The 16-byte size-line cap does not help, because the payload needs only 5 bytes.

2. Bandit's reading. For the body 2;\nxx\r\n40\r\n0\r\n\r\nGET /admin ..., Bandit takes 2;\nxx as the size line and 40 as the 2-byte chunk, and the embedded 0\r\n\r\n ends the body. Bandit then runs GET /admin as a second pipelined request.

3. The proxy's reading. A proxy that ends the size line at the bare LF sees only one POST, with the chunk xx and a 0x40-byte chunk that holds the GET /admin bytes.

Proof of concept

1. Run Bandit with a Plug that reads the body and records each request's method and path.
2. On one connection, send POST /public with Transfer-Encoding: chunked and the body 2;\nxx\r\n40\r\n0\r\n\r\n, followed directly by GET /admin HTTP/1.1 with Content-Length: 7 and the body \r\n0\r\n\r\n.
3. Bandit dispatches both POST /public with the body 40 and GET /admin. A proxy that ends lines at a bare LF would have forwarded the same bytes as the single POST /public.

Impact

Behind a front-end proxy that treats a bare LF as a line ending and forwards chunked bodies unchanged, an unauthenticated attacker can have Bandit run requests the proxy never saw, getting past the proxy's access controls.

Workarounds

Where the front-end proxy can reach Bandit over HTTP/2, disable HTTP/1 with http_1_options: [enabled: false], so that the chunked body reader never runs.

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 hold stream processes open indefinitely via WINDOW_UPDATE or empty SETTINGS frames sent while a Plug reads the request body.

Bandit.HTTP2.Stream.do_read_data/4 in lib/bandit/http2/stream.ex waits for each frame with a fresh read_timeout. A stream WINDOW_UPDATE, or the zero-delta window update that every empty SETTINGS frame delivers to all streams, ends the wait without delivering any body data, and the loop starts a new full countdown. A client that sends one of these 9-byte frames before each countdown expires keeps read_body blocked, together with the stream process and whatever the application holds while reading, for as long as it likes.

This issue affects bandit: from 1.4.0 before 1.14.0.

Details

1. Per-receive timeout. Bandit.HTTP2.Stream.read_data/2 passes a flat read_timeout (default 15,000 ms) to do_read_data/4, which blocks in do_recv/2's receive ... after timeout.

2. Non-progress frames end the wait. A stream WINDOW_UPDATE, delivered through Bandit.HTTP2.Connection.handle_frame/3, or an empty SETTINGS frame, which delivers a zero-delta window update to every stream, is matched inside that receive. do_recv_send_window_update/2 returns a bare %Stream{}, and do_read_data/4 recurses with the identical timeout, restarting the countdown.

3. Nothing else bounds the read. The transport read timeout fires only when no bytes arrive, max_bytes is decremented only by DATA frames, and neither WINDOW_UPDATE nor SETTINGS frames are rate limited. The send path in do_send_data/4 uses a progress-based deadline; the read path does not.

Proof of concept

1. Run Bandit with a Plug that calls Plug.Conn.read_body/2.
2. Open an HTTP/2 connection and send HEADERS for POST / on stream 1 without END_STREAM.
3. Every 10 seconds, send a WINDOW_UPDATE on stream 1 with an increment of 1.
4. The stream stays open for 120 s, eight times the default 15 s read_timeout. Without the WINDOW_UPDATE frames, the server ends the read after about 15 s.

Impact

An unauthenticated client can keep a Bandit HTTP/2 stream, and whatever its request handler holds while reading the body, occupied indefinitely for 9 bytes per read_timeout, and repeat this across many streams and connections. This affects any Bandit server with HTTP/2 enabled whose routes read request bodies, which Plug.Parsers does for POST, PUT and PATCH.

Workarounds

Disable HTTP/2 with http_2_options: [enabled: false], so that the vulnerable read path never runs.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via DATA frames sent past the advertised receive window. The attacker requests a response larger than the 65,535-byte initial window and withholds WINDOW_UPDATE, so the stream process blocks while sending and stops reading, then floods small DATA frames on that stream. Every frame is queued in the stream's mailbox until the BEAM node runs out of memory.

Bandit.HTTP2.Connection.handle_frame/3 in lib/bandit/http2/connection.ex forwards each DATA frame to the stream process without consulting the receive window, and Bandit.HTTP2.FlowControl.compute_recv_window/2 replenishes the window as data arrives rather than as it is consumed, and never answers a violation with FLOW_CONTROL_ERROR.

This issue affects bandit: from 0.3.1 before 1.14.0.

Details

1. Connection-level window (lib/bandit/http2/connection.ex, lib/bandit/http2/flow_control.ex)

The handle_frame/3 clause for DATA frames sends the payload to the stream process before any window is checked. It then calls compute_recv_window/2, which subtracts the frame size and, once the window drops below 2^30, advertises a WINDOW_UPDATE back up to 2^31-1. A negative window is accepted, so a peer that overruns the window is never refused, and the window refills when data arrives rather than when it is consumed.

2. Stream-level window (lib/bandit/http2/stream.ex)

The stream receive window is debited only when the stream process reads the DATA message, and it never rejects a violation either.

3. Accumulation

While send_data/3 waits for send window, its selective receive matches only window updates and resets, so DATA messages pile up unread in the mailbox. A stream WINDOW_UPDATE of 1 byte, sent at intervals under the 15-second send timeout, keeps the stream alive while the attacker floods 1-byte DATA frames.

Proof of concept

1. On an HTTP/2 connection, request a resource whose response exceeds 65,535 bytes and send no WINDOW_UPDATE. The server sends one window's worth and the stream blocks in send_data/3.
2. Send 1-byte DATA frames on that stream in batches, ignoring the server's receive windows.
3. Between batches, at intervals under 15 seconds, send a stream WINDOW_UPDATE with an increment of 1 to keep the blocked send alive.
4. Send a PING. It is acknowledged, and the server has sent neither FLOW_CONTROL_ERROR nor GOAWAY while its memory grows with every frame.

Impact

An unauthenticated remote client can exhaust the memory of any Bandit server with HTTP/2 enabled by flooding DATA frames on a stream that is not reading its request body, such as one stalled sending a large response. The queued frames live in the BEAM node's memory, so exhausting it takes down every application on the node, not just the HTTP listener.

Workarounds

From 0.7.0, disable HTTP/2 with http_2_options: [enabled: false], which removes the vulnerable path.

Summary

Improper Validation of Syntactic Correctness of Input vulnerability in mtrudel bandit allows an unauthenticated remote attacker to set conn.host and conn.port to values outside the RFC 3986 host grammar via the authority of an HTTP/1 absolute-form or authority-form request target. Bandit validates the Host header and answers 400 when it is malformed, but when the request target carries its own authority that authority takes precedence, as RFC 9112 requires, and Bandit.Pipeline.determine_host_and_port!/4 in lib/bandit/pipeline.ex passes it to the application unchecked. A request line such as GET http://good.example@evil.example/x HTTP/1.1 with a valid Host header yields a conn.host of good.example@evil.example, and the same path admits NUL, DEL and non-ASCII bytes, invalid IP literals and ports outside 1..65535. The HTTP/1.0 clause needs no Host header at all, and CONNECT places the unparsed port string in conn.port.

Applications that build absolute URLs from conn.host, such as through Plug.Conn.request_url/1 or Phoenix URL helpers, emit links whose authority the attacker chose. Message framing is unaffected, and no CR or LF can reach conn.host.

This issue affects bandit: from 0.6.0 before 1.13.0.

Details

1. Request-target parsing (lib/bandit/http1/socket.ex)

:erlang.decode_packet/3 returns an absolute-form target as {:absoluteURI, scheme, host, port, path} and an authority-form (CONNECT) target as {:scheme, host, port}. resolve_request_target!/2 unwraps both into a {scheme, host, port, path} tuple and forwards host and port as received. validate_request_line!/2 only rejects bytes at or below 0x20 and 0x7F, so userinfo, delimiters, backslashes, bytes 0x80 to 0xFF, invalid IP literals and out-of-range ports pass. For CONNECT, port is the unparsed text after the first colon.

2. Host selection (lib/bandit/pipeline.ex)

determine_host_and_port!/4 has three clauses. The HTTP/1.1 clause calls required_host_header!/1, which parses the Host header with Bandit.Headers.parse_hostlike_header!/1 and raises a 400 on a malformed value, and then discards that result whenever target_host is set, returning to_string(target_host) and target_port instead. The fallback clause used for HTTP/1.0 and for CONNECT returns the target host and port directly and never consults the Host header. The precedence itself follows RFC 9112 section 3.2.2; the defect is that the value which wins is the one never validated.

3. Effect

build_conn!/6 places the pair into the URI from which Plug.Conn.Adapter.conn/5 builds conn.host and conn.port. The application therefore sees host values Bandit rejects on every other route into the same field, and for CONNECT a binary where Plug.Conn.port_number/0 promises an integer, which makes Plug.Conn.request_url/1 raise.

Proof of concept

1. Start Bandit over plaintext HTTP with a plug that returns conn.host and conn.port.
2. Open a raw TCP connection to the listener and send GET http://good.example@evil.example/x HTTP/1.1 followed by Host: good.example and an empty line. The response is 200 and conn.host is good.example@evil.example.
3. Repeat with GET http://ex\x00am.com/x HTTP/1.1 (a NUL byte in the authority) or GET http://ex.com:99999/x HTTP/1.1. Both are accepted, with the NUL byte in conn.host and 99999 in conn.port.
4. Send the same bytes in the Host header of an origin-form request instead. Bandit answers 400 for the NUL byte and the out-of-range port on 1.12.5, and for every payload once the Host grammar tightening on main is released.
5. Send GET http://good.example@evil.example/x HTTP/1.0 with no Host header, or CONNECT good.example@evil.example:443 HTTP/1.1. Both are accepted, and the CONNECT form leaves conn.port as the binary "443".

Impact

An unauthenticated client can make the application see any host string and any port number as the request's authority, bypassing the validation applied to the Host header. An application that builds absolute URLs from conn.host, such as password-reset or verification links, emits links whose host the attacker chose.

Workarounds

Add a plug ahead of any code that reads conn.host or conn.port that compares conn.host against an allow-list of the hostnames the application serves, checks that conn.port is an integer, and halts the request with a 400 response otherwise. Do not derive absolute URLs from conn.host until that check has passed.

Summary

Uncontrolled Resource Consumption vulnerability in mtrudel bandit allows an unauthenticated remote attacker to pin HTTP/2 stream processes indefinitely via a trickle of small WINDOW_UPDATE frames. A stream whose response outruns the connection or stream send window blocks until the peer grants more window, and each block carries a 15 second deadline. Both deadlines restart whenever the peer makes partial progress. Bandit.HTTP2.Connection.finish_data/5 re-queues a partially advanced send in pending_sends with a fresh expires_at, so every WINDOW_UPDATE on stream 0, and every SETTINGS frame, resets the clock. Bandit.HTTP2.Stream.send_data/3 recurses on each stream WINDOW_UPDATE and re-arms a fresh after read_timeout. A peer that grants a few bytes every few seconds keeps the blocked stream process, its Plug state and any resource it holds mid-response alive for as long as it keeps dripping, and repeats this across streams and connections to exhaust server processes and memory.

The two paths are independent. The stream-level block is reached on its own by widening the connection window with a large WINDOW_UPDATE on stream 0 and shrinking the per-stream window with a small SETTINGS_INITIAL_WINDOW_SIZE, so closing only the connection-level path leaves it exploitable.

This issue affects bandit: from 1.4.0 before 1.13.0.

Details

1. Connection-level block (lib/bandit/http2/connection.ex)

A send that outruns the connection send window is queued in pending_sends with an expires_at deadline computed in finish_data/5 as now plus @pending_send_timeout (15 seconds). expire_pending_sends/1 drops any queued send whose deadline has passed whenever data arrives on the connection. do_pending_sends/2 runs on every WINDOW_UPDATE on stream 0 and on every SETTINGS frame (including an empty one, through handle_frame/3). When the granted window is smaller than the queued remainder, the leftover is re-queued through finish_data/5, which recomputes expires_at from the current time instead of preserving the original deadline. Each partial advance therefore restarts the timer, and an empty SETTINGS frame restarts it without granting any window at all.

2. Stream-level block (lib/bandit/http2/stream.ex)

send_data/3 runs in the stream process. When the stream send window is exhausted it enters a receive that waits for {:bandit, {:send_window_update, delta}} with after stream.read_timeout (the struct default of 15 seconds, never overridden in init/5). On each stream WINDOW_UPDATE it applies the delta and recurses into send_data/3 with the remainder, which re-enters the same receive with a fresh after timeout. Each partial advance restarts the 15 second wait.

For the stream-level block to be the one stuck, the stream window must be exhausted while the connection window has room. The peer controls both: a large WINDOW_UPDATE on stream 0 opens the connection window, and a small SETTINGS_INITIAL_WINDOW_SIZE shrinks every stream window. Closing only the connection-level path therefore leaves the stream-level path fully exploitable.

3. Effect

The trickle also keeps the transport-level read timeout from firing, since the connection continuously receives valid frames. The blocked stream process, its Plug state, and anything it holds mid-response stay retained for as long as the peer keeps dripping, instead of being released after 15 seconds.

Proof of concept

Connection-level path:

1. Open a stream whose response exceeds the connection send window (65,535 bytes by default).
2. The server sends the window's worth and queues the remainder in pending_sends.
3. Send WINDOW_UPDATE for stream 0 with an increment of 1 every few seconds, or an empty SETTINGS frame. Each one re-queues the remainder with a fresh deadline, so expire_pending_sends/1 never expires it.

Stream-level path:

1. Send a large WINDOW_UPDATE for stream 0 so the connection window never blocks.
2. Advertise a small SETTINGS_INITIAL_WINDOW_SIZE so each stream window is tiny.
3. Request a response larger than the stream window. The server sends the window's worth and blocks in the recursive receive in send_data/3.
4. Send WINDOW_UPDATE for the stream with an increment of 1 at intervals shorter than 15 seconds. Each one re-arms a fresh read_timeout.
5. Repeat across streams, up to max_concurrent_streams per connection, and across connections.

Impact

A remote, unauthenticated peer requests a response larger than a send window, then drips tiny WINDOW_UPDATE frames every few seconds. Each blocked stream process, with its Plug state and any upstream connection or file handle it holds, stays alive for as long as the trickle continues. Repeated across many streams and connections this exhausts server processes and memory.

Workarounds

Disable HTTP/2 with http_2_options: [enabled: false], which removes both vulnerable paths. Alternatively, terminate HTTP/2 at a reverse proxy that enforces its own send timeouts and speaks HTTP/1 to Bandit.

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.

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.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to grow per-connection memory and CPU cost without bound via a large SETTINGS_HEADER_TABLE_SIZE. Bandit resizes its HPACK encoder table to whatever size the client advertises, up to 2^32-1 bytes, and indexes response headers into it. Because responses carry distinct values such as date or content-length, nothing is evicted and the table grows with every response for the life of the connection, while each lookup scans it linearly.

The SETTINGS handling in Bandit.HTTP2.Connection (lib/bandit/http2/connection.ex) passes remote_settings.header_table_size to HPAX.resize/2 with no server-side cap, and encode_headers encodes every response header as :store. Serving N responses on one connection therefore costs O(N²) CPU in the connection process.

This issue affects bandit: from 0.3.6 before 1.14.0.

Details

1. Table size (lib/bandit/http2/connection.ex)

On every SETTINGS frame, Bandit.HTTP2.Connection passes the peer's SETTINGS_HEADER_TABLE_SIZE straight to HPAX.resize/2 for the encoder table, accepting values up to 2^32-1. No server-side limit is applied.

2. Indexing

encode_headers encodes every response header as :store, adding it to the dynamic table. Headers whose values differ per response (date, content-length, set-cookie, x-request-id, a reflected location) produce new entries, and with a limit of about 4 GB none are evicted.

3. Cost

HPAX's lookup_by_header scans the table linearly for each header it encodes, so every response costs more than the one before it. Serving N responses on one connection costs O(N²) CPU in the connection process, and the table holds every entry for as long as the connection stays open.

Proof of concept

1. Open an HTTP/2 connection and advertise a SETTINGS_HEADER_TABLE_SIZE of 4294967295 in the initial SETTINGS frame.
2. Send cheap requests one after another on that connection, each to an endpoint whose response carries a header value that changes per request.
3. Time the round trips. In the reporter's run, the last 1,000 of 12,000 requests took 3.68 times as long as the first 1,000.

Impact

An unauthenticated remote client that keeps an HTTP/2 connection busy with cheap requests makes every response on it progressively more expensive, because the encoder table it enlarged never shrinks. Holding several such connections open ties up server CPU and memory for as long as the attacker keeps them alive.

Workarounds

From 0.7.0, cap the requests one HTTP/2 connection may serve, for example with http_2_options: [max_requests: 1000], so each connection and its encoder table is closed before the cost grows large. Alternatively, disable HTTP/2 with http_2_options: [enabled: false].

Summary

Improper Handling of Highly Compressed Data (Data Amplification) vulnerability in the HTTP/2 implementation of mtrudel bandit allows an unauthenticated remote attacker to exhaust server memory via a small HPACK-compressed HEADERS block. The block stores one large cookie value in the HPACK dynamic table and then references it tens of thousands of times with 1-byte indexed fields. In the reporter's run, a 49 KB block made a server with default settings allocate a 183 MB cookie binary before any application code ran, and every concurrent stream can repeat the cost.

Bandit.HTTP2.Connection caps only the compressed block (max_header_block_size), and its check of the decoded list against max_header_list_size never fires because that setting defaults to :infinity. combine_cookie_crumbs/1 in lib/bandit/http2/stream.ex then joins every crumb into one binary.

This issue affects bandit: from 0.3.3 before 1.14.0.

Details

1. Compression

The attacker's header block, split across HEADERS and CONTINUATION frames, stays under the 50,000-byte max_header_block_size. It inserts one 4,058-byte cookie into the 4,096-byte dynamic table, the largest value that fits, then references it about 45,000 times with 1-byte indexed representations. HPAX.decode returns a list whose entries all point at the same binary, so decoding itself stays cheap.

2. Missing decoded limit (lib/bandit/http2/connection.ex, lib/bandit/http2/settings.ex)

After decoding, the connection compares header_list_size(headers) against local_settings.max_header_list_size. That setting defaults to :infinity, and in Erlang term order every integer sorts below an atom, so the comparison never rejects a list. The limit is enforced only when an operator sets it.

3. Expansion (lib/bandit/http2/stream.ex)

read_headers calls combine_cookie_crumbs/1, which joins every crumb with Enum.map_join/3 into a single binary of about 183 MB before Plug.call/2 runs. max_concurrent_streams also defaults to :infinity, so N streams allocate N times as much.

Proof of concept

1. Against a Bandit server with default HTTP/2 settings, build an HPACK header block with the request pseudo-headers plus a 4,058-byte cookie stored in the dynamic table and then referenced about 45,000 times with indexed representations. The block is about 49 KB.
2. Send it on one stream as a HEADERS frame followed by CONTINUATION frames of at most 16,384 bytes, with END_HEADERS on the last.
3. The request reaches the plug with a cookie header of about 183 MB, and VM memory grows by about the same amount. Repeat on further streams to multiply it.

Impact

An unauthenticated remote client can make any Bandit server with default HTTP/2 settings allocate a cookie binary thousands of times larger than the header block it sent, before any application code runs. Repeating it across concurrent streams exhausts the BEAM node's memory, taking down every application on the node.

Workarounds

On 1.12.2 and later, set a finite decoded header list limit, for example http_2_options: [default_local_settings: [max_header_list_size: 65_536]], which resets the stream before the cookie crumbs are joined. From 0.7.0, disabling HTTP/2 with http_2_options: [enabled: false] removes the vulnerable path.

Summary

Improper Cleanup on Thrown Exception vulnerability in the HTTP/2 handler of mtrudel bandit allows an unauthenticated remote attacker to bypass per-connection resource limits via a single TCP write that carries several frames, one of which raises a stream error.

When a frame raises StreamError partway through a chunk, Bandit.HTTP2.Handler.handle_data/3 sends RST_STREAM and continues with the connection state from before the chunk, dropping the rest of it. Streams opened by earlier frames in the chunk keep running their Plug calls, but the stream counts, last_stream_id, the rapid-reset timestamps, the HPACK decoder state and the buffer roll back, so max_concurrent_streams, max_requests and the rapid-reset limiter never see those streams. A client that sends one HEADERS frame more than max_concurrent_streams in each write has the extra refused and the others forgotten: with a limit of 10, five such writes run 50 Plug calls at once.

This issue affects bandit: from 1.9.0 before 1.14.0.

Details

1. Function-level rescue. Bandit.HTTP2.Handler.handle_data/3 in lib/bandit/http2/handler.ex deserializes every frame in a TCP chunk inside an Enum.reduce_while/3 and wraps the whole function in a rescue. Inside that rescue, state is the original function argument, not the reduce_while accumulator.

2. Rollback on StreamError. When Bandit.HTTP2.Connection.handle_frame/3 raises StreamError partway through the chunk, rescue_stream_error/3 sends RST_STREAM and returns {:continue, state} with the connection as it was before the chunk. The rest of the chunk is dropped.

3. Lost bookkeeping. Frames already handled keep their side effects: their stream processes are running the Plug. But the stream counts, last_stream_id, reset_stream_timestamps, recv_hpack_state and buffer are rolled back, so max_concurrent_streams, max_requests and the rapid-reset limiter no longer count those streams. The same rollback drops HPACK table updates, which can mix up headers between requests, misaligns frame parsing, and sends a stale last_stream_id in GOAWAY.

Proof of concept

1. Run Bandit with a Plug that blocks until released and with http_2_options: [default_local_settings: [max_concurrent_streams: 10]].
2. Open an HTTP/2 connection with prior knowledge and complete the SETTINGS exchange.
3. In one TCP write, send 11 HEADERS frames with END_HEADERS and END_STREAM on streams 1, 3, ..., 21, each carrying a header block encoded without indexing. The eleventh is refused with REFUSED_STREAM, and the server forgets the ten streams before it.
4. Send the same write four more times. The Plug runs 50 times concurrently against a limit of 10.

Impact

An unauthenticated client can run more concurrent Plug calls on one HTTP/2 connection than the configured max_concurrent_streams allows (five times the limit in the reporter's test), tying up the server processes, CPU and memory the limit is meant to cap. Servers that serve HTTP/2 with a finite max_concurrent_streams are affected.

Workarounds

Disable HTTP/2 with http_2_options: [enabled: false], so that the vulnerable HTTP/2 handler never runs.