Bandit CVE-2026-111101

Requires only that the target run Bandit (>= 0.1.0, < 1.14.0) with HTTP/1.1 accepted, which is the default; the attacker sends one unauthenticated POST with Transfer-Encoding: chunked whose body is many 1-byte chunks. No authentication (PR:N), no user interaction (UI:N), and no special route behavior are needed - the vulnerable chunked reader is reached even by routes that never call read_body, because on keep-alive connections ensure_completed/1 drains unread bodies through the same path. The only limiting factor is HTTP/1.1 reachability: per the advisory, from version 0.7.0 a deployment whose clients and proxies all speak HTTP/2 can set http_1_options: [enabled: false] so the vulnerable reader never runs; otherwise the vendor fix in 1.14.0 is the remedy.

This is a real, prioritizable availability issue but not a top-tier emergency. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) is confirmed by the input and is internally consistent with the description: an unauthenticated remote attacker over the network, with low complexity and no user interaction, can trigger the flaw, and impact is confined to availability (VA:H; VC/VI/VA show no confidentiality or integrity loss), which matches a CWE-770 resource-exhaustion DoS. The vuln.today decision label is 'this_week' rather than act_now/emergency, so the urgency is elevated but routine patch-cycle, not drop-everything. No EPSS score and no CISA KEV entry are provided, so there is no evidence of active exploitation or a quantified exploitation probability - absence of these is not itself a defect, but it means the priority rests on the CVSS/SSVC-style signals plus the detailed PoC in the vendor advisory. The GHSA advisory includes concrete reproduction steps and measured amplification (a 1 MB body holding ~48 MB; ~417 MB from a route that never reads the body), so a public PoC reference exists; it is not verified as working exploit code. Net: credible, cheap-to-launch unauthenticated memory/CPU amplification against any Bandit server accepting HTTP/1.1, with a confirmed fix - patch on a near-term schedule consistent with the 'this_week' label.

An unauthenticated attacker sends a single HTTP/1.1 POST with Transfer-Encoding: chunked whose body is composed of a large number of 1-byte chunks (e.g. ~1,000,000 chunks of '1\r\nA\r\n' then '0\r\n\r\n'). Because each chunk is retained as its own list cell and binary term until IO.iodata_to_binary joins them, and :length only caps data bytes, the handler process balloons to many times the payload size (~48 MB held for a 1 MB body) and burns seconds of CPU, exhausting memory even against routes that never read the body. A detailed proof-of-concept with these exact steps is published in the GHSA advisory.