CVE-2026-110353: 
HAProxy vulnerability analysis and mitigation

CVE-2026-110353 is a denial-of-service vulnerability in HAProxy caused by improper handling of truncated HTTP/2 PING frames, leading to worker-thread CPU exhaustion. It affects HAProxy versions 3.2.0 through 3.2.25, 3.3.0 through 3.3.16, 3.4.0 through 3.4.5, and 3.5-dev pre-releases before 3.5-dev9, as well as HAProxy Enterprise Edition and Kubernetes Ingress Controller variants. The vulnerability was published on October 22, 2026, with patches available at the same time. It carries a CVSS v3.1 base score of 7.5 (High) (Red Hat Advisory, GitHub Advisory).

The root cause is a missing short-read check in the h2c_handle_ping function within src/mux_h2.c, classified under CWE-835 (Loop with Unreachable Exit Condition / Infinite Loop) and CWE-252 (Unchecked Return Value). Unlike other HTTP/2 frame handlers in HAProxy, h2c_handle_ping does not verify whether a complete frame was received; when a truncated PING frame arrives, the incomplete data is never consumed, causing the H2 multiplexer tasklet to be repeatedly woken without making progress. This results in a CPU spin loop that persists until the timeout http-request directive closes the connection, and an attacker opening many such connections simultaneously can sustain high CPU usage across worker threads (Red Hat Advisory, GitHub Advisory). The fix is available in the HAProxy git repository (HAProxy Commit).

Successful exploitation causes denial of service through sustained CPU exhaustion on HAProxy worker threads, degrading or completely preventing the proxy from serving legitimate traffic. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue. In high-traffic environments or where HAProxy fronts critical infrastructure, an attacker sustaining many concurrent malicious connections could render the service unresponsive, potentially affecting all downstream applications and users relying on the proxy (Red Hat Advisory, Red Hat Bugzilla).

No public proof-of-concept exploit code or in-the-wild exploitation has been reported as of the disclosure date. The vulnerability requires no authentication, no privileges, and no user interaction, making it trivially exploitable by any remote attacker who can reach an HAProxy instance with HTTP/2 enabled. The EPSS score is 0.0 at time of publication, and the vulnerability is not listed in the CISA Known Exploited Vulnerabilities catalog (GitHub Advisory, Red Hat Advisory).

1. Reconnaissance: Identify internet-facing HAProxy instances running versions 3.2.0–3.2.25, 3.3.0–3.3.16, or 3.4.0–3.4.5 with HTTP/2 (h2 or h2c) enabled, using tools like Shodan, Censys, or banner grabbing.
2. Establish HTTP/2 connections: Open multiple concurrent HTTP/2 connections to the target HAProxy instance.
3. Send truncated PING frames: Craft and transmit HTTP/2 PING frames that are intentionally truncated (i.e., fewer than the required 8 bytes of opaque data), causing h2c_handle_ping to receive an incomplete frame.
4. Trigger the spin loop: Because the incomplete frame data is never consumed, the H2 multiplexer tasklet is repeatedly scheduled without progress, causing the worker thread to spin and consume CPU.
5. Scale the attack: Open many such connections simultaneously to exhaust all available worker-thread CPU capacity, sustaining the denial-of-service condition until the timeout http-request directive closes each connection (Red Hat Advisory, GitHub Advisory).

• Network: High volume of inbound HTTP/2 connections from one or multiple source IPs; connections that remain open but transfer minimal data after the initial handshake.
• System: Sustained near-100% CPU utilization on HAProxy worker threads (observable via top, htop, or process monitoring tools) without a corresponding spike in legitimate traffic.
• Logs: HAProxy logs showing many connections timing out due to timeout http-request from the same or rotating source IPs; absence of normal request processing in those sessions.
• Process: HAProxy worker processes consuming disproportionate CPU relative to active request throughput, detectable via haproxy -sf stats or the HAProxy stats socket (show info).

Upgrade to a patched version of HAProxy: 3.2.26, 3.3.17, 3.4.6, or 3.5-dev9 for the community edition; 3.2r1-378.1259 or 3.3r1-377.1005 for HAProxy Enterprise Edition; 3.2.17 for the Kubernetes Ingress Controller; and 3.2.17-ee1, 3.0.16-ee17, or 1.11.14-ee11 for the Kubernetes Ingress Controller Enterprise (Red Hat Advisory, GitHub Advisory). As a short-term workaround, reducing the timeout http-request value will limit the duration of each spin loop, decreasing the CPU impact per connection. Additionally, rate-limiting inbound HTTP/2 connections at the network perimeter or load balancer level can reduce the attack surface until patching is complete.

The vulnerability was noted on Mastodon/infosec.exchange shortly after disclosure, with automated CVE tracking accounts and security researchers acknowledging the issue (infosec.exchange CVE). Red Hat triaged the issue at high severity and opened a Bugzilla tracking entry with a broad CC list of product security engineers, indicating active internal review (Red Hat Bugzilla). No major vendor statements beyond Red Hat or significant media coverage have been identified at this time.