Mat Trudel

An unauthenticated remote attacker can exhaust server memory by sending a request body composed of numerous 1-byte DATA frames. The issue occurs in the HTTP/2 request body reader where the `do read data/5` function in `lib/bandit/http2/stream.ex` stores every DATA frame payload as an individual list element until the read operation returns. Because the `:length` option of `read body/2` tracks the total number of bytes rather than the number of frames, a high volume of small frames creates significant memory overhead per byte. This effect is amplified when frames are interleaved across up to 500 concurrent streams per connection. This issue affects any route where the Plug reads the request body, including those using `Plug.Parsers` for POST, PUT, and PATCH requests.

An unauthenticated remote attacker can exhaust server memory by sending DATA frames that exceed the advertised receive window in the HTTP/2 implementation. The attacker can request a response larger than the 65,535-byte initial window and withhold `WINDOW UPDATE`, causing the stream process to block while sending and stop reading. Subsequently, flooding small DATA frames on that stream causes every frame to be queued in the stream's mailbox until the BEAM node runs out of memory. This occurs because `Bandit.HTTP2.Connection.handle frame/3` forwards DATA frames 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, failing to trigger a `FLOW CONTROL ERROR` upon violation.

An inefficient algorithmic complexity issue in the HTTP/2 implementation allows an unauthenticated remote attacker to exhaust server CPU resources. By opening thousands of streams that block on the connection send window and subsequently sending small SETTINGS or connection-level WINDOW UPDATE frames, an attacker can force the server to perform quadratic O(n²) list operations. This occurs because the `do pending sends/2` function in `lib/bandit/http2/connection.ex` retries every queued send and removes entries using `List.delete/2`, causing the server to walk the entire queue of blocked sends for each frame. The impact is amplified because `max concurrent streams` defaults to `:infinity`, allowing the attacker to control the number of blocked streams.

An unauthenticated remote attacker can cause server memory exhaustion through a data amplification issue in the HTTP/2 implementation. By sending a small HPACK-compressed HEADERS block that stores a large `cookie` value in the HPACK dynamic table and references it tens of thousands of times, the attacker can force the server to allocate a massive binary. This occurs because `Bandit.HTTP2.Connection` only limits the compressed block size via `max header block size`, while the `max header list size` setting defaults to `:infinity`, failing to reject the expanded list. The function `combine cookie crumbs/1` in `lib/bandit/http2/stream.ex` then joins these references into a single large binary. Since `max concurrent streams` also defaults to `:infinity`, multiple concurrent streams can multiply this memory consumption, potentially crashing all applications on the BEAM node.

An issue in the WebSocket connection handling allows a remote client to continue executing handler code after the server has attempted to stop the connection. This occurs because when a callback returns `{:stop, ...}`, the `Bandit.WebSocket.Connection` process enters a `:closing` state but continues to process incoming data frames and messages. The functions `handle frame/3` and `handle info/3` do not verify the connection state, allowing frames to reach `handle in/2` and messages to reach `handle info/2` until the client sends a Close frame, the TCP connection drops, or an idle timeout occurs. This can lead to the bypass of authorization checks in `init/1` or the evasion of session terminations such as kicks or bans, potentially allowing unauthorized access to administrative actions.

An unauthenticated remote attacker can cause unbounded growth of per-connection memory and CPU usage in the HTTP/2 implementation. This occurs because the software resizes its HPACK encoder table based on the `SETTINGS HEADER TABLE SIZE` advertised by the client without applying a server-side cap, allowing sizes up to 2^32-1 bytes. Since response headers with distinct values like `date` or `content-length` are indexed and not evicted, the table grows with every response. Consequently, the `lookup by header` function in the HPAX library scans the table linearly, resulting in O(N²) CPU cost for serving N responses on a single connection. The issue is located in the `Bandit.HTTP2.Connection` (`lib/bandit/http2/connection.ex`) where `remote settings.header table size` is passed to `HPAX.resize/2`, and the `encode headers` function encodes every response header as `:store`.

An unauthenticated remote attacker can exhaust server memory and CPU resources by sending a request body composed of numerous 1-byte chunks. The issue exists in the HTTP/1.1 chunked body reader within `lib/bandit/http1/socket.ex`, which stores every chunk as an individual list cell and binary term until they are joined by the `IO.iodata to binary/1` function. Because the `:length` option of the `read body/2` function only counts data bytes and does not limit the total number of chunks, small chunks consume significantly more memory than their actual payload. This can occur even if the route does not explicitly read the body, as the `ensure completed/1` function drains unread bodies on keep-alive connections.

