Mat Trudel

**Name of the Vulnerable Software and Affected Versions** bandit versions 1.4.0 through 1.12.4 **Description** 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. **Recommendations** Update bandit to version 1.12.5 or later.

**Name of the Vulnerable Software and Affected Versions** bandit versions 0.3.4 through 1.12.4 **Description** 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. **Recommendations** Update bandit to version 1.12.5 or later.

**Name of the Vulnerable Software and Affected Versions** bandit versions 1.11.0 through 1.12.0 **Description** 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. **Recommendations** Update bandit to version 1.12.1.

**Name of the Vulnerable Software and Affected Versions** bandit versions 1.4.0 through 1.11.0 **Description** 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. **Recommendations** Update bandit to version 1.11.1.

**Name of the Vulnerable Software and Affected Versions** bandit versions 1.6.1 through 1.11.0 **Description** 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. **Recommendations** Update bandit to version 1.11.1.

**Name of the Vulnerable Software and Affected Versions** bandit versions 0.5.9 through 1.10.x **Description** 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. **Recommendations** Update to version 1.11.0 or later. As a temporary workaround, do not pass `compress: true` to `WebSockAdapter.upgrade/4` or set it to false to prevent permessage-deflate negotiation.

**Name of the Vulnerable Software and Affected Versions** bandit versions prior to 1.11.0 **Description** Inconsistent interpretation of HTTP requests allows HTTP request smuggling via duplicate Content-Length headers. The function `get content length()` in `Elixir.Bandit.Headers` uses `List.keyfind/3`, which only returns the first matching header. If a request contains two Content-Length headers with different values, the system accepts it, uses the first value to read the body, and treats the remaining bytes as a second pipelined request on the same keep-alive connection. This behavior contradicts RFC 9112 §6.3, which requires such cases to be treated as unrecoverable framing errors. When positioned behind a proxy that selects the last Content-Length value, an unauthenticated attacker can smuggle requests to bypass edge WAF rules, path-based ACLs, rate limiting, and audit logging. **Recommendations** Update to version 1.11.0 or later.

**Name of the Vulnerable Software and Affected Versions** bandit versions 0.5.0 through 1.10.x **Description** An allocation of resources without limits or throttling allows unauthenticated remote denial of service via memory exhaustion. The fragment reassembly path in the `handle frame/3` function within 'Elixir.Bandit.WebSocket.Connection' appends every incoming Continuation frame payload where `fin` is false to a per-connection iolist without a cumulative size cap. While the `max frame size` option limits individual frames, a remote actor can stream an unbounded number of continuation frames without setting `fin=1`, causing the BEAM heap to grow linearly until the process is terminated by the operating system or a supervisor. This accumulation occurs before the `handle in/2` function is called, preventing the application from implementing a size check. Consequently, stock Phoenix applications using Phoenix Channels or LiveView are exposed upon accepting socket connections. This issue specifically affects applications that accept WebSocket connections. **Recommendations** Update bandit to version 1.11.0 or later. As a temporary mitigation, disable WebSocket endpoints if they are not required by the application.

**Name of the Vulnerable Software and Affected Versions** bandit versions 1.0.0 through 1.10.f **Description** Reliance on untrusted inputs in a security decision allows unauthenticated transport-state spoofing on plaintext HTTP connections. The function `determine scheme/2` in `Elixir.Bandit.Pipeline` returns the client-supplied URI scheme verbatim, ignoring the transport's secure flag. This occurs because HTTP/1.1 absolute-form request targets and the HTTP/2 `:scheme` pseudo-header are attacker-controlled strings. Consequently, a client can declare https over a plaintext TCP connection, leading the system to set `conn.scheme` to `:https` without TLS negotiation. This misleads downstream Plug consumers, causing Plug.SSL to skip HTTP to HTTPS redirects, secure cookies to be sent over plaintext, audit logs to incorrectly record HTTPS usage, and CSRF or SameSite gating to make incorrect decisions. This issue specifically affects systems accepting plaintext HTTP connections, either directly or via h2c (HTTP/2 over TCP without TLS). **Recommendations** Update bandit to version 1.11.0 or later.

**Name of the Vulnerable Software and Affected Versions** bandit versions 0.3.6 through 1.10.x **Description** An issue in the `deserialize/2` function within `Elixir.Bandit.HTTP2.Frame` allows unauthenticated memory exhaustion through oversized HTTP/2 frames. The system checks the `SETTINGS MAX FRAME SIZE` limit only after pattern-matching the payload size, requiring the entire frame body to be present in memory before the size guard is evaluated. This allows a peer to announce a frame length up to the 24-bit maximum (approximately 16 MiB), forcing the server to buffer the entire body regardless of the negotiated `max frame size`. An attacker maintaining multiple concurrent connections can cause significant memory pressure, leading to a denial of service. **Recommendations** Update to version 1.11.0 or later.