GHSA-c67r-gc9j-2qf7: Bandit is vulnerable to CL.CL request smuggling via unrejected duplicate `Content-Length` header
SummaryBandit 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/e5270b1b19e9f3574aa0f87ec76851d66c38c0afDetails`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.PoCThe 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.ImpactSpec 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
CVSS v4.0: 6.3