An improper cleanup process during thrown exceptions in the HTTP/2 handler allows an unauthenticated remote attacker to bypass per-connection resource limits. When a frame raises a `StreamError` during the processing of a TCP chunk, the `handle data/3` function in `Bandit.HTTP2.Handler` sends a RST STREAM and reverts the connection state to its condition before the chunk was processed. While streams opened by earlier frames in the chunk continue to execute their Plug calls, the internal bookkeeping—including stream counts, `last stream id`, rapid-reset timestamps, and the HPACK decoder state—is rolled back. Consequently, the `max concurrent streams`, `max requests`, and rapid-reset limiter fail to account for these active streams, allowing a client to exceed the configured concurrency limits and exhaust server CPU and memory resources.

An unauthenticated remote attacker can cause excessive server CPU consumption due to inefficient algorithmic complexity in the header integer parser. The function `Bandit.Headers.parse integer/2` in `lib/bandit/headers.ex` processes numbers one digit at a time without a limit on the digit count, allocating a new bignum at each step. This results in processing time that is quadratic relative to the length of the input. The issue is triggered by providing a `content-length` value or a `Host` or `:authority` port consisting of thousands of digits. This occurs on raw request input over HTTP/1 and HTTP/2 before any range checks are performed. In HTTP/2 environments, an attacker can use HPACK dynamic table storage to amplify the effect, sending a large value once and referencing it in subsequent streams to keep the server busy with minimal traffic.

An unauthenticated remote attacker can exhaust server memory through the WebSocket fragment reassembly process. The `Bandit.WebSocket.Connection` function checks the `max fragmented message size` variable against the received payload bytes but does not limit the total number of fragments. By sending a fragmented message consisting of numerous 1-byte continuation frames, an attacker can consume significantly more memory than the configured limit. For instance, a 1-byte fragment requires approximately 150 to 170 bytes of server memory. Additionally, sending Ping frames between fragments allows the connection to remain active beyond the idle timeout.

An inconsistent interpretation of HTTP requests, known as HTTP Request/Response Smuggling, exists in the HTTP/1.1 chunked body reader. This allows an unauthenticated remote attacker to smuggle a second request past a front-end proxy by using a chunk extension containing a bare LF (Line Feed). The issue occurs in the `lib/bandit/http1/socket.ex` file, where the chunked reader accepts the chunk-size line up to the first CRLF and discards content after the `;` character without validating it against the RFC 9112 `chunk-ext` grammar. Consequently, control bytes like bare LF and bare CR are permitted. If a front-end proxy treats a bare LF as a line ending, it may interpret the stream as a single request, while Bandit interprets it as a separate pipelined request, potentially bypassing proxy access controls. This issue only affects deployments using a front-end proxy that treats a bare LF as a line ending and forwards chunked bodies unchanged.

An unauthenticated remote attacker can hold stream processes open indefinitely in the HTTP/2 request body reader. This occurs because the `do read data/4` function in `lib/bandit/http2/stream.ex` resets the `read timeout` countdown whenever a WINDOW UPDATE or an empty SETTINGS frame is received. Since these frames do not deliver body data but still end the wait period, a client can send these 9-byte frames repeatedly to keep `read body` blocked. This allows the attacker to occupy the stream process and any resources held by the application during the read operation across multiple streams and connections.

An unauthenticated remote attacker can set `conn.host` and `conn.port` to values that violate the RFC 3986 host grammar by using the authority of an HTTP/1 absolute-form or authority-form request target. While the software validates the `Host` header and returns a 400 error if it is malformed, the authority within the request target takes precedence per RFC 9112. The function `determine host and port!/4` in `lib/bandit/pipeline.ex` passes this authority to the application without validation. This allows the injection of NUL, DEL, and non-ASCII bytes, invalid IP literals, and ports outside the 1..65535 range. Applications that construct absolute URLs using `conn.host`, such as through `Plug.Conn.request url/1` or Phoenix URL helpers, may emit links with an attacker-controlled authority. For `CONNECT` requests, the unparsed port string is placed in `conn.port`, which may cause `Plug.Conn.request url/1` to raise an error as `Plug.Conn.port number/0` expects an integer.

Uncontrolled resource consumption allows an unauthenticated remote attacker to pin HTTP/2 stream processes indefinitely. By sending a trickle of small `WINDOW UPDATE` frames or empty `SETTINGS` frames, an attacker can reset the 15-second deadline for blocked stream processes. This occurs through two independent paths: one where `Bandit.HTTP2.Connection.finish data/5` re-queues partially advanced sends in `pending sends` with a fresh `expires at` timestamp, and another where `Bandit.HTTP2.Stream.send data/3` recurses on each stream `WINDOW UPDATE` and re-arms a fresh `read timeout`. This behavior keeps the blocked stream process, its Plug state, and associated resources alive, potentially exhausting server processes and memory.

