CVE-2026-110354: 
HAProxy vulnerability analysis and mitigation

CVE-2026-110354 is a denial-of-service vulnerability in HAProxy 3 caused by an infinite loop in the HTTP/1.1 chunked request parser. A remote, unauthenticated attacker can send a specially crafted HTTP/1.1 chunked request that causes the H1 multiplexer's parser to repeatedly re-process the same bytes without making forward progress, trapping worker threads at 100% CPU indefinitely. Affected versions include HAProxy 3.0.0–3.0.29, 3.2.0–3.2.25, 3.3.0–3.3.16, 3.4.0–3.4.5, and 3.5-dev through 3.5-dev8, as well as corresponding HAProxy Enterprise Edition and Kubernetes Ingress Controller releases. It was published on October 22, 2026, and carries a CVSS v3.1 base score of 7.5 (High) (Red Hat CVE, GitHub Advisory).

The root cause is classified as CWE-835 (Loop with Unreachable Exit Condition / Infinite Loop). When HAProxy's H1 multiplexer processes an HTTP/1.1 chunked request and attempts to drain the request before closing the stream, a flaw in the parser logic causes it to re-evaluate the same bytes in a loop without advancing its position, resulting in the worker thread spinning at 100% CPU. This condition persists even after configured timeouts expire and after the client disconnects, meaning the thread is permanently consumed until the HAProxy process is restarted. No authentication or special privileges are required; the attack is network-accessible with low complexity, making it trivially exploitable at scale (Red Hat CVE, GitHub Advisory, Red Hat Bugzilla). A fix commit is available in the HAProxy upstream repository (HAProxy Commit).

Successful exploitation results in persistent CPU exhaustion of HAProxy worker threads, with no impact on confidentiality or integrity. Each malicious request permanently consumes one worker thread at 100% CPU; by sending repeated requests, an attacker can exhaust all available worker threads, rendering the proxy completely unresponsive to legitimate traffic until the process is manually restarted. In environments where HAProxy serves as a critical load balancer or ingress controller (including Kubernetes deployments), this can cause a full service outage affecting all downstream applications and users (Red Hat CVE, Red Hat Bugzilla).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the disclosure date. The EPSS score is 0.0, indicating low current exploitation probability, and the vulnerability does not appear in the CISA KEV catalog (GitHub Advisory). However, the attack requires no authentication, no user interaction, and only a network connection, making it straightforward for any attacker to attempt once the triggering request format is understood. No threat actor attribution has been reported.

1. Reconnaissance: Identify internet-facing HAProxy instances running version 3.x (3.0.0–3.0.29, 3.2.0–3.2.25, 3.3.0–3.3.16, 3.4.0–3.4.5, or 3.5-dev through 3.5-dev8) using tools such as Shodan or Censys, or by probing HTTP response headers for HAProxy version banners.
2. Craft malicious request: Construct an HTTP/1.1 chunked transfer-encoded request with a malformed or specially crafted chunk structure that triggers the parser's infinite re-processing loop in the H1 multiplexer.
3. Send request: Transmit the crafted request to the target HAProxy instance over HTTP/1.1. No credentials or session tokens are required.
4. Observe thread exhaustion: The targeted worker thread enters a 100% CPU loop and remains stuck even after the connection is closed or timeouts expire, permanently consuming that thread.
5. Repeat to exhaust all threads: Send additional malicious requests (one per worker thread) to consume all available worker threads, causing HAProxy to become completely unresponsive to legitimate traffic until the process is restarted (Red Hat CVE, Red Hat Bugzilla).

• Network: Unusual or repeated HTTP/1.1 requests with chunked transfer encoding (Transfer-Encoding: chunked) from one or more source IPs to the HAProxy frontend, particularly with malformed or minimal chunk bodies.
• Process: HAProxy worker threads showing sustained 100% CPU utilization (observable via top, htop, or ps aux) that persists after client disconnection and after configured timeout periods.
• Logs: HAProxy logs showing connections that remain open or in a processing state far beyond configured timeout values; absence of normal request completion log entries for affected connections.
• System: Overall HAProxy process becoming unresponsive to new connections despite the process still running; health check failures from upstream load balancers or monitoring systems targeting the HAProxy instance.

Upgrade to a patched version of HAProxy: 3.0.30, 3.2.26, 3.3.17, 3.4.6, or 3.5-dev9 for community editions. For HAProxy Enterprise Edition, upgrade to 3.0r1-362.1441, 3.2r1-378.1259, or 3.3r1-377.1005. For HAProxy Kubernetes Ingress Controller, upgrade to 3.2.17 (community) or 3.2.17-ee1, 3.0.16-ee17, or 1.11.14-ee11 (Enterprise). The upstream fix is available in the HAProxy git repository (HAProxy Commit). As a temporary workaround where patching is not immediately possible, consider rate-limiting or blocking HTTP/1.1 chunked requests at an upstream network layer, or restricting access to HAProxy frontends to trusted IP ranges (Red Hat CVE, GitHub Advisory).

Red Hat has acknowledged the vulnerability and assigned it a high severity rating, opening a tracking bug (Bugzilla 2558749) with 27 CC'd team members, indicating active internal triage across multiple product teams (Red Hat Bugzilla). The GitHub Advisory Database has published the advisory (GHSA-vqpp-w68q-p3f5), though it remains marked as unreviewed with no associated package ecosystem entry. No notable independent researcher commentary or significant social media discussion has been identified as of the disclosure date.