bandit EUVD-2026-63661

The vulnerability requires the target server to be running bandit version 1.4.0 through 1.12.4 with HTTP/2 enabled (the HTTP/1 code path already rejected the same characters). No authentication is required and no non-default configuration is needed for the injection itself to succeed - any HTTP/2 client can send a HEADERS frame with \r, \n, or \0 in a field value. However, the prerequisite for actual harm is that the downstream application code consumes raw header values in a way that is sensitive to these control characters: specifically, appending header values verbatim to plain-text logs (enabling log injection) or concatenating them into outbound HTTP/1.1 upstream request headers (enabling request smuggling). Applications that do not perform these operations are not materially harmed by the injection. The duplicate :authority condition additionally requires an attacker to send two :authority pseudo-headers in the same HEADERS frame, which is trivially constructable by any HTTP/2 client but requires the application to act on the second (non-winning) :authority value to cause harm.

The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N) scores 6.9 and accurately reflects the attack surface: fully network-reachable, no authentication or complexity barrier, but with impact limited to low integrity on the vulnerable system. EPSS data was not provided; absent KEV listing and with no publicly referenced POC, opportunistic mass exploitation is unlikely at time of analysis. The RCE tag attached to this CVE in the source data is not supported by the description - bandit itself is explicitly not a sink for the injected bytes, and the description rules out response splitting through bandit's own response-header path. The realistic risk lives entirely in how downstream application code consumes raw header values: a Phoenix application that appends an X- header verbatim to a structured log line or forwards it into an HTTP/1.1 upstream request is genuinely vulnerable to log injection or request smuggling respectively, but the severity of that outcome is application-dependent. Operators running bandit-backed services that proxy, log, or relay header values verbatim should treat this as a concrete integrity risk; those whose applications do not touch raw header values in those ways face negligible real-world exposure. The CVSS integrity impact of 'Low' (VI:L) and the absence of any confidentiality or availability metrics are consistent with the description. No conflict between CVSS signals and description is present, though the absence of EPSS data limits quantitative exploitation-probability assessment.

An attacker sends an HTTP/2 HEADERS frame to a bandit server where one field value - for example, x-forwarded-for - contains an embedded LF followed by a fabricated header line such as x-injected: malicious. Because bandit does not validate field values in its HTTP/2 path, HPACK decodes the frame without error and the raw value (including the embedded LF) is placed into conn.req_headers. A downstream Phoenix controller that logs this header verbatim, or a reverse-proxy plug that forwards it in an HTTP/1.1 upstream request, receives the injected control characters and interprets the LF as a header delimiter, enabling log injection or request smuggling. No POC has been publicly identified at time of analysis.