{"id":"CVE-2026-75484","aliases":["EEF-CVE-2026-75484","EUVD-2026-63661","GHSA-23xx-x3px-xxpj","GHSA-x3gh-xhj4-3vq8"],"status":"published","title":"HTTP/2 header field values containing CR, LF or NUL are passed to the application unvalidated in Bandit","description":"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.read_headers/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.req_headers unchanged. The HTTP/1 path already rejects the same octets; HTTP/2 did not.\n\nBandit 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 put_resp_header, 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.\n\nThis issue affects bandit: from 1.4.0 before 1.12.5.","severity":{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-09","score":0.00709,"percentile":0.53759,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-93"],"published":"2026-08-20T21:11:27Z","modified":"2026-10-28T02:31:06Z","fixes":[{"ecosystem":"Hex","package":"bandit","fixed_in":["1.12.5"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Hex","package":"bandit","ranges":[{"type":"SEMVER","events":[{"introduced":"1.4.0"},{"fixed":"1.12.5"}]}],"versions":["1.10.0","1.10.1","1.10.2","1.10.3","1.10.4","1.11.0","1.11.1","1.12.0","1.12.1","1.12.2","1.12.3","1.12.4","1.4.0","1.4.1","1.4.2","1.5.0","1.5.1","1.5.2","1.5.3","1.5.4","1.5.5","1.5.6","1.5.7","1.6.0","1.6.1","1.6.10","1.6.11","1.6.2","1.6.3","1.6.4","1.6.5","1.6.6","1.6.7","1.6.8","1.6.9","1.7.0","1.8.0","1.9.0"]}],"products":[{"vendor":"mtrudel","product":"bandit"}],"references":[{"url":"https://github.com/mtrudel/bandit/security/advisories/GHSA-x3gh-xhj4-3vq8","tags":["vendor-advisory","related","exploit","advisory"]},{"url":"https://cna.erlef.org/cves/CVE-2026-75484.html","tags":["related","web"]},{"url":"https://osv.dev/vulnerability/EEF-CVE-2026-75484","tags":["related","web"]},{"url":"https://github.com/mtrudel/bandit/commit/d38cf046c9a3cae4d0f88001c2ceb4143f86366b","tags":["patch","fix"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-75484","tags":["advisory"]},{"url":"https://github.com/advisories/GHSA-23xx-x3px-xxpj"},{"url":"https://github.com","tags":["web"]},{"url":"https://repo.hex.pm","tags":["web"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/75xxx/CVE-2026-75484.json","tags":["advisory"]},{"url":"https://github.com/mtrudel/bandit","tags":["package"]},{"url":"https://hex.pm/packages/bandit","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-75484","title":"HTTP/2 header field values containing CR, LF or NUL are passed to the application unvalidated in Bandit","description":"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.read_headers/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.req_headers unchanged. The HTTP/1 path already rejects the same octets; HTTP/2 did not.\n\nBandit 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 put_resp_header, 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.\n\nThis issue affects bandit: from 1.4.0 before 1.12.5.","status":"published","published":"2026-08-20T21:11:27.523Z","modified":"2026-08-21T19:52:42.954Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"medium","assessor":"cna"}],"cwes":["CWE-93"],"updated_at":"2026-11-02T14:20:07.260654Z"}],"euvd":[{"id":"EUVD-2026-63661","description":"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.read_headers/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.req_headers unchanged. The HTTP/1 path already rejects the same octets; HTTP/2 did not.\n\nBandit 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 put_resp_header, 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.\n\nThis issue affects bandit: from 1.4.0 before 1.12.5.","status":"published","published":"2026-08-20T21:11:27Z","modified":"2026-08-21T19:52:42Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"medium"}],"updated_at":"2026-11-02T18:01:36.844009Z"}],"ghsa":[{"id":"GHSA-23xx-x3px-xxpj","title":"Improper Neutralization of CRLF Sequences ('CRLF Injection') vulnerability in mtrudel bandit...","description":"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.read_headers/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.req_headers unchanged. The HTTP/1 path already rejects the same octets; HTTP/2 did not.\n\nBandit 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 put_resp_header, 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.\n\nThis issue affects bandit: from 1.4.0 before 1.12.5.","status":"published","published":"2026-08-20T21:31:29Z","modified":"2026-08-20T21:31:36Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"medium"}],"cwes":["CWE-93"],"updated_at":"2026-11-02T15:10:48.274578Z"}],"nvd":[{"id":"CVE-2026-75484","description":"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.read_headers/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.req_headers unchanged. The HTTP/1 path already rejects the same octets; HTTP/2 did not.\n\nBandit 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 put_resp_header, 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.\n\nThis issue affects bandit: from 1.4.0 before 1.12.5.","status":"published","published":"2026-08-20T21:17:09.597Z","modified":"2026-10-18T20:10:00.11Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"medium","assessor":"secondary"}],"cwes":["CWE-93"],"updated_at":"2026-11-02T14:12:40.302911Z"}],"osv":[{"id":"CVE-2026-75484","title":"HTTP/2 header field values containing CR, LF or NUL are passed to the application unvalidated in Bandit","description":"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.read_headers/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.req_headers unchanged. The HTTP/1 path already rejects the same octets; HTTP/2 did not.\n\nBandit 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 put_resp_header, 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.\n\nThis issue affects bandit: from 1.4.0 before 1.12.5.","status":"published","published":"2026-08-20T21:11:27.523Z","modified":"2026-10-28T02:31:06.170832739Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-93"],"updated_at":"2026-11-02T15:45:17.102988Z"},{"id":"EEF-CVE-2026-75484","title":"HTTP/2 header field values containing CR, LF or NUL are passed to the application unvalidated in Bandit","description":"## Summary\n\nImproper 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.read_headers/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.req_headers` unchanged. The HTTP/1 path already rejects the same octets; HTTP/2 did not.\n\nBandit 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 `put_resp_header`, 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.\n\nThis issue affects bandit: from 1.4.0 before 1.12.5.","status":"published","published":"2026-08-20T21:11:27.523Z","modified":"2026-09-09T00:30:03.555913196Z","cvss":[{"version":"4.0","score":6.9,"vector":"CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N","level":"medium"}],"cwes":["CWE-93"],"updated_at":"2026-11-02T15:46:33.520522Z"}]}}