An improper neutralization of CRLF sequences allows an unauthenticated remote attacker to smuggle Carriage Return (CR), Line Feed (LF), or Null (NUL) characters into application-visible request headers via HTTP/2. The function `Bandit.HTTP2.Stream.read headers/1` validates pseudo-header placement, uniqueness, header-name casing, connection-specific headers, the `te` value, and `content-length`, but fails to check field values. Since HPACK carries arbitrary octets, a HEADERS block containing `r`, ` `, or `0` decodes without error, and these values are placed in `conn.req headers` unchanged. While the HTTP/1 path rejects these octets, the HTTP/2 path does not. The risk occurs when a downstream application consumes these header values, such as by appending them to a plain-text log or concatenating them into an upstream request. Additionally, a duplicate `:authority` pseudo-header could be accepted, where the first instance is used as `conn.host` while a conflicting value remains visible to the application.

An unauthenticated remote attacker can pin an unbounded number of HTTP/2 stream processes indefinitely by exploiting connection-level flow control. When a stream response body exceeds the HTTP/2 connection-level send window, the `Bandit.HTTP2.Connection` queues the remaining bytes and a reply closure in `pending sends`, causing the stream process to block forever during a synchronous call to the connection process. Because there is no bound on this wait and the queue is not purged, client `RST STREAM` requests are never read, and periodic PING frames prevent transport-level read timeouts from triggering. This allows an attacker to pin processes, Plug state, and associated resources, such as pooled upstream connections in a reverse-proxy Plug, by targeting endpoints with responses larger than the connection window and maintaining the connection with PINGs.

An inefficient algorithmic complexity issue allows unauthenticated remote denial of service via CPU exhaustion during WebSocket fragment reassembly. The function `oversize message?/2`, called from `handle frame/3` in `lib/bandit/websocket/connection.ex`, appends non-final continuation frames to a left-nested iolist and re-measures the entire buffer using `IO.iodata length/1` for every frame. This results in quadratic (O(n^2)) reassembly work relative to the number of continuation frames. While the `max fragmented message size` limit restricts total bytes, it does not limit the frame count. An attacker can send numerous small continuation frames to exhaust CPU resources, potentially starving the server and denying service to legitimate users. This issue specifically affects applications serving WebSocket endpoints through Bandit, including Phoenix applications using Bandit as the HTTP adapter.

An unauthenticated remote attacker can cause a denial of service via memory exhaustion. The `read data/2` function in `Elixir.Bandit.HTTP1.Socket` ignores the `:length` option when processing HTTP/1 chunked request bodies. Specifically, the `do read chunked data!/5` function buffers every received chunk into an iolist without capping the accumulated body at the configured limit, materializing the entire body as a single binary. Since this process occurs before routing and authentication in standard Phoenix endpoints, sending a single POST request with a `Transfer-Encoding: chunked` header and an arbitrarily large body can exhaust the BEAM process memory, leading to termination by the operating system's Out-Of-Memory (OOM) killer.

An infinite loop in the `do read chunked data!/5` function within `lib/bandit/http1/socket.ex` allows unauthenticated remote attackers to cause a denial of service via worker process exhaustion. The issue occurs because the function only terminates when the last-chunk line is immediately followed by an empty trailer line, whereas RFC 9112 §7.1.2 allows for zero or more trailer fields. When trailers are present, the process enters a state where it tail-recurses with unchanged state, pinning the worker process for the duration of the TCP connection. A small number of concurrent RFC-conformant chunked requests containing trailer fields can exhaust the worker pool, rendering the server unresponsive. This can occur even with legitimate traffic forwarded by proxies like NGINX and HAProxy.

An unauthenticated remote attacker can cause a denial of service via memory exhaustion when WebSocket permessage-deflate compression is enabled. The issue occurs because the `inflate/2` function in `Elixir.Bandit.WebSocket.PerMessageDeflate` calls `:zlib.inflate/2` without an output-size cap and materializes the decompressed payload as a single binary using `IO.iodata to binary/1`. While `websocket options.max frame size` limits the compressed frame size, it does not limit the decompressed output. Consequently, a high-ratio compressed frame can force GiB-scale heap allocations, exhausting the BEAM node's memory and triggering an Out-Of-Memory (OOM) kill. This requires both the server-level `websocket options.compress` and the per-upgrade `compress: true` option in `WebSockAdapter.upgrade/4` to be enabled.