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.
{
"osv_generated_from": "https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/75xxx/CVE-2026-75484.json",
"unresolved_ranges": [
{
"source": "AFFECTED_FIELD",
"extracted_events": [
{
"introduced": "fff06efe3be962b484bd4d3eb339372fda5a231f"
},
{
"fixed": "d38cf046c9a3cae4d0f88001c2ceb4143f86366b"
}
]
}
],
"cwe_ids": [
"CWE-93"
],
"cna_assigner": "EEF"
}