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.

HAProxy - NULL Pointer Dereference in hpackdhtinsert Function

HAProxy - Integer Overflow in FCGI Demux Record Length Field

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

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.

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.

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.

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

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.

On 10/10/23 11:40, Alan Coopersmith wrote: Information I've found so far on open source implementations (most via the current listings in the CVE) include: Some more updates since last week: - Apache httpd:   https://chaos.social/@icing/111210915918780532 The discussion in https://github.com/apache/httpd-site/pull/10 makes the situation a little murkier.

- contour: https://github.com/projectcontour/contour/pull/5850

- grpc-go: https://github.com/grpc/grpc-go/pull/6703 - haproxy: https://github.com/haproxy/haproxy/issues/2312 https://www.haproxy.com/blog/haproxy-is-not-affected-by-the-http-2-rapid-reset-attack-cve-2023-44487 - http2 [Haskell]: https://github.com/kazu-yamamoto/http2/issues/93

- IETF: https://lists.w3.org/Archives/Public/ietf-http-wg/2023OctDec/0025.html

- kubernetes: https://github.com/kubernetes/kubernetes/pull/121120

- linkerd: https://linkerd.io/2023/10/12/linkerd-cve-2023-44487/ - netty: https://github.com/netty/netty/commit/58f75f665aa81a8cbcf6ffa74820042a285c5e61 https://github.com/advisories/GHSA-xpw8-rcwv-8f8p https://netty.io/news/2023/10/10/4-1-100-Final.html

- varnish https://github.com/varnishcache/varnish-cache/issues/3996

Also,https://mstdn.social/@jschauma/111252863550361935 points out that the Rust h2 crate seems to have announced a very similar issue under a different CVE id back in April:

https://rustsec.org/advisories/RUSTSEC-2023-0034.html https://github.com/advisories/GHSA-f8vr-r385-rh5r

and a followup post notes further similarities to Netflix's CVE-2019-9514 “Reset Flood” from https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-002.md except in that case the RSTSTREAM seem to have been sent from the server, not the client side.

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

[I've seen multiple news articles & blogs in the wake of the coordinated disclosure today, but no postings here yet, so lets start fixing that.]

Google, Cloudflare, AWS, and others released details today of a protocol-level issue in HTTP/2 being exploited in recent months for denial-of-service attacks:

https://cloud.google.com/blog/products/identity-security/how-it-works-the-novel-http2-rapid-reset-ddos-attack https://blog.cloudflare.com/technical-breakdown-http2-rapid-reset-ddos-attack/ https://aws.amazon.com/blogs/security/how-aws-protects-customers-from-ddos-events/

This attack works via the multiplexed streams feature of HTTP/2, in which the client repeatedly makes a request for a new stream, and then immediately sends a RSTSTREAM frame to cancel them, resulting in the server doing lots of extra work to set up and tear down the streams, while not hitting any server-side limit on a maximum number of active streams per connection.

CVE-2023-44487 was issued to track this issue across implementations: https://www.cve.org/CVERecord?id=CVE-2023-44487

A script to check for affected implemenations has been posted at: https://github.com/bcdannyboy/CVE-2023-44487

Information I've found so far on open source implementations (most via the current listings in the CVE) include:

- Apache httpd: https://chaos.social/@icing/111210915918780532

- caddy: https://github.com/caddyserver/caddy/issues/5877

- envoy: https://github.com/envoyproxy/envoy/pull/30055

- golang: https://github.com/golang/go/issues/63417 https://groups.google.com/g/golang-announce/c/iNNxDTCjZvo

- h2o: https://github.com/h2o/h2o/security/advisories/GHSA-2m7v-gc89-fjqf https://github.com/h2o/h2o/pull/3291

- haproxy: https://github.com/haproxy/haproxy/issues/2312

- hyper: https://seanmonstar.com/post/730794151136935936/hyper-http2-rapid-reset-unaffected

- jetty: https://github.com/eclipse/jetty.project/issues/10679 https://github.com/eclipse/jetty.project/releases/tag/jetty-12.0.2 https://github.com/eclipse/jetty.project/releases/tag/jetty-11.0.17 https://github.com/eclipse/jetty.project/releases/tag/jetty-10.0.17 https://github.com/eclipse/jetty.project/releases/tag/jetty-9.4.53.v20231009

- netty: https://github.com/netty/netty/commit/58f75f665aa81a8cbcf6ffa74820042a285c5e61

- nghttp2: https://github.com/nghttp2/nghttp2/pull/1961 https://github.com/nghttp2/nghttp2/releases/tag/v1.57.0

- nginx: https://www.nginx.com/blog/http-2-rapid-reset-attack-impacting-f5-nginx-products/ https://mailman.nginx.org/pipermail/nginx-devel/2023-October/S36Q5HBXR7CAIMPLLPRSSSYR4PCMWILK.html

- nodejs: https://github.com/nodejs/node/pull/50121

- proxygen: https://github.com/facebook/proxygen/pull/466

- swift-nio-http2: https://forums.swift.org/t/swift-nio-http2-security-update-cve-2023-44487-http-2-dos/67764

- tomcat: https://tomcat.apache.org/security-11.html#FixedinApacheTomcat11.0.0-M12 https://tomcat.apache.org/security-10.html#FixedinApacheTomcat10.1.14 https://tomcat.apache.org/security-9.html#FixedinApacheTomcat9.0.81 https://tomcat.apache.org/security-8.html#FixedinApacheTomcat8.5.94

-- -Alan Coopersmith- alan.coopersmith () oracle com Oracle Solaris Engineering - https://blogs.oracle.com/solaris

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.

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.

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

Initial description: Router PODs frequently getting restarted and haproxy process is receiving the segfault but it is not generating coredump even though the core file size is unlimited.

Upstream bug: https://github.com/haproxy/haproxy/issues/1972

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.

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.

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

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.

Last updated 25 August 2025

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