Last updated 25 August 2025

A flaw was found in HAProxy's headers processing that causes HAProxy to drop important headers fields such as Connection, Content-length, Transfer-Encoding, and Host after having partially processed them. A maliciously crafted HTTP request could be used in an HTTP request smuggling attack to bypass filtering and detection by HAProxy.

HAProxy - Integer Overflow in FCGI Demux Record Length Field

HAProxy - NULL Pointer Dereference in hpackdhtinsert Function

A flaw was found in haproxy. A stemming from an inefficient algorithmic complexity issue within its bundled mjson parsing library. This vulnerability is triggered when haproxy is configured to analyze JSON content, such as with the jsonquery or jwtpayloadquery function

A flaw was discovered in the HPACK decoder of haproxy before 1.8.14, that is used for HTTP/2. An out-of-bounds read access in hpackvalididx() resulted in a remote crash and denial of service. According to the report, there is no risk of escalation or code execution.

An issue was discovered in HAProxy 2.2 before 2.2.16, 2.3 before 2.3.13, and 2.4 before 2.4.3. It does not ensure that the scheme and path portions of a URI have the expected characters. For example, the authority field (as observed on a target HTTP/2 server) might differ from what the routing rules were intended to achieve.

An issue was discovered in HAProxy 2.2 before 2.2.16, 2.3 before 2.3.13, and 2.4 before 2.4.3. It can lead to a situation with an attacker-controlled HTTP Host header, because a mismatch between Host and authority is mishandled.

An out-of-bounds read issue was discovered in the HTTP/2 protocol decoder in HAProxy 1.8.x and 1.9.x through 1.9.0 which can result in a crash. The processing of the PRIORITY flag in a HEADERS frame requires 5 extra bytes, and while these bytes are skipped, the total frame length was not re-checked to make sure they were present in the frame.

An issue was discovered in dns.c in HAProxy through 1.8.14. In the case of a compressed pointer, a crafted packet can trigger infinite recursion by making the pointer point to itself, or create a long chain of valid pointers resulting in stack exhaustion.

A flaw was found in HAProxy before 2.0.6. In legacy mode, messages featuring a transfer-encoding header missing the "chunked" value were not being correctly rejected. The impact was limited but if combined with the "http-reuse always" setting, it could be used to help construct an HTTP request smuggling attack against a vulnerable component employing a lenient parser that would ignore the content-length header as soon as it saw a transfer-encoding one (even if not entirely valid according to the specification).

An out-of-bounds read in dnsvalidatednsresponse in dns.c was discovered in HAProxy through 1.8.14. Due to a missing check when validating DNS responses, remote attackers might be able read the 16 bytes corresponding to an AAAA record from the non-initialized part of the buffer, possibly accessing anything that was left on the stack, or even past the end of the 8193-byte buffer, depending on the value of acceptedpayloadsize.

An integer overflow exists in HAProxy 2.0 through 2.5 in htxaddheader that can be exploited to perform an HTTP request smuggling attack, allowing an attacker to bypass all configured http-request HAProxy ACLs and possibly other ACLs.

HAProxy through 2.0.32, 2.1.x and 2.2.x through 2.2.30, 2.3.x and 2.4.x through 2.4.23, 2.5.x and 2.6.x before 2.6.15, 2.7.x before 2.7.10, and 2.8.x before 2.8.2 forwards empty Content-Length headers, violating RFC 9110 section 8.6. In uncommon cases, an HTTP/1 server behind HAProxy may interpret the payload as an extra request.

HAProxy through 3.4.0, fixed in commit 5985276, contains an integer overflow vulnerability in the fcgiconn structure's drl field that allows buffer misparse as new FCGI record headers. When contentLength is 65535 and paddingLength is 1 or more, the drl field wraps to 0, causing incorrect record consumption and allowing malicious FastCGI backends to desynchronize the FCGI framing parser, potentially causing request routing errors, response smuggling, or memory safety issues.

HAProxy through 3.4.0, fixed in commit 9a6d1fe, contains a null pointer dereference vulnerability in hpackdhtinsert() within src/hpack-tbl.c that fails to validate the return value of hpackdhtdefrag() when the memory pool is exhausted. An attacker can trigger HPACK dynamic table insertions under memory pressure to dereference a NULL pointer and crash HAProxy worker processes, causing denial of service.

Incorrect caching of responses to requests including an Authorization header in HAProxy 1.8.0 through 1.8.9 (if cache enabled) allows attackers to achieve information disclosure via an unauthenticated remote request, related to the protohttp.c checkrequestforcacheability function.

An issue was discovered in HAProxy before 3.3.6. The HTTP/3 parser does not check that the received body length matches a previously announced content-length when the stream is closed via a frame with an empty payload. This can cause desynchronization issues with the backend server and could be used for request smuggling. The earliest affected version is 2.6.

QUIC in HAProxy 3.1.x before 3.1-dev7, 3.0.x before 3.0.5, and 2.9.x before 2.9.11 allows opening a 0-RTT session with a spoofed IP address. This can bypass the IP allow/block list functionality.

An issue was discovered in HAProxy 2.0 before 2.0.24, 2.2 before 2.2.16, 2.3 before 2.3.13, and 2.4 before 2.4.3. An HTTP method name may contain a space followed by the name of a protected resource. It is possible that a server would interpret this as a request for that protected resource, such as in the "GET /admin? HTTP/1.1 /static/images HTTP/1.1" example.

Buffer overflow in the trash buffer in the header capture functionality in HAProxy before 1.4.21, when global.tune.bufsize is set to a value greater than the default and header rewriting is enabled, allows remote attackers to cause a denial of service and possibly execute arbitrary code via unspecified vectors.

The keycloak guides recommend to not expose /admin path to the outside in case the installation is using a proxy (see https://www.keycloak.org/server/reverseproxy#exposedpathrecommendations ). The problem is that, at least ha-proxy, can be tricked to using relative/non-normalized paths to access the /admin application path relative to /realms (which should be exposed). For example:

curl --path-as-is http://localhost:7080/realms/../admin/master/console/#/master/info <http://localhost:7080/admin/master/console/#/master/info>

The admin path requires authentication but, in the end, the final customer is exposing a path that he thinks is not accessible. Also note that this is more an issue in ha-proxy than keycloak. Keycloak does not even document how to configure ha-proxy or any other proxy, it just recommends to not expose the /admin app. For example mod-proxy correctly manages non-normalized URLs, because it normalizes the path before to be sure it's inside the prefix-path.

Nevertheless we have reached the conclusion that keycloak should return an error by default for non-normalized URLs.

The installation should use a proxy configuration with ha-proxy with the common configuration.

James Kettle’s work on request smuggling has always inspired me. I’ve followed his research, watched his talks at DEFCON and BlackHat, and spent time experimenting with his labs and tooling.

Coming from a web security background, I’ve explored vulnerabilities both from a black-box and white-box perspective — understanding not just how to exploit them, but also the exact lines of code responsible for issues like SQLi, XSS, and broken access control.

Request smuggling, however, always felt different. It remained something I could detect and exploit… but never fully trace down to its root cause in real-world server implementations.

A few months ago, I decided to go deeper into networking and protocol internals, and now, months later, I can say that I “might” have figured out how the internet works😂

This research on HAProxy (HTTP/3) is the result of that journey — finally connecting the dots between protocol behavior and the actual code paths leading to the bug.

(Yes, I used AI 😉 )