CVE-2024-49214: HAProxy QUIC Authentication Bypass Vulnerability

CVE-2024-49214 Overview

CVE-2024-49214 is an authentication weakness in the QUIC implementation of HAProxy, a widely deployed open-source load balancer and reverse proxy. The vulnerability affects HAProxy versions 3.1.x before 3.1-dev7, 3.0.x before 3.0.5, and 2.9.x before 2.9.11. An attacker can open a QUIC 0-RTT session using a spoofed source IP address. Because HAProxy evaluated allow/block list rules against the unvalidated client address, the flaw permits bypass of IP-based access controls. The issue is classified under CWE-290: Authentication Bypass by Spoofing.

Critical Impact
Attackers can bypass IP allow/block list enforcement in HAProxy by sending 0-RTT QUIC traffic with a spoofed source address, enabling unauthorized access to backends intended to be restricted by source IP.

Affected Products

HAProxy 3.1.x prior to 3.1-dev7
HAProxy 3.0.x prior to 3.0.5
HAProxy 2.9.x prior to 2.9.11

Discovery Timeline

2024-10-14 - CVE-2024-49214 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-49214

Vulnerability Analysis

QUIC supports 0-RTT (zero round-trip time) resumption, which allows a client to send encrypted application data in the first flight without completing a full handshake. In HAProxy's QUIC stack, early data packets were accepted and processed before the sender's address was validated through retry tokens or a full handshake. IP allow and block list rules were applied against this unvalidated address.

Because QUIC runs over UDP, source addresses are trivially spoofable. An attacker can forge the source IP of a 0-RTT Initial packet to appear as a trusted address, causing HAProxy to treat the connection as if it originated from an allowed source. This defeats the IP-based access control model that many deployments rely on for administrative endpoints, internal services, or restricted paths.

Root Cause

The root cause is missing sender-address validation on the 0-RTT path. The upstream fix, commit f627b92, introduces new connection flags QUIC_FL_CONN_NO_TOKEN_RCVD and QUIC_FL_CONN_SEND_RETRY in include/haproxy/quic_conn-t.h to track whether a client supplied a valid address-validation token and to force a Retry packet when it did not. HAProxy now requires that the peer prove reachability at the claimed address before 0-RTT data is accepted.

Attack Vector

An attacker on the network sends a crafted QUIC Initial packet containing 0-RTT application data with a forged source IP matching an entry in HAProxy's allow list. The listener dispatches the request to the backend as if it came from the trusted address. No authentication, user interaction, or prior access is required.

// Patch excerpt: include/haproxy/quic_conn-t.h
#define QUIC_FL_CONN_IPKTNS_DCD                  (1U << 15) /* Initial packet number space discarded  */
#define QUIC_FL_CONN_HPKTNS_DCD                  (1U << 16) /* Handshake packet number space discarded  */
#define QUIC_FL_CONN_PEER_VALIDATED_ADDR         (1U << 17) /* Peer address is considered as validated for this connection. */
#define QUIC_FL_CONN_NO_TOKEN_RCVD               (1U << 18) /* Client did not send any token */
#define QUIC_FL_CONN_SEND_RETRY                  (1U << 19) /* A send retry packet must be sent */
/* gap here */
#define QUIC_FL_CONN_TO_KILL                     (1U << 24) /* Unusable connection, to be killed */

Source: GitHub Commit f627b92

Detection Methods for CVE-2024-49214

Indicators of Compromise

QUIC Initial packets on UDP/443 (or configured QUIC ports) containing 0-RTT early data where the source IP matches an internal or allow-listed range but the traffic arrives from an unexpected network path.
HAProxy access logs showing requests from allow-listed source IPs without a corresponding established TCP/HTTP session history.
Backend application logs recording requests to IP-restricted endpoints that are not reflected in upstream firewall or ACL telemetry.

Detection Strategies

Audit HAProxy versions across the estate and flag any running affected 2.9.x, 3.0.x, or 3.1.x builds.
Correlate HAProxy frontend src fields with routing data to identify 0-RTT connections where the source address is implausible for the ingress interface.
Monitor for unexpected QUIC traffic volume to endpoints that are supposed to be IP-restricted.

Monitoring Recommendations

Forward HAProxy and backend access logs to a centralized analytics platform and alert on access to restricted paths from the public Internet via QUIC.
Track UDP flow records at the perimeter for asymmetric or spoofed-looking QUIC Initial packets.
Enable connection-level logging of QUIC handshake outcomes, including whether a Retry packet was issued.

How to Mitigate CVE-2024-49214

Immediate Actions Required

Upgrade HAProxy to 2.9.11, 3.0.5, 3.1-dev7, or later on all instances that enable QUIC listeners.
If an immediate upgrade is not possible, disable QUIC listeners and route clients over TCP/TLS until patched.
Re-validate that security controls do not rely solely on source IP for authorization on QUIC-exposed services.

Patch Information

The fix is implemented in HAProxy commit f627b92 ("BUG/MEDIUM: quic: always validate sender address on 0-RTT"). It is included in HAProxy 2.9.11, 3.0.5, and 3.1-dev7. The patch forces address validation via a QUIC Retry when the client does not present a valid token, ensuring the sender has demonstrated reachability at the claimed IP before 0-RTT data is processed. See the HAProxy 2.9 Changelog, HAProxy 3.0 Changelog, and HAProxy 3.1 Changelog for release details.

Workarounds

Remove the allow-0rtt option from bind lines on QUIC frontends to prevent 0-RTT acceptance.
Enforce authentication at the application layer (mutual TLS, bearer tokens, signed requests) instead of relying on IP allow lists.
Terminate QUIC at an upstream device that performs address validation and forward only validated connections to HAProxy.

bash

# Example: disable 0-RTT on a QUIC frontend in haproxy.cfg
frontend quic_fe
    bind quic4@:443 ssl crt /etc/haproxy/certs/site.pem alpn h3
    # Do NOT include 'allow-0rtt' until HAProxy is upgraded to a fixed release
    default_backend app_be