Bandit: Unauthenticated DoS via chunked request trailers in Bandit HTTP/1 decoder
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
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.
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:
"hello"0\r\nX-Trailer: 1\r\n\r\nThe 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.
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.
```elixir
# 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_b
This issue can be reached over the network, attack complexity is low, an attacker needs no privileges on the target. No user interaction is required. Rated impact: confidentiality none, integrity none, availability high.
The score comes from this vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
CVE-2026-39806 is classified as CWE-835: Infinite Loop. A loop condition can never become false for some inputs, hanging the process.
CVE-2026-39806 is recorded against 1 package.
Published on 19 May 2026 and last revised on 30 July 2026. A public exploit is known to exist, which raises the urgency of patching considerably. A vendor advisory or fix has been published. Record sourced from OSV.
github.com (Web)
nvd.nist.gov (Advisory)
github.com (Web)
cna.erlef.org (Web)
github.com (Package)
osv.dev (Web)
bandit has other advisories on record. If you are patching this one, these are worth checking on the same host:
These advisories are the same class of weakness (CWE-835: Infinite Loop) in other software:
Details
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N
Affected Packages
| Software | From version | Fixed in |
|---|---|---|
| bandit | — | — |
References
Similar Threats
Exploit Protection
CVE-2026-39806 carries CVSS 8.0 High rating and a public exploit already exists. BotEraser checks your installation against this and other known CVE records, and blocks IPs associated with exploit activity.
Check My Site For CVE-2026-39806 →No credit card required · Results in minutes
ⓘ Data Notice: The information presented above has been compiled from publicly available internet sources. Boteraser aggregates this data solely for informational purposes and does not independently classify, evaluate, or endorse any findings about the vulnerabilities listed. The accuracy and completeness of this information is the sole responsibility of the original publishers. Boteraser and its operators accept no liability for any decisions made based on this data.
Stay up to date with the latest from Boteraser.
We use cookies to improve your experience on our site. By using our site, you consent to cookies.
Manage your cookie preferences below:
Essential cookies enable basic functions and are necessary for the proper function of the website.
CloudFlare provides web performance and security solutions, enhancing site speed and protecting against threats.
Service URL: developers.cloudflare.com (opens in a new window)
These cookies are needed for adding comments on this website.
These cookies are used for managing login functionality on this website.
Statistics cookies collect information anonymously. This information helps us understand how visitors use our website.
Google Analytics is a powerful tool that tracks and analyzes website traffic for informed marketing decisions.
Service URL: policies.google.com (opens in a new window)
You can find more information in our Cookie Policy and Privacy Policy.