https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 08:48:44 +0000 https://cve.radiocsirt.org/vuln/euvd-2026-357520 EUVD-2026-357520 https://cve.radiocsirt.org/vuln/euvd-2026-357520 https://cve.radiocsirt.org/vuln/fkie_cve-2026-75484 <p>Improper Neutralization of CRLF Sequences (&#39;CRLF Injection&#39;) 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.</p> <p>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&#39;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.</p> <p>This issue affects bandit: from 1.4.0 before 1.12.5.</p> <p>Improper Neutralization of CRLF Sequences (&#39;CRLF Injection&#39;) 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.</p> <p>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&#39;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.</p> <p>This issue affects bandit: from 1.4.0 before 1.12.5.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-75484 https://cve.radiocsirt.org/vuln/ghsa-23xx-x3px-xxpj <p>Improper Neutralization of CRLF Sequences (&#39;CRLF Injection&#39;) 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.</p> <p>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&#39;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.</p> <p>This issue affects bandit: from 1.4.0 before 1.12.5.</p> <p>Improper Neutralization of CRLF Sequences (&#39;CRLF Injection&#39;) 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.</p> <p>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&#39;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.</p> <p>This issue affects bandit: from 1.4.0 before 1.12.5.</p> https://cve.radiocsirt.org/vuln/ghsa-23xx-x3px-xxpj