Bandit EUVD-2026-109825

Exploitation requires that the target run Bandit (1.9.0 up to but not including 1.14.0) serving HTTP/2 with a finite max_concurrent_streams - HTTP/2 is served by default on Bandit's HTTPS/h2 listeners and max_concurrent_streams has a default value, so default HTTP/2 deployments are exploitable without special configuration. The attacker must craft a single TCP write carrying multiple HEADERS frames where at least one frame raises a StreamError (per the advisory, a header block encoded without indexing), which causes handle_data/3 to roll back connection state. No authentication, user interaction, or local access is needed (PR:N/UI:N). The principal limiting factor is that only the HTTP/2 handler is affected: deployments that disable HTTP/2 (http_2_options: [enabled: false]) are not exploitable, and HTTP/1-only listeners are unaffected. Impact is confined to availability (process/CPU/memory exhaustion); no data confidentiality or integrity is at stake.

This is a genuine but bounded availability issue rather than a top-tier emergency. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N) and score of 8.2 reflect a network-reachable, unauthenticated flaw whose only impact is availability (VA:H; VC:N/VI:N), which matches the described mechanism: an attacker bypasses the per-connection max_concurrent_streams / max_requests / rapid-reset limits and runs far more concurrent Plug calls than configured, exhausting processes, CPU and memory. The priority signal is 'this_week' (vuln.today), consistent with a serious DoS-class bug that is not under active exploitation. There is NO CISA KEV listing and NO EPSS score in the provided data, so widespread automated exploitation is not evidenced - this points to a defensible-but-not-firefight posture. A detailed proof-of-concept is published in the GHSA advisory (deterministic steps: configure max_concurrent_streams, send 11 HEADERS frames per TCP write, repeat), which lowers the practical barrier to exploitation. One caveat to flag explicitly: the input tag 'Authentication Bypass' conflicts with the actual mechanism - the CVSS shows PR:N and VC:N/VI:N, and the advisory describes a resource-limit bypass, not any authentication bypass, so that tag is misleading. Overall: real priority for Elixir/Phoenix shops running HTTP/2, but severity rests entirely on availability, not data compromise.

An unauthenticated remote attacker opens an HTTP/2 connection to a Bandit server and sends a single TCP write containing several HEADERS frames where the last one triggers a StreamError; the server refuses the final stream but forgets the earlier ones, so their Plug calls keep running while the connection's limit bookkeeping rolls back. By repeating this write the attacker accumulates many more concurrent requests than max_concurrent_streams permits on one connection, exhausting server processes, CPU and memory. A public PoC reference exists in the vendor advisory describing the exact frame sequence; it is not verified as working exploit code in the provided data.