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.

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.

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.

HAProxy - NULL Pointer Dereference in hpackdhtinsert Function

HAProxy - Integer Overflow in FCGI Demux Record Length Field

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.

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.

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.

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.

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 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.

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 😉 )

u/albinowax ’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, standalone mode) 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 😉 )

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 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

HAProxy Kubernetes Ingress Controller before 3.1.13, when the config-snippets feature flag is used, accepts config snippets from users with create/update permissions. This can result in obtaining an ingress token secret as a response. The fixed versions of HAProxy Enterprise Kubernetes Ingress Controller are 3.0.16-ee1, 1.11.13-ee1, and 1.9.15-ee1.

HAProxy before 2.8.2 accepts # as part of the URI component, which might allow remote attackers to obtain sensitive information or have unspecified other impact upon misinterpretation of a pathend rule, such as routing index.html#.png to a static server.

Last updated 25 August 2025

A flaw was found in the way haproxy processed certain HTTP/2 request packets. An attacker could send crafted HTTP/2 request packets which cause memory corruption, leading to a crash or potential remote arbitrary code execution with the permissions of the user running haproxy.

A flaw was found in haproxy. Anybody who can add a "set-cookie2 X=Y" header into the return path from their server/backend will kill haproxy in 2.2 (and onwards), resulting in a denial of service.

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 2.9.x before 2.9.10, 3.0.x before 3.0.4, and 3.1.x through 3.1-dev6 allows a remote denial of service for HTTP/2 zero-copy forwarding (h2send loop) under a certain set of conditions, as exploited in the wild in 2024.

An uncontrolled resource consumption vulnerability was discovered in HAProxy which could crash the service. This issue could allow an authenticated remote attacker to run a specially crafted malicious server in an OpenShift cluster. The biggest impact is to availability.

An information leak vulnerability was discovered in HAProxy 2.1, 2.2 before 2.2.27, 2.3, 2.4 before 2.4.21, 2.5 before 2.5.11, 2.6 before 2.6.8, 2.7 before 2.7.1. There are 5 bytes left uninitialized in the connection buffer when encoding the FCGIBEGINREQUEST record. Sensitive data may be disclosed to configured FastCGI backends in an unexpected way.

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.

HTTP request/response smuggling vulnerability in HAProxy version 2.7.0, and 2.6.1 to 2.6.7 allows a remote attacker to alter a legitimate user's request. As a result, the attacker may obtain sensitive information or cause a denial-of-service (DoS) condition.

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 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.