Mat Trudel

**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 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.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 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.

**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 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.