BUG/MAJOR: h3: reject header values containing invalid chars
authorWilly Tarreau <w@1wt.eu>
Tue, 8 Aug 2023 15:18:27 +0000 (17:18 +0200)
committerVincent Bernat <bernat@debian.org>
Fri, 3 Oct 2025 06:03:00 +0000 (08:03 +0200)
commitc731ae3d5b9c4ea9134591c6f7fe99db52b8e8e1
tree797ba1c92384b4543c25ff9f1b1db7260e7cc29e
parent3dc54ec00fccbf2051626cf9d87769c259a7648a
BUG/MAJOR: h3: reject header values containing invalid chars

Origin: https://git.haproxy.org/?p=haproxy-2.6.git;a=commit;h=20a35c4d505475215122d37405ce173075338032

In practice it's exactly the same for h3 as 54f53ef7c ("BUG/MAJOR: h2:
reject header values containing invalid chars") was for h2: we must
make sure never to accept NUL/CR/LF in any header value because this
may be used to construct splitted headers on the backend. Hence we
apply the same solution. Here pseudo-headers, headers and trailers are
checked separately, which explains why we have 3 locations instead of
2 for h2 (+1 for response which we don't have here).

This is marked major for consistency and due to the impact if abused,
but the reality is that at the time of writing, this problem is limited
by the scarcity of the tools which would permit to build such a request
in the first place. But this may change over time.

This must be backported to 2.6. This depends on the following commit
that exposes the filtering function:

    REORG: http: move has_forbidden_char() from h2.c to http.h

(cherry picked from commit d13a80abb7c1badaa42045c37cfff79f24f05726)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit 0404bf14c900d6ac879ec432a198435e0741d835)
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
(cherry picked from commit f58b63af68f239464c29e698a34f08ff3eef862f)
 [ad: no http/3 trailer support in 2.6]
Signed-off-by: Amaury Denoyelle <adenoyelle@haproxy.com>
Gbp-Pq: Name BUG-MAJOR-h3-reject-header-values-containing-invalid.patch
src/h3.c