CVE-2026-75484: HTTP/2 header field values containing CR, LF or NUL are passed to the application unvalidated in Bandit
Improper Neutralization of CRLF Sequences ('CRLF Injection') vulnerability in mtrudel bandit allows an unauthenticated remote attacker to smuggle CR, LF, or NUL characters into application-visible request headers via HTTP/2. Bandit.HTTP2.Stream.readheaders/1 validates pseudo-header placement and uniqueness, header-name casing, connection-specific headers, the te value, and content-length, but never checks field values. Because HPACK carries arbitrary octets, a HEADERS block whose field values contain \r, \n, or \0 decodes without error and the values land in conn.reqheaders unchanged. The HTTP/1 path already rejects the same octets; HTTP/2 did not.
Bandit itself is not a sink for the injected bytes: its own logging uses fixed strings or inspect, and HTTP/2 response headers are HPACK-encoded and separately rejected by Plug's putrespheader, so response splitting is not reachable through this path. The risk is entirely in how a downstream application consumes header values, such as appending one verbatim to a plain-text log or concatenating it into an upstream request. A related gap bundled in the same fix: only :method, :scheme, and :path were checked for at most one occurrence; a duplicate :authority pseudo-header was accepted, with the first instance silently winning as conn.host while a conflicting value remained visible to the application.
This issue affects bandit: from 1.4.0 before 1.12.5.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
banditto a version that resolves this vulnerability.Fixed in 1.12.5
Event History
Frequently Asked Questions
Who is exposed to this issue?
Applications using Bandit's HTTP/2 request handling are exposed if they consume request header values in a way that treats them as safe text. The attacker is unauthenticated and remote, but the practical impact depends on downstream application handling.
What does an attacker need to do to exploit it?
An attacker needs to send an HTTP/2 HEADERS block with a header field value containing carriage return, line feed, or NUL bytes. HPACK permits arbitrary octets, allowing those values to reach conn.req_headers unchanged.
What downstream application behavior creates risk?
Risk arises when an application uses a received header value verbatim, such as appending it to a plain-text log or concatenating it into an upstream request. Bandit's own logging and HTTP/2 response-header handling are not identified as exploitable sinks through this path.
Is the same input accepted over HTTP/1?
No. The HTTP/1 path already rejects these octets in header values; the validation gap is specific to HTTP/2.