mtrudel bandit EUVD-2026-26712

The vulnerability requires a specific deployment topology and configuration misalignment: (1) Bandit must be deployed behind a reverse proxy or load balancer that processes duplicate Content-Length headers and selects the last value (rather than rejecting the request) - this includes certain nginx, Apache, or custom proxy configurations; (2) HTTP keep-alive connections must be enabled on both the proxy-to-Bandit link and the client-to-proxy link, allowing pipelined requests on the same connection; (3) the upstream application must process requests smuggled through the desynchronized framing without additional validation, and must lack independent rate-limiting or WAF rules at the Bandit layer. Bandit in isolation (without a problematic proxy) does NOT exhibit exploitable vulnerability - the attack requires the inconsistency between Bandit's first-value parsing and the proxy's last-value interpretation. Default Bandit configurations with compliant proxies (that reject duplicate Content-Length per RFC 9112) are NOT vulnerable. Authentication is NOT required - this is an unauthenticated network attack exploiting protocol interpretation differences.

CVSS 6.3 with AV:N/AC:L indicates network-accessible exploitation with low attack complexity, but the AT:P (Attack Timing Present) qualifier suggests timing constraints reduce real-world exploitability. The vulnerability requires precise coordination: the attacker must craft a request with two Content-Length headers with mismatched values AND position it behind a proxy that uses last-value semantics while Bandit uses first-value semantics - this is not a default HTTP behavior but rather a deployment-specific misconfiguration. EPSS data is not provided in input; however, the attack prerequisites (proxy misconfiguration + keep-alive enabled + downstream application processing smuggled requests) are common but not universal. The threat model is clear: request smuggling can bypass rate limiting, path-based access controls (e.g., /admin routes), and WAF inspection, but only when both Bandit and an upstream proxy exhibit the divergent interpretation simultaneously. The RFC 9112 compliance fix (commit f2ca636) changes Bandit to explicitly reject all duplicate Content-Length headers with a 400 error, eliminating the vulnerability entirely. This is a real issue for deployments matching the proxy-Bandit stack, but not a remote code execution or authentication bypass on Bandit alone. Risk is HIGH for affected deployments (edge proxies + Bandit); MEDIUM-LOW for general Internet-facing Bandit instances without problematic proxies.

An attacker crafts an HTTP POST request with two Content-Length headers: 'Content-Length: 50' and 'Content-Length: 1000', followed by 1000 bytes of body data (200 bytes of legitimate request + 800 bytes of smuggled payload). The request is sent to a reverse proxy configured to use the last Content-Length value (e.g., nginx with a default or misconfigured setup). The proxy forwards the entire 1000-byte body to Bandit. Bandit reads only the first 50 bytes as the request body (using the first header), leaving 950 bytes (the smuggled payload) in the keep-alive connection buffer. When the same connection is reused, Bandit interprets the remaining 950 bytes as a new HTTP request. If the smuggled payload contains a request targeting an /admin route with elevated privileges, it bypasses WAF inspection (which only saw the original 50-byte request) and rate-limiting counters applied to the first request. This allows unauthorized actions on the backend application.