The same toolkit tampered with multiple tools across the victims' systems, including an SSH keylogger. HAProxy was one of several disguises; it just happened to be the most interesting to reverse-engineer.

That headline pairing of "backdoor" and "HAProxy" has understandably raised questions from our community and customers. So we want to be clear about what happened and what it means for anyone running open source infrastructure.

Trojanized binaries don't exploit a flaw

The details matter here, so start with the facts.

There is no CVE. Nobody exploited a flaw in HAProxy. Rapid7's research is explicit on this point: the attackers had to fully compromise the victim's host first, through some other means, before they could deploy the backdoor. Once they had that access, they replaced the legitimate HAProxy binary with a modified version that they compiled themselves.

This was also not a supply chain attack. Nobody tampered with an official HAProxy download, package repository, or release. The attackers recompiled HAProxy 2.8.12 from source, with their own malicious plugin built in, custom-fitted to the victims' environment. The trojanized build even used hardcoded memory offsets specific to version 2.8.12, which confirms it was purposely built for those specific targets rather than distributed broadly.

In other words, the attackers didn't break into HAProxy. They broke into the servers, then camouflaged malware as HAProxy.

Why attackers target the load balancer

Once an attacker compromises a host, they can trojanize anything on it. And in this campaign, they did. The same toolkit included tampered versions of crond, sshd, agetty, atd, and polkitd. Rapid7 even found evidence of code reused from a possible prior backdoor developed for nginx. Any widely deployed open-source component can be abused this way because the technique doesn't depend on the software having a flaw. It depends on the attacker already having control of the machine.

The load balancer was an attractive target for one simple reason: it sees everything. It terminates TLS and touches every request and response. The Ted implant used HAProxy's extensibility: the filter API and body-access hooks that let operators build custom traffic logic. With those, it captured session cookies and injected scripts into pages served to selected victims, all while running a hidden command channel underneath. Normal load balancing kept working the whole time, so nothing looked wrong.

A trusted reputation invites less scrutiny

Part of what made HAProxy useful as a disguise is its reputation. The open-source software has been peer-reviewed and battle-tested and recently passed an audit by Almond ITSEF, validating HAProxy's architectural resilience, so a healthy HAProxy process is one of the last things an operator suspects. The trust the software has earned over two decades has become a cover for malware wearing its name. The more dependable a component is, the less scrutiny it tends to get, and attackers know it.

That's a property of any extensible edge software, not a defect. But it's exactly why the integrity of the binary sitting at the edge deserves the same scrutiny as your application servers.

Five habits for verifying open-source builds

The uncomfortable lesson from this research applies far beyond HAProxy. If you run open source software in production, you are responsible for knowing that the build you're running is the build the project actually shipped. In practice, that comes down to five habits:

1. Install from official sources. Get binaries and source from the trusted channels. For HAProxy, that's haproxy.com/downloads, where HAProxy Community Performance Packages are all published in one place. The same rule covers anything you load into the process. Modules, Lua scripts, and other extensions run with the binary's full access to your decrypted traffic, so they deserve the same scrutiny and the same trusted sourcing as the binary itself.

2. Verify the signature on every release. HAProxy releases ship with GPG signatures and SHA-256 and SHA-512 checksums, and checking them takes seconds. Put this in the upgrade runbook, not just the install guide. Every release, not once.

3. Monitor binary integrity after deployment. A signature check answers the question at a single moment, but file integrity monitoring keeps answering it. Rapid7's conclusion names binary integrity checks as a core control for catching implants like Ted, since a replaced binary evades the component's own logs. Open-source tools like OSSEC syscheck or AIDE do the job well, flagging when a binary on disk changes outside of a known update.

4. Don't assume an update removes a compromise. If an attacker has replaced a binary, bumping the version changes nothing. Cleanup means finding the tampered build and replacing it with a verified-clean one, on a host you've confirmed is no longer compromised.

5. Watch the whole host, not just the process. The Ted implant scrubbed HAProxy's own connection counters, and its command traffic never reached a backend server for logging. Independent network monitoring caught what component-level logs couldn't.

Verification takes seconds per release. Monitoring is a one-time setup. Between them, you've covered the install and everything that comes after it.

Hardening that attackers have to work around

HAProxy ships with hardening built for exactly this scenario. The recommended setup runs the process inside an empty chroot and drops its privileges after startup. A third protection is enabled by default: once its threads are running, HAProxy blocks itself from creating any new process at the operating system level.

Each protection takes something away from an intruder.

• The chroot locks the process in a bare directory with nothing to read and nowhere to write.

• Dropping privileges leaves it running as an unprivileged user with almost no capabilities.

• With forking forbidden, it can't spawn a shell or launch other tools.

These protections were originally designed to contain an intrusion through a compromised library, but they strip away most of what this implant needs to operate. Ted creates its command channel as named pipes under /tmp and executes operator commands via popen. In an empty chroot with forking forbidden, both of those calls fail.

Here's the interesting part: the implant checks for them. Its command channel can report back whether the target process is chrooted and whether it's running in master-worker mode. The attackers built it in a way that asks whether these protections are on. You don't write that code unless you know a hardened configuration breaks your tooling.

How to check that HAProxy is properly secured

Could attackers who are already compiling from source strip out the hardening? Sure. But that's exactly the point. A HAProxy process running as root, outside a chroot, with full capabilities looks wrong from the outside. Hardening doesn't make a compromised host safe. It forces the malware to either fail or become visible to anyone who checks.

And checking takes seconds, with no extra tooling:

• /proc/$(pidof haproxy)/root should point to an empty or deleted directory (the chroot)

• Uid in /proc/$(pidof haproxy)/status should be non-zero, with effective capabilities at or near nothing

• Max processes in /proc/$(pidof haproxy)/limits should be zero on each worker process, which means the built-in fork protection is active

If any of those look wrong on a host with hardening configured, either it's not configured properly, or you may be looking at a tampered process. Either way, it's worth investigating. And, if your global section doesn't already set chroot, user, and group, this is a good week to fix that. HAProxy 3.4 added chroot auto, which jails the process in an unnamed, empty, read-only directory with no setup required, and making chroot the default behavior is being discussed.

Where to get HAProxy builds you can trust

Which brings us to the practical question: where should HAProxy binaries come from?

Community

If you're running HAProxy Community Edition, you have two good options. You can compile from source pulled from the official project repositories and verify the signatures. Alternatively, a quicker option is to use the HAProxy Community Performance Packages that we maintain at HAProxy Technologies. These are the same open-source HAProxy, built and packaged by the team that develops it, with high-performance libraries included and tuned. You get a binary with known provenance and better out-of-the-box performance. That's a win on both counts.

What we'd steer you away from is running binaries of unknown origin. Distribution packages are built and signed through the distro's own verified pipeline, and you can confirm an installed binary matches what shipped with tools like rpm -V or debsums. The tradeoff is version lag: distros often stay on older branches, so fixes land there later than in official releases.

Vendor-embedded builds vary more. If HAProxy comes bundled with an appliance or platform, it's fair to ask the vendor how they build it, whether they publish checksums, and how quickly they track upstream fixes. The builds we can stand behind directly are the ones from official channels.

Enterprise

If you're running HAProxy One, our commercial platform, your builds come exclusively from HAProxy Technologies. We build, test, and sign every release ourselves before delivering it through authenticated channels, so the provenance question is answered before the binary ever reaches you. Enterprise customers also get our support team, which means a second set of expert eyes if anything about a deployment ever looks off.

One thing to remember: no vendor's build, ours included, protects a host that an attacker already controls. Trusted builds and signature verification tell you that what you installed is genuine. File integrity monitoring and host security keep it that way. You need both.

If you see something, tell us

An open question for us: where else might trojanized HAProxy builds be circulating? If you encounter a suspicious HAProxy binary or a package that fails verification against our published checksums, report it to security at haproxy.com. The same goes for unofficial download sites offering HAProxy builds.

Credit to Rapid7 Labs for thorough research and responsible reporting. Their full write-up includes indicators of compromise, from file hashes to on-host artifacts, worth adding to detection tooling.

The takeaway is simple. HAProxy wasn't breached. A server was breached, and the attackers wore HAProxy as a disguise. Verify your builds and monitor their integrity. And get your binaries from a source you can trust.

With over 3,200 combined AI use cases cataloged across the US and EU, public sector IT leaders face an identical roadblock: traditional application delivery controllers were not designed to parse or throttle Layer 7 LLM payloads, leading to backend GPU exhaustion.

Generative AI in the public sector introduces demands that traditional architectures were never built for: sensitive data flowing through inference APIs and strict audit requirements.

If you're in the public sector, see how HAProxy One handles government application delivery across on-premises, sovereign cloud, and air-gapped environments, with commercial products available to US buyers through authorized partners on Federal and SLED contract vehicles.

How is AI applied in the public sector?

Government agencies use AI for specific, already-deployed tasks. 

A few examples:

• Fraud detection. The Treasury Department uses machine learning to detect fraud in real time, and recovered over $4 billion in fraudulent funds during fiscal year 2024. Carahsoft

• Service chatbots. The IRS deployed a virtual assistant called "Ask IRS," built on Microsoft Azure AI, which handled over 3 million taxpayer questions in its first year and cut call center volume by 40%. SmartDev

• Document processing. The General Services Administration uses AI to help review procurement documents, which frees up staff for more strategic work. SmartDev

• Threat and anomaly detection, where models flag unusual network activity or suspicious transactions that a manual review would likely miss.

Agentic AI in the public sector

These examples share a pattern: a model flags something or answers something, and a person decides what happens next. Agentic AI removes that middle step. Instead of flagging an anomaly, an agentic system can investigate it. Instead of answering a question, it can complete the underlying task, such as processing a benefits application from start to finish with no human in the loop.

Securing sensitive data in AI inference APIs

Government AI handles some of the most sensitive data in existence: tax records, health histories, law enforcement intelligence, and defense communications. When that data moves through an inference API, it meets threats that ordinary web security was not designed to catch. In the EU, the General Data Protection Regulation (GDPR) raises the stakes further, requiring strict protection for any system that processes the personal data of EU citizens.

The endpoints themselves face a specific set of risks:

• Prompt injection that manipulates a model into leaking data or behaving unpredictably.

• Unauthorized access to inference endpoints, which exposes both model capabilities and the data sitting behind them.

• Model extraction, where an attacker sends repeated probing queries to reverse-engineer proprietary model behavior.

• Autonomous risk escalation: as agentic AI in the public sector spreads, a single compromised endpoint can trigger actions with no human in the loop.

Both the U.S. and the EU are answering with governance frameworks, including NIST's draft Cybersecurity Framework Profile for AI and the EU AI Act. Those frameworks set expectations; the delivery layer is where they actually get enforced.

HAProxy One application delivery platform enforces them through a web application and API protection (WAAP) stack. A web application firewall solution inspects requests and helps protect inference endpoints, achieving 99.65% balanced accuracy in an open source WAF benchmark. Meanwhile, bot management and protection identifies, classifies, and labels high-impact bot threats including application DDoS attacks, brute force attacks, web scrapers, and vulnerability scanners. For AI traffic specifically, an API gateway and AI gateway add rate limiting tied to API keys and token counts, which gives finer control than IP-based limits on their own.

HAProxy One runs consistently across on-premises, sovereign cloud, and air-gapped environments, giving government and public sector teams one security layer for AI services across the environments they operate in.

High availability for mission-critical AI services

Some government AI services cannot go dark. Disaster response coordination, real-time border monitoring, fraud detection across benefits systems, and emergency dispatch all fall into this category. When these systems stall, the cost is measured in public safety: in response times, and in people who can't reach the services they need.

Inference workloads make availability harder to guarantee. They are computationally heavy, and their latency swings with prompt complexity, model size, backend load, and concurrency. A delivery layer built for this kind of unpredictability keeps services responsive in a few concrete ways. Load balancing solutions spread inference requests across model replicas and continuously health-check the backends, rerouting traffic away from any instance that falters. HAProxy can run these health checks against specific endpoints, such as /health or /v1/models, to assess backend responsiveness and reroute traffic away from an overloaded GPU instance before requests start timing out. SSL/TLS offloading moves encryption work off the AI backend so latency stays low even under heavy load. Content-aware routing then sends different request types, such as chat completions and image generation, to the backend pools suited to them, so expensive GPU capacity goes where it is actually needed.

Latency compounds at this layer. When inference already adds hundreds of milliseconds, every fraction the delivery layer contributes counts. HAProxy is built for this: benchmarks showed HAProxy achieved over 2 million requests per second with TLS termination enabled, so the delivery layer adds negligible overhead even as inference traffic scales and demand spikes.

Modernizing legacy systems without a rip-and-replace

Public sector teams rarely get a clean slate. They run mainframe-era systems next to virtual machines and, increasingly, Kubernetes deployments. Older infrastructure predates modern AI workloads by decades, and replacing it wholesale is rarely realistic on a public budget or a public timeline.

HAProxy One deploys consistently across on-premises data centers, public clouds, sovereign clouds, and container environments, which lets it act as connective tissue between legacy systems and new AI services. A Kubernetes ingress controller routes traffic into containerized AI workloads while the same platform manages external load balancing for Kubernetes and the traditional backends beside them. Agencies modernize one service at a time, keeping central control and observability intact, and without locking themselves into a single cloud or compromising between jurisdictions.

AI governance in the public sector carries legal weight. In the U.S., OMB Memoranda M-25-21 and M-25-22 direct agencies to set AI strategies and to put safeguards around high-impact use cases, while updating how they buy AI. In the EU, the AI Act took force in August 2024 and classifies many public sector uses as "high-risk," which brings requirements for risk management, data governance, technical documentation, and fundamental rights impact assessments.

The two regimes approach the problem differently:

These obligations are largely organizational, but several of them (ongoing monitoring, audit trails, and transparency) depend on infrastructure that can show its work. The HAProxy Fusion Control Plane aggregates logs, metrics, and security events from every node it manages, across on-premises, cloud, sovereign-cloud, and Kubernetes environments. Secure management traffic runs over mTLS, so the audit trail itself is protected end to end.

The OECD's guidance on trustworthy government AI points the same way, urging agencies to favor high-benefit, lower-risk applications while they build maturity. Most still lack the measurement to make those calls with confidence, which is exactly why infrastructure-level observability belongs in the design from day one, rather than something retrofitted after a deployment is already live.

Securing your agency's AI future

Every challenge described above has a known answer at the infrastructure layer. The real question for public sector IT teams is whether the platform under their AI services was built for this much load and this much scrutiny.

HAProxy One pairs the performance of the open source HAProxy core with a unified enterprise platform. The HAProxy Enterprise load balancer delivers high-performance load balancing and multi-layered security with token-aware rate limiting for AI traffic, and the HAProxy Fusion Control Plane centralizes management and observability across the estate. ML-enhanced threat intelligence already powers the detection algorithms in the HAProxy Enterprise WAF and Bot Management Module, and the HAProxy Edge application delivery network extends that intelligence to the network edge.

Reach out to discuss how HAProxy One can support your agency's AI infrastructure.

Frequently asked questions

Almost every one of them, whatever it started as, turned into a version of the same question: how do I know? How do I know whether a vendor's AI does what the banner says? How do I know what my agents are doing on the network? Or that every certificate in the inventory will renew before it expires, or what's really running in front of my applications right now?

Verification, not novelty, was the subject of the show.

Our takeaways

1. AI saturation has produced buyer skepticism, and skepticism rewards checkable claims. When every vendor says the same thing, the advantage goes to whoever can be verified, in source code, in documentation, and in practice.

2. The dominant AI security question has shifted from "what can AI do for us" to "how do we control what our AI is doing." Agent and model traffic needs a policy enforcement point, and that's a proxy problem.

3. Smaller rooms help build trust. Some of our best conversations happened at a 250-person forum convened by Major League Baseball at the same time as Black Hat.

Six themes from the Black Hat show floor

1. Every booth claimed AI, and the crowd was skeptical

Every vendor at Black Hat attached AI to its message. Some were selling ways to secure AI workflows. Others were selling AI that does the security work for you, reading logs or running penetration tests. AI saturation produced a predictable reaction: attendees told us their hardest problem was separating useful capability from marketing noise.

It's a change in tone from 2025. Last year the question was what can AI do for security? This year: how do I tell whether yours does anything real? Several people asked, more or less directly, to be shown rather than told.

The correction favors technology whose claims can be tested and verified. HAProxy's core is open source, with a documented configuration language, so an engineer can read what a feature does instead of trusting a marketing headline. Behind the project is a community large enough to have tried nearly every configuration imaginable, in production Many of them publish their setups and experiences in blogs and forums.

Open fundamentals raise the bar for everyone, us included. If the core is free, capable, and readable, then commercial products must add something unique and worthwhile: advanced security, management and orchestration, and support from the engineers who built the product.

2. People wanted proof, from someone who had built it

Blocking unwanted traffic and web attacks was the most common use case attendees raised. Our best answer to this was to walk through the security control plane in HAProxy Fusion at one of our demo stations.

Centralized DDoS protection, bot management, and WAF policy across a whole fleet is easier to show than to describe. It’s simple to understand and configure using HAProxy Fusion’s Security Profiles and the intuitive visual policy builder we call the Threat-Response Matrix. To cap it all, unified observability shows its impact on real traffic.

Attendees wanted to go deep, with multiple technical questions, so it helped that we brought several of our top engineers who helped design and build our solutions, and implement them in real-world deployments. At a show where every banner claims the same capabilities, that expertise and experience is the fastest way to stand out.

3. Agent and MCP traffic is the new perimeter question

Some of the most common AI questions were about securing AI traffic. How do you put a policy enforcement point in front of model and agent calls? And how do you see what those agents are doing on the network once they're running? 

Businesses are also starting to consume third-party MCP (Model Context Protocol) servers, and some are preparing to expose their own. Both directions raise questions, such as who may call this, and what did they ask for? At least one vendor on the floor was building an MCP gateway as its entire product.

A head of AI security at a large organization sought us out to ask what we can do to help. Our answer: this is a proxy problem in new clothes. 

Agent and model traffic is HTTP and gRPC. Authentication, authorization, rate limiting, request inspection, routing, and observability at Layer 7 are among the very fundamentals of HAProxy. You don't need a new category of product to put a control point in front of an agent or MCP server. The control point you already have just needs to see that traffic.

4. Certificate management is as vital as threat protection

For a conference built on offensive research, a striking share of the practical questions at our booth were about certificates. How do you automate issuance and renewal across thousands of endpoints, and what breaks when certificate lifetimes shorten?

There's a deadline behind those questions. Under CA/Browser Forum ballot SC-081v3, maximum TLS certificate lifetimes fell from 398 days to 200 in March 2026. They drop to 100 days in 2027, and to 47 days in 2029. Domain validation reuse is shrinking on the same schedule, from 398 days to 10, so revalidation becomes near-continuous.

It’s worth considering how that will affect your own inventory. A certificate that previously needed to be renewed once a year will need it roughly eight times a year at 47-day validity. An inventory of 500 certificates, for example, becomes close to 4,000 renewal events a year.

These are unglamorous problems that quietly consume large teams. 

HAProxy's SSL/TLS implementation is best in class. But certificates aren't a single load balancer problem, they're a fleet problem; managing them consistently across an entire fleet is the hard part. Centralized ACME support in HAProxy Fusion, for fleet-wide certificate automation, is coming soon, and we demoed it at the booth. Automating renewal from the control plane removes a whole category of expiry incident. That demo spread by word of mouth and drew people who needed exactly this.

Post-quantum TLS came up too, usually as a sequencing problem: the load balancer, the backend, and the clients are all on different timelines. The load balancer, at least, doesn't have to be the blocker. HAProxy Community Performance Packages and HAProxy Enterprise 3.2+ support hybrid post-quantum key exchange natively. Clients that aren't ready fall back to classical ECDHE. Our guide to enabling post-quantum cryptography and TLS termination walks through the configuration.

5. "App sec" and why securing traffic matters

AI wasn't the only thing the floor was selling. A large share of it was application security in the narrower sense: securing the application code itself, rather than the traffic that reaches it.

The two layers answer different halves of the same question. Code analysis tells you what an application should do. The traffic layer tells you what it does under real load, from real clients, including the requests nobody designed for. 

The two layers also work on different clocks. Fixing application code takes as long as it takes: a patch, a review, a release, a deployment window. The vulnerability stays reachable in the meantime. A WAF at the proxy layer can block the requests that would exploit the vulnerability; this doesn't fix the code but buys the time to fix it properly. That's a good reason for the traffic layer and the code layer to be part of the same conversation.

6. Trust compounds over 25 years

One topic came up again and again: we have F5, we're having some issues, we're opening conversations with other vendors, and we heard of HAProxy.

There’s a good reason why people gravitate to HAProxy under these circumstances. HAProxy has been in production for more than 25 years, upholding the world’s most demanding applications and inspiring a generation of tinkerers in their home labs. That history is why people arrive at the booth already knowing the name, and already trusting the solution. It's also why "how do I know?" has an easy answer here: check the source, or ask anyone who has run it.

It also means the migration path is well traveled rather than theoretical. DoubleVerify's move from F5 to HAProxy Enterprise is the story we pointed people to most often.

Building an ecosystem in 2026

Two miles from Mandalay Bay, we spent the same days at CTI (Cyber & Technology Innovation). It's a 250-person forum, convened by Major League Baseball rather than by a vendor or a media company.

CTI brings together technology and security leaders from MLB clubs, MLB's parent and sister companies, other sports leagues, and media and entertainment organizations. Those people run comparable infrastructure under comparable pressure: a season-shaped traffic curve, and live events that can't be rescheduled.

The keynote paired MLB's security leadership with a public-sector cybersecurity leader and one of the game's most recognizable managers. 

This event format is worth watching. Enterprise buyers with mature technical functions can build their own ecosystems, on their own terms, inviting peers directly instead of waiting for a vendor to broker the introduction.

If your organization runs something like this, we'd like to know.

Demos, Loady, and the next generation

Back at Black Hat, booth 4208 ran four demo stations and five live sessions on rotation. The lineup: multi-layered application security with Security Profiles in HAProxy Fusion, fleet-wide load balancer rate limiting, defending against HTTP protocol attacks, TLS at scale with ACME, and post-quantum TLS termination.

The swag verdict was unambiguous. Everyone loves Loady, our elephant mascot and the most reliable conversation-starter we own. After Loady, the biggest hits were the kids' T-shirts and onesies. A lot of today’s engineers got interested in this stuff young. Hopefully our giveaways for kids and families will help inspire the next generation. Our adult-sized T-shirts also earned a few laughs!

What's next?

See the security control plane in action: watch the HAProxy Fusion 2.0 on-demand webinar. 

Get a custom demo and consultation with our experts: request a demo.

Meet us at the next event: HAProxy Events page

This isn't a general hacker concern. The actors with the means to store encrypted traffic at scale (and eventually acquire the quantum computing resources to break it) are nation-states and large, well-resourced organizations. The other important detail: you can't tell it's happening. Passive traffic collection leaves no trace, and waiting isn't a viable posture.

In August 2024, NIST responded to this threat by finalizing its first post-quantum cryptography (PQC) standards: ML-KEM for key encapsulation, and ML-DSA, SLH-DSA, and FN-DSA for digital signatures. 

This post covers what happens during a TLS handshake, why quantum computers threaten the key exchange step specifically, and how HAProxy can protect your traffic with hybrid post-quantum cryptography right now.

How does the TLS handshake work?

Every TLS connection begins with a handshake, a brief negotiation that establishes which cipher suite to use, authenticates the server, and derives the symmetric keys that protect the session. The cipher suite is the combination of algorithms and key lengths governing the session. The vulnerability that post-quantum cryptography addresses lives in one specific step of this process: the key exchange.

Modern TLS stacks, whether running 1.2 or 1.3, use ECDHE (Elliptic Curve Diffie-Hellman Ephemeral) for that key exchange. Both sides contribute a fresh random value; the shared secret is derived from both contributions and immediately discarded. The classical security of ECDHE rests on the hardness of the elliptic curve discrete logarithm problem, which is effectively unsolvable on classical hardware. It is not unsolvable for a quantum computer running Shor's Algorithm.

TLS 1.3 (shown below) improves on 1.2 in ways that matter for this discussion: it makes ECDHE mandatory by removing static RSA key exchange, reduces the handshake to a single round-trip, and adds support for hybrid post-quantum key exchange. It also makes Perfect Forward Secrecy mandatory by design — more on that, and its limits, shortly.

Hybrid PQC requires TLS 1.3 because the named groups extension that carries the post-quantum component isn't available in TLS 1.2.

You'll see references to "hybrid key exchange" throughout this post. It means combining a classical algorithm (ECDHE) with a post-quantum algorithm (ML-KEM, or Module Lattice Key Encapsulation Mechanism) and using both outputs to derive the shared secret. Neither algorithm alone is enough to reconstruct it. It's a fail-safe in either direction: if ML-KEM has an undiscovered flaw, ECDHE still holds. If ECDHE is broken by a quantum computer, ML-KEM still holds. The hybrid approach also maintains backward compatibility, so clients that don't support post-quantum curves will negotiate classical ECDHE automatically.

If you want a deeper look at the mechanics of TLS 1.3 and round-trip improvements, we covered that in our TLS 1.3 & 0-RTT blog post.

Why do quantum computers break TLS?

Modern TLS key exchange relies on two math problems that are easy to compute forward and nearly impossible to reverse on classical hardware.

RSA depends on integer factorization. Multiplying two primes together is trivial: 17 × 23 = 391. Working backward from 391 to find 17 and 23 is manageable. Doing that with 600+ digit numbers is effectively impossible for any classical computer. ECDHE depends on the elliptic curve discrete logarithm problem, a different but similarly hard-to-reverse operation.

A sufficiently powerful quantum computer running Shor's Algorithm changes this, and Shor's Algorithm can solve both integer factorization and discrete logarithm problems efficiently. That means RSA and ECDHE, the two key exchange mechanisms securing virtually all classical TLS deployments, become breakable.

Quantum computers powerful enough to do this don't exist yet. But the timeline is shorter than most assume; Google's cryptography migration timeline puts the window at years, not decades. And there's a threat that doesn't require waiting for them.

ML-KEM is built on the Module Learning With Errors (MLWE) problem: given a system of linear equations with small random errors deliberately introduced, recovering the original values is computationally intractable even for a quantum computer. It doesn't reduce to factorization or discrete logs, so Shor's Algorithm does not apply. NIST standardized ML-KEM in 2024 because lattice problems of this kind are believed to be hard for both classical and quantum computers. You may also see it referred to by its earlier name, CRYSTALS-Kyber, which is still common in documentation and tooling.

If you want an interactive look at how Shor's Algorithm transforms factoring into period finding, this demo is worth a few minutes.

Perfect Forward Secrecy (PFS) and its limits

Perfect Forward Secrecy (PFS) is a property of certain key exchange mechanisms. When PFS is in place, each TLS session uses a completely independent, ephemeral key. Ephemeral means the key is generated fresh for that session and discarded immediately after. It's never stored on disk, never reused.

The practical upside: if an attacker later compromises your server's private key, they can't decrypt past sessions. Each session's secret is gone once the session ends.

PFS in TLS comes from ephemeral Diffie-Hellman key exchanges, specifically ECDHE. Both sides contribute a fresh random value per session. Neither side's value is ever reused. TLS 1.3 mandates PFS by removing static key exchange options entirely, which is one of the reasons it's a meaningful improvement over TLS 1.2.

But PFS has a limit that quantum computing exposes.

Why Perfect Forward Secrecy doesn't fully solve the quantum threat

A well-resourced attacker doesn't need to break encryption today. The strategy is to record encrypted TLS traffic now and wait until a cryptographically-relevant quantum computer exists, then use Shor's Algorithm to break the classical key exchange retroactively, sometimes described as "harvest now, decrypt later." It's a practical threat for any traffic containing data with a long sensitive shelf life: medical records, government communications, intellectual property.

PFS doesn't change this calculus, because the threat it protects against (an attacker stealing a server's long-term private key) is a different threat model entirely.  What Shor's Algorithm targets is the ephemeral key exchange itself, by solving the discrete logarithm problem against the recorded handshake. That handshake was transmitted in plaintext and is straightforward to capture passively, without any access to the server. Forward secrecy was designed for a world where breaking the key exchange was computationally out of reach, and that assumption no longer holds.

Hybrid post-quantum key exchange addresses this directly. By combining ECDHE with ML-KEM, breaking the shared secret requires defeating both algorithms simultaneously, and Shor's Algorithm currently cannot be used against the lattice-based component.

Configuring hybrid post-quantum cryptography in HAProxy

HAProxy Enterprise 3.2+ and HAProxy Community 3.3+ support hybrid post-quantum cryptography natively. This works because both versions ship with AWS-LC as their cryptographic library, which includes support for post-quantum curves. See our Supercharging HAProxy Community with AWS-LC Performance Packages blog post for details on the AWS-LC integration, and the AWS-LC PQ documentation for the full list of supported curves.

Here's a working configuration that enables hybrid PQC. The PQC-specific addition is two lines: the curve priority lists for bind and server sides. Everything else in the configuration below is standard TLS hardening we'd recommend regardless of post-quantum requirements.

You can verify hybrid PQC is negotiating correctly with BoringSSL's bssl client, which ships with HAProxy Community and HAProxy Enterprise packages by default. The path varies by version (this example uses HAProxy Enterprise 3.2), so adjust accordingly:

Once this configuration is in place, your TLS handshake follows a path that classical and quantum computers can't break independently:

Quantum computers that can break RSA and ECDHE don't exist yet. But adversaries can and do collect encrypted traffic today against the day when they will. NIST finalized its first post-quantum cryptography standards in 2024, and the ecosystem is moving fast.

HAProxy with AWS-LC gives you hybrid PQC without waiting for clients to catch up. The fallback curve order handles compatibility automatically. 

PQC carries a slight CPU penalty once enabled, but for most workloads this trade-off is worth taking. We have benchmarked both standard TLS and PQC-enabled TLS, and will publish the results in a follow-up blog post.

What’s next?

Migrating key exchange now is step one of a two-phase migration. Digital signatures are step two.

Hybrid ML-KEM key exchange protects the key agreement step of the TLS handshake, but TLS also uses digital signatures to authenticate certificates. Those signatures still rely on RSA or ECDSA, which are equally vulnerable to Shor's algorithm.

The NIST PQC standard includes ML-DSA (CRYSTALS-Dilithium) and SLH-DSA for post-quantum digital signatures. Support in certificate authorities and TLS stacks is coming.

One note on scope: HAProxy secures the client-to-edge connection. Traffic from HAProxy to your backend applications travels over a separate connection, and if those backends don't yet support PQC, that leg stays on classical crypto. Enabling PQC at the edge is still the right first step because it's the most exposed connection for passive collection. But a complete migration requires applying the same approach to your backend connections.

Frequently asked questions

For years, Liftoff relied on a managed enterprise proxy vendor. It worked, until it didn’t. As traffic grew, so did the challenges: rising operational costs, vendor lock-in, and performance limitations threatened their ability to maintain the ultra-low latency their ad tech platform demanded.

These obstacles led Liftoff to migrate to HAProxy, reducing costs by 87.6% and improving latency by 75%. Tommy Nguyen and Ken Chin shared their journey at HAProxyConf, and we unpack their story below.

Liftoff’s proxy was a managed service sitting outside their infrastructure. Every configuration change went through the vendor. Routine updates that should have taken a day could stretch across an entire sprint cycle.

The vendor’s platform also added extra network hops between Liftoff’s systems and their backend services. This added latency is a real problem for an ad tech company where milliseconds directly affect revenue.

Agility and performance weren’t the only challenges faced.

Costs scaled with traffic, but not in a manageable way. Their vendor's pricing model made it harder for the business to grow efficiently. And because the proxy was proprietary, Liftoff didn’t have the flexibility to change directions if their architecture needs shifted.

Liftoff decided they needed a sovereign infrastructure solution that they could own, configure, and run themselves.

Building their architecture with HAProxy

The team spent six months moving from initial testing to a production-ready HAProxy deployment. They ran performance tests, collaborated across teams, and built the automation and monitoring tooling needed before going live.

The architecture they landed on used GitHub Actions to trigger builds, HashiCorp Packer to create pre-configured machine images, and Ansible to handle consistent provisioning across servers. AWS EC2 instances ran HAProxy, with Route 53 directing inbound traffic. AWS Network Load Balancers (NLBs) sat between HAProxy and backend Kubernetes clusters spread across multiple availability zones.

The results were immediate and significant. Operational costs dropped by 87.6%. Latency improved by 75%. Configuration deployments that previously took weeks could now be completed in a single day — a 93% improvement in deployment speed.

That was phase one.

Using HAProxy to address outages and NLB blind spots

After a period of stable operation, a major traffic failure hit the Liftoff platform. The team couldn't restore normal service for several hours. The outage was painful, but what made it worse was not being able to pinpoint the cause quickly.

The NLBs sitting between HAProxy and the backend pods were a blind spot. There wasn't enough visibility into that layer to diagnose what was happening during the incident. Troubleshooting required guesswork, and that cost time.

The incident pushed the team to rethink the architecture – to lean more on the trusted and reliable HAProxy deployment. The question wasn't just how to prevent another failure; it was how to make HAProxy the single, observable control point for all traffic decisions.

Rebuilding with dynamic service discovery

To make that work at scale, the team integrated Consul service discovery with HAProxy. Backend services automatically register themselves in Consul's catalog. HAProxy reads those records in real time, so its routing table stays up to date without manual changes or configuration redeployment. When a pod turns unhealthy, Consul removes it, and HAProxy stops sending traffic there — immediately, automatically.

As a result, HAProxy now makes the routing decisions. It knows which backends are healthy, where they are, and how to reach them. There's no secondary system making routing choices that HAProxy can't see.

This flatter design brought an additional 20% reduction in operational costs, simply by eliminating the abstraction layer that was no longer needed. While that improvement was not the original intention, it reflects how much unnecessary overhead the old architecture carried.

End-to-end visibility with HAProxy

The new architecture gave Liftoff something they hadn't had before: end-to-end visibility from the moment a request hits HAProxy through to storage.

They use HAProxy's native Prometheus exporter to export metrics to Prometheus, then visualize everything using a modified version of HAProxy's Grafana template. The dashboards track connection rates, backend response times, latency, HTTP response codes, and Consul catalog counts throughout the day.

Because Liftoff's traffic follows predictable patterns, they can also run reliable week-over-week comparisons and spot anomalies early. They take their logs out of HAProxy and ingest them into their Loki, giving the team a centralized place to query and analyze log data alongside their metrics.

This kind of observability stack is what the first architecture was missing. Now, when something goes wrong, the team has the data to diagnose it quickly.

What the HAProxy roadmap looks like for Liftoff

Liftoff is planning to upgrade HAProxy to the latest version, with several specific capabilities driving the decision.

Glitch limit functionality will help the team handle protocol glitches without draining CPU resources. Enhanced logging will give them finer-grained data at the HAProxy layer, improving their ability to correlate events across the stack. Enhanced stick tables and improved traffic prioritization will let them shape traffic more precisely across different service tiers (particularly useful when some services have tighter latency requirements than others).

They're also planning to move from a third-party auto-scaling solution to a first-party one, giving them more direct control over how HAProxy instances scale against their specific traffic patterns. And they're working on grouping HAProxy instances by traffic destination, so that high-priority or latency-sensitive services get dedicated capacity rather than competing for shared resources.

Further out, the team is watching HAProxy's AI gateway capabilities. As LLM-based API traffic becomes more common in their stack, routing it through HAProxy (with the same performance, configurability, and observability they already rely on) is a natural extension of what they've built.

While Liftoff achieved these results with the open source version of HAProxy, organizations that need enterprise-grade service discovery, automated configuration management, direct-to-pod routing, centralized observability, and high-throughput performance at scale can get these capabilities out of the box with HAProxy One, the world's fastest application delivery and security platform.

The report carries a CVSS v4.0 score of 8.7 (High). We want to be transparent about that score and equally clear about our assessment: the real-world risk is low. This is not realistically exploitable.

The issue was observed only on a custom-modified HAProxy build, and neither our team nor the reporter was able to reproduce it on a standard build. There is no known proof-of-concept and no evidence of exploitation in the wild. The CVSS vector also reflects an availability-only impact (a process crash) with no impact to confidentiality or integrity.

The reason comes down to how modern systems manage memory. Triggering this bug requires an allocation to return NULL under memory exhaustion. Still, on a normally configured Linux system, the kernel's out-of-memory (OOM) killer terminates a memory-starved process before that can happen. Returning NULL in this path generally requires a non-default memory-overcommit configuration that very few deployments use. In practice, a server would already be in a critical low-memory state before this code path could be reached.

We committed a fix regardless, out of respect for the report and to keep our codebase clean, and we are rolling it out through our normal release process rather than as an emergency patch. We recommend customers update to a fixed version once it is available for their product. In the meantime, the most effective safeguard is the one we recommend for any production deployment: size HAProxy to the memory available on its host so the process does not approach Out-of-Memory (OOM) conditions.

Vulnerability details

• CVE Identifier: CVE-2026-55204

• CVSS v4.0 Score: 8.7 (High) — base score assigned by the CNA (VulnCheck)

  • Vector: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

  • For reference, the equivalent CVSS v3.1 base score is 7.5 (High): CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

• Weakness: CWE-476 (NULL Pointer Dereference)

• Affected component: HAProxy HPACK dynamic header table — hpack_dht_insert() in src/hpack-tbl.c

• Reported by: Tristan Madani

• Published: June 18, 2026 (CVE source: VulnCheck)

• Description:

  • The issue was first reported to HAProxy Community Edition as a minor bug, demonstrated using a custom version of HAProxy.

  • hpack_dht_insert() does not validate the return value of hpack_dht_defrag() when the memory pool is exhausted. HPACK dynamic table insertions under memory pressure can dereference a null pointer, crashing HAProxy worker processes and causing a denial-of-service.

  • HAProxy Technologies was unable to reproduce the bug with a standard version of HAProxy, and has no evidence of exploitation. CISA's automated SSVC assessment also records exploitation status as "none."

  • Because the trigger is memory-pool exhaustion, deployments with insufficient memory (reaching OOM or similar states) are most relevant to this issue.

HAProxy's assessment

Based on our analysis, we do not consider this a meaningful avenue for attacking or weakening HAProxy services. A rolling release is typical for HAProxy Enterprise patches addressing low-risk issues: fixes flow continuously from HAProxy Community Edition and are picked up for upcoming HAProxy Enterprise releases and backports. 

We are publishing this advisory because a CVE with a high CVSS score has been filed, and we want customers to have the full picture (both the score and our assessment) so they can make an informed decision about when to update.

Affected versions and remediation

This issue is present across currently supported versions of HAProxy — the CVE record cites all releases up to and including 3.4.0, so it is not limited to the latest branch. Because the affected code is part of the core HTTP/2 engine, products built on HAProxy (HAProxy Community Edition, HAProxy Enterprise, and HAProxy ALOHA) should be assumed in scope. The fix is committed upstream in commit 9a6d1fe.

At the time of writing, the fix has not yet been included in a tagged HAProxy Community Edition release — it is available in source for anyone who wishes to compile it themselves — and HAProxy Enterprise packages and builds are being rebuilt now. The HAProxy Community Edition team is targeting a tagged release in its next release series

The issue is fixed in HAProxy Enterprise after the following builds:

The permanent fix is delivered by updating to a patched version. In the meantime, the most effective safeguard is the one we recommend for any production deployment: size HAProxy to the memory available on its host so the process does not approach Out-of-Memory conditions. A system kept within healthy memory limits will not reach the state required to trigger this issue.

Upgrade instructions

Once fixed images are available, users of affected products should update by pulling the latest version for their respective release track. Instructions are linked below (customer login required):

• Upgrade HAProxy Enterprise

• Upgrade HAProxy Enterprise with HAProxy Fusion

• Upgrade HAProxy ALOHA

• HAProxy Community Edition: update to the fixed tagged release once published, or build from source.

Support

If you are an HAProxy customer with questions about this advisory or about upgrading to the latest version, please contact our support team.

We were there to talk about HAProxy One, the world’s fastest application delivery and security platform. It puts load balancing, next-gen security layers, Kubernetes routing, and API gateway in a single stack. HAProxy Enterprise is the data plane: it processes the traffic. HAProxy Fusion is the control plane: it handles management, observability, automation, and integration with the infrastructure around it. HAProxy Edge is the global edge network: it provides fully managed application delivery services from a global low-latency network.

As we spoke to attendees, four clear themes kept coming up. These are patterns from real booth conversations with engineers across company sizes, industries, and cloud maturity levels. Each pattern reveals a technical challenge and a business need that HAProxy One is a great fit for: 

• Integration with AWS 

• Portability across infrastructure 

• Consolidation of tool-sprawl (especially in security) 

• Pricing that helps you scale

1. Designed to work on AWS

The engineers we spoke to wanted tools designed to work in the AWS environment. Third-party tools that require significant integration work lose before they start.

AWS-native services like ALB and AWS WAF work out of the box. Everything else can feel bolted on. Engineers want the performance and flexibility of best-of-breed tooling, without the operational friction.

One question came up in various forms: "How does your product integrate with AWS?" This was an understandable pre-qualification question. If the answer wasn't convincing, the conversation moved on.

Fortunately, HAProxy One provides scalable AWS load balancing and security:

• HAProxy Fusion Control Plane connects directly with AWS Route 53, and supports Auto Scaling Group awareness for load balancing with HAProxy Enterprise.

• Hardened AWS AMIs for HAProxy Enterprise ship with automatic HAProxy Fusion registration.

• Native support for Graviton instances, with performance measured at over 2 million HTTPS requests per second on Graviton2. 

• SSL/TLS processing with AWS-LC cryptography delivers up to 2X the TLS performance of OpenSSL 3+.

• HAProxy Enterprise is in the AWS Solutions Library, co-validated and architecturally integrated with the platform.

HAProxy is built to live inside an AWS environment without being dependent on it.

2. Cloud-neutral and infrastructure-agnostic

The engineers who sounded most nervous were the ones with the most mature AWS environments and the deepest integration, who faced the biggest impact if something were to change.

Those who have built on AWS for years know that every AWS-native architectural decision is a sunk cost that makes the next one harder to reverse. They want full AWS integration today without closing the door on tomorrow.

More than one engineer said something to this effect: they were all-in on AWS right now, but they'd been all-in on things before, and they knew how those stories could end. So they can’t afford to be locked into one environment. Any assets they can carry over to another cloud or on-premises data centers has more long-term value. 

HAProxy suits this approach. It runs the same platform, with the same configuration and behavior, in any environment: on-prem, AWS, GCP, Azure, bare metal, VMs, and Kubernetes. No proprietary APIs, no “migration tax” when architecture evolves. 

Engineers were asking for exactly this: for any application, on any infrastructure, without compromise.

3. One unified platform to replace many tools

Security was the number-one conversation starter at the NYC booth, and the most common frustration was that securing an AWS application typically means running multiple products. A load balancer here, a WAF somewhere else. Then a third product for DDoS, each with its own console and its own incident playbook. Each additional tool adds operational overhead. It also adds a network hop in the request path, and the latency cost compounds. So does the attack surface between integrations.

AWS makes it easy to add another managed service. The bill and the complexity grow together. Several engineers described sprawl they'd built one service at a time and were now trying to rationalize.

The billing complexity was a specific frustration, but the deeper concern was decision overhead. Every additional capability engineers needed as they grew meant evaluating a new tool, budgeting for it separately, and absorbing the operational cost of adding it to their deployment. Sprawl is the inevitable outcome when each problem gets its own product.

HAProxy One puts load balancing, WAF, bot management, DDoS protection, Kubernetes ingress and routing, and API gateway in a single platform. All of it runs through one data plane in the traffic path, managed by one sovereign control plane (that you deploy and manage). 

The HAProxy Enterprise WAF, powered by the Intelligent WAF Engine, delivers exceptional balanced accuracy and ultra-low latency, so consolidation doesn't require compromising on security or performance. The HAProxy Enterprise Bot Management Module, powered by the Threat Detection Engine, stops complex, high-impact threats including application layer DDoS, brute force attacks, web scrapers, and vulnerability scanners. These powerful security layers run locally with no external connection, keeping your traffic and telemetry private.

Can one product excel in all these categories, without compromise? Well, that’s what more than 900 verified user reviews on G2 tell us. In the latest G2 Summer 2026 Grid^® Reports, HAProxy received a perfect Satisfaction Score of 100, and was named a Leader in Load Balancing, WAF, DDoS Protection, Container Networking, and API Management.

A unified stack is faster to operate, harder to misconfigure, and reduces the cost and complexity of decisions as you grow.

4. Pricing that makes sense at scale

Consumption-based pricing works in the early stages. At scale, it stops working for the customer.

Any traffic spike (usually good news) comes with a matching bill (bad news). DDoS events and high-volume API endpoints are no different. The engineers most exposed to this problem are exactly the ones who've succeeded most. High-traffic applications protected by AWS WAF and load-balanced by ALB are billed per request or per connection, and at scale that adds up fast.

Several engineers described the experience of a strong traffic month where their security bill scaled with it at exactly the same rate — growth penalized by the model designed to protect it. Their eyes would light up at the thought of flat, predictable pricing.

HAProxy is instance-based: you pay for the instance, not the traffic. No per-request fees, no bill surprises during high-traffic events. At scale, the TCO advantage over consumption-priced alternatives is substantial and compounds. 

There's a longer-term dimension here as well. Pricing predictability is partly a vendor stability question. HAProxy is independently owned and profitable, not subject to the acquisition cycles that have repriced infrastructure for a lot of teams over the last few years.

Cloud and AI without compromise

These four themes aren't coincidental. Engineers see immense value in building on AWS, but they are also keenly aware of the trade-offs that come with investing heavily in one environment.

They want to build well, not just build fast. Depth without dependency. Consolidation without compromise. Pricing that rewards growth and success. That's what HAProxy One is built to deliver.

These factors are particularly useful for engineers building internal AI infrastructure: load balancing across GPU clusters, routing requests to the right model, handling inference traffic at scale. Engineers want to know whether their infrastructure will be agile and scalable enough to keep up, without introducing dozens of new components.

The good news is the traffic management fundamentals that HAProxy excels at — intelligent routing, integrated security, and performance efficiency — apply directly to AI inference. HAProxy is already the load balancing layer in production AI deployments: NVIDIA Run:ai v2.24 recommends HAProxy for the Kubernetes ingress controller, and Anyscale documented an 11.1X throughput improvement using HAProxy with Ray Serve. 

The engineering fundamentals don't change when the payload is a prompt.

If you want to see HAProxy One in action, contact our team to schedule a demo and a consultation.

For a decade, Clover ran HAProxy at the center of its infrastructure. At HAProxyConf, engineers Dilpreet Singh and Anirudh Ramesh explained how they pushed that relationship further with the HAProxy One platform, using HAProxy Enterprise and HAProxy Fusion Control Plane to build a traffic routing model they call “rainbow deployments.”

Blue-green deployments provide teams a safe way to release software. You run two environments in parallel and shift traffic from the stable version to the new one when it is ready. If something goes wrong, you can reroute the traffic back.

But Clover’s business demands more than a clean two-environment switch can provide. The company serves a wide range of merchants, including traditional banks and financial institutions that are cautious about version changes (and the risk they can pose to their business). Some customers need to stay pinned to specific versions, while others require hotfixes and experimental features without affecting the broader merchant base.

Blue-green deployments cannot provide that level of control. Once you switch traffic, everyone moves together. What Clover needed was a way to run multiple versions simultaneously and route each customer to the right one.

A deployment model built on multiple colors

HAProxy Enterprise sits in the middle of all this, deciding which color handles each request, but how is this accomplished?

The routing uses a weighted map file with number ranges corresponding to different backends. HAProxy Enterprise generates a random number between 1 and 100, looks up its position in the map, and sends the request to the corresponding backend. A split of 1 to 33 might route traffic to green. 34 to 67 to blue. 68 to 100 to red. This would give each color roughly equal traffic, but the team has the freedom to adjust those ranges at any time to shift traffic incrementally toward a new release or to pin a specific customer group to a single backend, entirely.

This approach lets Clover release version changes during normal business hours. Since the new version initially receives a controlled fraction of traffic, the platform team can monitor for problems and expand the rollout gradually. If something breaks, they adjust the map file. No all-hands rollback, no off-hours deployment windows.

How the infrastructure fits together

In their Hashicorp Nomad cluster, Clover runs three versions of their COS monolith, each represented by a color. Three blue nodes run the blue version of COS, three green nodes run the green version, and three red nodes run the red version. Each node also runs an HAProxy Enterprise instance as a sidecar container.

Traffic from the outside world arrives and is distributed across all nine nodes on port 8080. At that point, HAProxy Enterprise load balancer takes over. The lb-haproxy frontend receives the request, consults the weighted map file, and forwards it to the appropriate color backend. The request then travels to the HAProxy Enterprise instance running on a node of that color, which terminates SSL and passes the decrypted request to COS running locally on port 8020.

HAProxy Enterprise also handles egress from COS. When the monolith needs to talk to a microservice running in Kubernetes, it makes a request to a local port. HAProxy Enterprise picks that up and forwards it to the Kubernetes Istio ingress, which routes it internally. This turns HAProxy Enterprise into a service mesh for COS, without requiring the monolith itself to know where downstream services live.

Bootstrapping and dynamic backend management

The bootstrapper creates the cluster, configures Consul integration, and registers backend resource templates for each color. HAProxy Fusion then uses Consul service discovery to dynamically populate the backend server pools. When Clover registers a Nomad node in Consul with a blue, green, or red tag, HAProxy Fusion picks it up and adds it to the matching backend. Scaling the cluster up or down does not require manual backend configuration.

Once HAProxy Fusion has the configuration, it pushes it to all nine HAProxy Enterprise instances simultaneously. Changes that previously required touching individual load balancer configs now happen in one place and propagate automatically.

Low-risk deployments at any time of day

The shift to rainbow deployments changed how Clover thinks about releases. The team can now release during the day because a bad deployment affects only a slice of traffic, not every merchant at once. They can test a new version under real load by giving it 10 or 20 percent of traffic before committing fully. They can pin conservative customers to a stable version indefinitely while still moving the rest of the platform forward.

Singh put it plainly during the talk: zero on-call pages and zero drama. HAProxy has operated as a silent workhorse in Clover's stack for ten years, and the move to HAProxy Fusion extends that reliability into a more complex multi-version deployment model.

What comes next

The map file and configuration changes were still applied manually through the HAProxy Fusion UI. The team's next goal is to automate that fully through the REST API, so developers can trigger traffic shifts and version pins without touching the HAProxy configuration directly.

Clover also plans to build an application model that abstracts away the deployment target entirely. Application teams would define what they want to deploy, and the platform team's tooling would handle whether it goes to Nomad, Kubernetes, or a cloud function, with HAProxy routing configured automatically as part of the process.

Every cluster, backend, frontend, and Consul integration is configurable through the API, which means the entire deployment pipeline can eventually run without a human touching the load balancer configuration at all.

At a glance

• The issue: A critical resource-exhaustion vulnerability known as the "HTTP/2 Bomb" affects multiple major web servers, including NGINX, Apache HTTPD, Microsoft IIS, Envoy, and Cloudflare Pingora (CVE-2026-49975).

• Severity: Critical. A single home computer on a 100 Mbps connection can knock a vulnerable server offline in seconds.

• Status: Proof-of-concept (PoC) code is available, and technical details are public.

• HAProxy protection:

  • HAProxy Enterprise / Community: HAProxy is architecturally safe from being overwhelmed by this exploit due to its strict memory constraints.

  • Configuration: An optional configuration update can be applied immediately to drop malicious clients at the network edge and conserve CPU cycles.

What is CVE-2026-49975?

On June 2, 2026, security researchers disclosed a remote denial-of-service (DoS) exploit named the HTTP/2 Bomb. This flaw allows unauthenticated remote attackers to rapidly exhaust server memory, rendering major web servers inaccessible.

Technical impact

The vulnerability stems from an attack chain that combines two older techniques: a compression bomb and a Slowloris-style hold.

1. Compression bomb: The attack targets HPACK, the HTTP/2 header compression scheme. The attacker seeds the server's dynamic table with a nearly empty header and emits thousands of 1-byte indexed references to it. Because the header is tiny, standard decoded-size limits never fire.
   
   However, each 1-byte reference forces the server to create a fresh per-entry bookkeeping allocation, causing massive memory amplification (up to 5,700:1). For servers that cap field counts, attackers bypass limits by splitting the Cookie header into individual crumbs, which Apache and Envoy fail to count properly.

2. Slowloris hold: The attacker advertises a zero-byte flow-control window. This action blocks the server from finishing its response, while the attacker drips 1-byte WINDOW_UPDATE frames to reset send timeouts.

This combination pins allocations in memory indefinitely. A single client can consume and hold 32 GB of server memory in less than 20 seconds, pushing backend machines into swap and killing system performance.

• Default configurations of NGINX (before 1.29.8)

• Apache HTTPD (before mod_http2 v2.0.41)

• Microsoft IIS (Windows Server 2025

• Envoy (1.37.2 and older

• Cloudflare Pingora

Defending your infrastructure: Virtual patching vs. host reconfiguration

If your web servers are exposed directly to the internet without a security proxy in front of them, you must immediately configure manual host limits or rush out vendor updates to completely remove the threat:

Option A: Manual server reconfiguration

• Patch the source: Apply the official vendor patches to your backend web servers as soon as possible.

  • NGINX: Upgrade to version 1.29.8 or later to use the new max_headers directive.

  • Apache HTTPD: Upgrade mod_http2 to version v2.0.41 or later.

• Disable HTTP/2 on un-patched servers: If patches are unavailable (such as for IIS, Envoy, or Pingora), disable HTTP/2 on those specific servers to avoid exposure.

• Cap host worker memory: Configure cgroups, container limits, or ulimit -v tight enough on your web servers so that a bombed worker gets OOM-killed and respawned clean before it drags the host machine into a memory-swap loop.

Option B: “Virtual patching” with HAProxy

If you deploy HAProxy or HAProxy Enterprise in front of your web servers, none of the intrusive backend modifications above are required. Because HAProxy acts as an isolated protocol terminator at the edge of your network, it safely handles client-side HTTP/2 processing within its own tightly budgeted, fixed-size memory boundaries. 

It then passes sanitized (un-bombable) traffic down to your internal infrastructure. Even if your underlying web applications remain un-patched or vulnerable, they are immediately 100% protected. HAProxy acts as an instant virtual patch that removes the administrative rush to reconfigure your core server fleet.

How HAProxy protects your infrastructure

While patching upstream web servers is the ultimate remediation, HAProxy sits at the edge of your network, providing a critical first line of defense. You can stop the attack before it ever reaches your vulnerable servers.

Unlike most load balancers and reverse proxies that struggle with multiplexed streams because they rely on dynamic memory tracking, HAProxy stands out. HAProxy treats HTTP/2 streams with strict memory constraints and processes frames at bare-metal speeds.

Automatic protection with HAProxy

HAProxy is architecturally safe from being overwhelmed by the HTTP/2 Bomb exploit. Its core design limits the memory footprint of individual connections and streams, preventing an attacker from triggering out-of-memory (OOM) conditions or massive memory inflation that hits other servers. HAProxy stays stable even under high-intensity resource-exhaustion attempts.

You don't need to change anything for HAProxy itself to survive this attack

Optional: Immediate mitigation configuration

Even though HAProxy will not crash, you can use its configuration layer to actively reject attacking clients rather than spend CPU cycles processing malformed frames. In fact, it will actually “reverse” the attack by causing the malicious client to use twice as much memory and 100 times as much CPU as HAProxy!

Using HAProxy stick tables, you can track anomalous protocol behavior, including rapid resets and malformed continuation frames, and reject malicious connections before they reach application backends. 

Add the following configuration snippet to your frontend to conserve resources and frustrate the attacker:

Conclusion

Vulnerabilities like CVE-2026-49975 highlight the volatility of the modern threat landscape and show that relying solely on patching backend applications leaves a dangerous window of exposure. HAProxy provides the robust, high-performance security needed to virtually patch vulnerabilities instantly at the edge of your network.

Next steps:

• Community users: Apply the optional mitigation configuration above to reject abusive traffic early and reduce unnecessary CPU load. This will also reject other types of similar attacks.

• Evaluate your security: If you want comprehensive threat protection and automated zero-day defense, start a free trial of HAProxy Enterprise load balancer today.

Dynamic backend management simplifies integration with modern architectures, memory efficiency improves across a broader range of workloads, native cryptographic operations at the proxy layer open new possibilities for API security architectures, and OpenTelemetry support makes HAProxy a first-class participant in distributed tracing pipelines. 

Meanwhile, operational improvements in health checking, attack resistance, and log management mean HAProxy remains the best choice for the world's most demanding environments.

These advances extend HAProxy's lead across G2 categories in Load Balancing, API Management, Container Networking, DDoS Protection, and Web Application Firewall (WAF).

What’s new in HAProxy 3.4?

HAProxy is the world’s fastest and most widely used software load balancer. It provides high availability, load balancing, and best-in-class SSL/TLS processing for TCP, QUIC, and HTTP-based applications.

HAProxy is the open source core that powers HAProxy One, the world’s fastest application delivery and security platform. The platform consists of a flexible data plane (HAProxy Enterprise) for TCP, UDP, QUIC, and HTTP traffic; a scalable control plane (HAProxy Fusion); and a secure edge network (HAProxy Edge).

HAProxy is trusted by leading companies and cloud providers to simplify, scale, and secure modern applications, APIs, and AI services in any environment.

How to upgrade to HAProxy 3.4?

You can install HAProxy 3.4 in any of the following ways:

• Install the new HAProxy packages for Ubuntu, Debian, and RHEL.

• Run it as a Docker container. View the Docker installation instructions.

• Compile it from source. View the compilation instructions.

Flexibility

The headline addition is the introduction of dynamic backends, which extends HAProxy’s strengths in modern, automated environments. Building on the dynamic servers capability introduced in HAProxy 2.4, dynamic backends allow backends to be added, published, and deleted at runtime without requiring a reload. The result is fully automated backend lifecycle management, driven directly from your control plane or orchestration layer.

Experimental QMux support also lands in 3.4, enabling HTTP/3 and QUIC over TCP, useful in networks where UDP is blocked or not a suitable transport layer.

Dynamically add and delete backends

New HAProxy Runtime API commands let you add, delete, and publish backend sections. Publish makes the backend available for use. 

First, consider this HAProxy configuration:

We use the HAProxy Runtime API to perform the following:

• Create a new test-backend backend with a server, inheriting settings from the mydefaults defaults section.

• Enable the server and its health checks.

• Publish the backend so that the frontend can use it.

• Add an entry to our map file to route requests for the path /test to the new backend.

The corresponding HAProxy Runtime API commands are shown below:

To delete the server, backend, and map entry, use the following commands:

• A backend referenced by the default_backend or use_backend directives in a frontend, will be skipped if it has been disabled or unpublished. Set force-be-switch to override and force HAProxy to use the backend.

• In order to ensure that all named defaults sections are available to dynamic backends, they are now stored in memory. If you don't intend to use dynamic backends,  set the global tune.defaults.purge directive to free that memory.

QMux protocol

This version adds experimental support for QMux, a protocol that, according to the draft specification, allows sending QUIC frames over any transport protocol that provides an ordered, reliable, bidirectional, byte-oriented stream. It enables TCP to transport QUIC, offering an alternative for networks where QUIC's processing overhead over UDP outweighs its benefits (e.g., fast and reliable intra-datacenter networks).

To enable QMux, add the alpn h3 argument to the target frontend bind or backend server line and include expose-experimental-directives in the global section. Since the protocol is still in its early stages, one practical way to test this is to chain two HAProxy instances together, as illustrated by the configuration below, which allows QMux to be evaluated on both the frontend and backend.

HAProxy can now be built with the latest version of Lua (version 5.5), incorporating five years’ worth of improvements in the language. 

A new global directive, tune.lua.openlibs, provides control over which Lua standard libraries are loaded. Omitting unused libraries reduces the attack surface of Lua scripts and helps enforce security practices, particularly when scripts originate from third parties or external customers. For example:

• Omitting os disables os.execute() and os.exit().

• Omitting io disables io.open() and io.popen().

• Omitting package prevents loading native C modules via require().

• Omitting debug prevents introspection of HAProxy internals via debug.getupvalue(), debug.getmetatable(), or debug.sethook().

Set timeouts dynamically

The http-request set-timeout directive, introduced in HAProxy 2.4, originally gave the ability to change the timeout server and timeout tunnel values dynamically on a per-request basis. HAProxy 2.9 extended it to cover timeout client. Now, in HAProxy 3.4, http-request set-timeout can also adjust the values of timeout connect, timeout queue, and timeout tarpit. Together, these make it easier to apply application-specific timeouts, especially when combined with map files.

New fetches have been added to return the values of these timeouts: be_connect_timeout, be_queue_timeout, be_tarpit_timeout, cur_connect_timeout, cur_queue_timeout, cur_tarpit_timeout, and fe_tarpit_timeout.

Binary HTTP headers

New HTTP request and response actions manage (add, set, or delete) HTTP headers, storing them as data with a variable-length integer binary encoding. Refer to the documentation for these actions:

• add-headers-bin

• set-headers-bin

• del-headers-bin

Passing headers as binary data is a convenient way to modify them as a group rather than individually. This format is commonly used with the Stream Processing Offload Protocol (SPOP), making these actions particularly useful when communicating with stream processing offload agents. HAProxy also provides the req.hdrs_bin and res.hdrs_bin fetches, which return request and response headers in this format. Captured headers can be stored in variables and restored to their original state when needed.

This simplifies the exchange of multiple HTTP header fields between HAProxy and an SPOE agent: headers can be serialized and deserialized via a single variable, allowing multiple headers to be exchanged with a single declaration when the agent is trusted. A matching prefix can be specified on these actions to isolate the headers that an agent is permitted to manipulate.

QUIC protocol

This release introduces several improvements to HAProxy's QUIC protocol implementation:

• The quic-cc-algo argument is now supported by the server directive, whereas it had been supported only by the bind directive. This argument defines the QUIC congestion control algorithm, allowing the algorithm to be tuned independently for the frontend and backend network topologies. This change has been backported to HAProxy 3.3.

• The new global directive tune.quic.fe.stream.max-total limits the maximum number of requests that a single QUIC connection can handle. Once the limit is reached, HAProxy initiates a graceful shutdown of the connection (a GOAWAY frame in HTTP/3) and the connection is closed when all remaining transfers are completed.

HTTP compression

The syntax for HTTP request and response compression has been revised. Previously, compression was enabled by setting filter compression in a backend, with the option to set the compression direction directive to indicate whether to compress requests, responses, or both. The new model splits this into two filters: filter comp-req for request compression and filter comp-res for response compression. Separating the two simplifies the eventual addition of a decompression filter.

The following example compresses responses:

A new directive, filter-sequence, provides explicit control of the order in which filter directives are applied. Previously, filter execution was determined by the order in which filters were declared. With filter-sequence, filters can now be declared in any order and their execution sequence is managed independently. This is especially useful when execution order affects behavior. A good example is traffic shaping configurations that combine bandwidth limiting and compression filters. Placing compression before the limiter causes the limit to be applied on compressed traffic, which changes whether the traffic is actually throttled.

Another practical benefit of the filter-sequence directive is that any filter declared in the configuration, but omitted from the sequence directive is skipped. That's a convenient way to temporarily disable a filter without removing it from the configuration.

do-log action

In HAProxy 3.4, the do-log action now accepts the name of a log profile section as an argument.

The do-log action, introduced in version 3.1, emits custom log messages at various stages of request and response processing. The workflow is straightforward: define a log-profile section with log format strings (templates), then have do-log invoke them. For instance, a log format string might print the value of a variable named req.log_message during the processing of HTTP request rules. In the corresponding frontend, the variable would be set and then invoked with http-request do-log to log its value. 

Previously, the log profile was selected per frontend via a log line. That meant that every do-log action in a specific frontend had to use the same log profile. Now each do-log action can specify its own profile. This gives you greater flexibility in choosing the log format strings to use depending on the type of request.

HAProxy's buffer system has been reworked: large buffers can be allocated on demand for body-inspection workloads, eliminating the need to raise the global tune.bufsize and inflate memory consumption across every connection. Small buffers can also be substituted for queued and retried requests, reducing memory pressure under load. 

A scheduler overhaul preserves low latency under extreme load, shared stats counters can be split by thread group, and new CPU topology controls deliver further gains on large-core-count hardware.

Tuning buffer size

New buffer size options provide finer-grained control over the amount of memory HAProxy uses for different categories of data. Buffers play a central role in HAProxy's operation and are used in various places to store incoming and outgoing data, including HTTP requests and responses, log messages, health check exchanges, and payload data. A uniform global buffer size often results in suboptimal memory allocation: a large buffer may waste memory when used to store small queued requests, while a smaller buffer might be insufficient to handle larger payloads, such as HTTP message bodies.

The new global directives tune.bufsize.large and tune.bufsize.small allow distinct sizes to be defined for different categories of data. The corresponding directive option use-small-buffers, set in a backend or defaults section, enables the small buffer for queues, L7 retries, and health checks. The large buffer applies to the action wait-for-body, used during HTTP message body processing. These directives enable appropriate buffer sizes for these use cases, while keeping the global buffer size unchanged.

The release also adds tune.cli.max-payload-size, which defines the maximum payload size accepted by the HAProxy Runtime API.

Task scheduler

As a request moves through HAProxy, different stages of processing are handled by short-running functions called tasks. HAProxy's task scheduler determines which task will run next on each thread based on each task's priority and urgency. This release includes some enhancements to the scheduling mechanisms that address inconsistencies in wake, queueing, and prioritization behavior for tasks. These are edge cases that surface under sustained attack traffic or recovery scenarios. Testing confirms reduced latency when processing large queues of tasks and improved responsiveness of the HAProxy Runtime API.

Stats page counters

A new directive, stats calculate-max-counters, controls whether stats max counters are computed. Counters in this category include the max connection rate per second, max session rate per second, and max request rate per second.

Calculating maximums requires an expensive coordination between all threads, and in practice, virtually nobody uses it anymore since it only lasts for the process's lifetime; today, users have external solutions that collect stats and calculate maxes over periods of time instead.

This directive is enabled (on) by default; it may be set to off to disable these counters and save resources.

Automatic CPU binding

HAProxy 3.2 introduced options for tuning the automatic CPU binding, or how HAProxy organizes its threads to make efficient use of the underlying hardware. Version 3.4 adds a global keyword, cpu-affinity, that enables more control over how the threads bind to CPUs. HAProxy organizes its threads based on system topology and assigns  each thread group a set of CPUs; threads in a group are only allowed to run on those CPUs.

On NUMA systems, this keeps inter-thread operations within physically adjacent CPUs to reduce latency. The default, per-group, lets any thread in a group run on any CPU assigned to that thread group. While this offers the most OS flexibility in scheduling, this may not always be the best choice for latency. The options for cpu-affinity allow changes to this behavior:

• per-core: a thread may run on any hardware thread of a single SMT core (typically two threads per core in modern SMT implementations). The OS retains flexibility in scheduling IRQ activity. For example, from the NIC. HAProxy's threads can run on either hardware thread, keeping latency between HAProxy and the NIC low.

• per-thread: each thread will be bound to a single, specific hardware thread. Stricter than per-core, which permits movement between the hardware threads of a core.

• per-ccx: on systems with multiple CCX, such as AMD EPYC, this setting allows each thread to run on any hardware threads within all the cores of a single CCX.

There is an additional loose option for cpu-affinity per-group (cpu-affinity per-group loose). When a set of CPUs must be split over several thread groups, this allows multiple thread groups to use all CPUs in the list without each thread group being confined to a specific subset of the CPUs. The default, auto, which prevents this sharing by assigning each group to its own subset of CPUs, is usually the better choice. However, loose can perform better when CPU usage is uneven across groups.

This release adds a new threads-per-core option for the cpu-policy global directive, accepting a value of either 1 or the default, auto. Setting the value to 1 constrains HAProxy thread to a single thread per core on SMT-enabled CPUs (such as those implementing Intel's Hyper-Threading), leaving the other thread of the core free for other usage, most commonly the NIC. Improved performance has been observed in situations where there is high network activity on the same CPUs or during periods of frequent reloads that result in multiple HAProxy processes remaining active for extended periods of time. With the default auto setting, HAProxy creates a thread per each hardware thread. When threads-per-core is set to 1 and no explicit cpu-affinity value is set, the affinity defaults to per-core.

The following examples illustrate common configurations.

Intel Xeon with 64 cores with SMT (Hyper-Threading) enabled, where HAProxy will use one thread and the NIC may use the other thread of the same cores:

The next example involves AMD EPYC with 4 cores per CCX, where each thread in a group may use all hardware threads within a single CCX:

A new global option, max-threads-per-group, sets the maximum number of threads permitted in a single thread group. HAProxy defines the number of thread groups automatically based on the underlying hardware, and any tuning directives, including cpu-policy and cpu-affinity. On NUMA systems, this value often corresponds to the number of CPUs per CCX, and on systems with a single, unified L3 cache it corresponds to the total number of available cores. Setting max-threads-per-group provides fine-grained control. A higher number of threads in a group can introduce contention, while a lower number can increase the number of sockets required. Internal testing identified 16, the default, as the best overall tradeoff across the majority of systems.  

Before adjusting these defaults, it is recommended to evaluate the  system’s CPU topology, NUMA characteristics and NIC configurations. The performance tuning guide provides a step-by-step reference.

HTTP/2 performance

New global directives help mitigate HTTP/2 protocol attacks:

• tune.h2.fe.max-frames-at-once – Sets the maximum number of HTTP/2 incoming frames processed at once on a frontend connection. Typically, you can leave this at the default value.

• tune.h2.be.max-frames-at-once – Sets the maximum number of HTTP/2 incoming frames processed at once on a backend connection. Typically, you won't change this.

• tune.h2.fe.max-rst-at-once – Sets the maximum number of HTTP/2 incoming RST_STREAM frames processed at once on a frontend connection. A low value (1 to 10) is effective for sites that face frequent RST-based attacks. Note that very low values, such as 1, which are the most effective at erasing the impact of such attacks, might slightly increase the perceived latency on highly-interactive sites or gRPC services. 

• tune.h2.fe.max-total-streams – Sets the maximum number of HTTP/2 streams in total processed per incoming connection. Once the limit is reached, the connection will be recycled. This curbs the ability of misbehaving clients to flood connections. Values around 1000 are already very effective without observable impact for the user.

• tune.streams-elasticity – Defines a target percentage of streams per frontend connection relative to the maximum number of concurrent connections (maxconn) when all connections are established. As the number of concurrent connections grows, the number of per-connection concurrent streams is reduced, dynamically redistributing unallocated streams over existing connections. The result is that the service remains highly responsive at moderate loads and resists overload under extreme loads, while maintaining reasonable resource usage.

Additionally, the global tune.h2.fe.max-concurrent-streams directive, which sets the maximum number of HTTP/2 concurrent streams per incoming connection, now accepts two new arguments: rq-load and min. The rq-load argument dynamically adjusts concurrency based on the executing thread's run-queue load. The min argument sets a floor on the advertised concurrency level when using rq-load, even if this results in a higher load than the configured target.

Reusing idle server connections

The new global directive tune.idle-pool.shared enables sharing idle server connections across threads. Idle connection reuse is a valuable optimization in most deployments, and this directive provides explicit control over the behavior. Accepted values are on (share connections between threads in the same thread group), full (share across all threads), and off (disable sharing entirely, useful for debugging a connection reuse issue). This new directive deprecates tune.takeover-other-tg-connections, which was introduced in version 3.2 and served a similar purpose.

HATerm

The HAProxy GitHub repository now includes haterm, a lightweight HTTP server built on HAProxy. It’s intended for benchmarking and other exercises that require a simple, configurable HTTP server with options for customizing its internal configuration and behavior. 

It's the successor to the earlier httpterm utility, which was HTTP/1 only and lacked SSL support. This new utility supports H1/H2/H3 over QUIC, TCP and SSL, and benefits from HAProxy's scalability under extreme load. A complementary client, haload, is under active development and will be released soon to replace h1load.

Learn more in the HATerm documentation.

Security and TLS

JSON Web Tokens

This release adds new options for validating JSON Web Tokens (JWTs). HAProxy can now decrypt JWE tokens natively at the proxy layer, enabling inspection of encrypted JWT claims before routing or access decisions.

• The global directive jwt.decrypt_alg_list defines a colon-separated list of permitted algorithms in tokens decrypted by the jwt_decrypt_* converters. This enables you to reject tokens that use an unsupported algorithm for the alg parameter.

• The global directive jwt.decrypt_enc_list defines a colon-separated list of permitted encryption algorithms in tokens decrypted by the jwt_decrypt_* converters. This enables you to reject tokens that use an unsupported encryption algorithm for the enc parameter.

• The converter jwt_decrypt_cert performs asymmetric decryption with ECDH-ES with EC certificates. When provided a certificate, the converter returns the decrypted contents of the JWT input sample.

• The converter jwt_decrypt_secret, when provided with a base64-encoded secret, returns the decrypted contents of the JWT input sample.

• The converter jwt_decrypt_jwk, when provided with a JSON Web Key, returns the decrypted contents of the JWT input sample following the JSON Web Encryption format.

AES CBC converters

This release adds new converters relating to AES CBC encryption and decryption, supporting token manipulation, payload masking, and secure session handling natively in HAProxy.

• The aes_cbc_dec converter decrypts the raw byte input using the AES128-CBC, AES192-CBC, or AES256-CBC algorithm, depending on the bits parameter.

• The aes_cbc_enc converter encrypts the raw byte input using the AES128-CBC, AES192-CBC, or AES256-CBC algorithm, depending on the bits parameter.

Enhanced ACME features

HAProxy is an early adopter of a new way to validate domain ownership through the ACME protocol for TLS certificate issuance. The DNS-PERSIST-01 challenge works by publishing a TXT record in your DNS server that contains the CA name and ACME account ID to serve as proof of domain ownership and, subsequently, authorizes issuing a TLS certificate. Contrary to DNS-01, which requires periodic updates of the challenge in the DNS record, DNS-PERSIST-01 permits setting a persistent record, so is more suitable for DNS zones managed manually, where rotating a record at each renewal isn’t practical. Rollout of this new challenge type is ongoing at providers like Let's Encrypt with wider availability expected later this year.

Also in this release, the acme configuration section has a new directive, challenge-ready, that sets how HAProxy can determine if the TXT record of a DNS-01 challenge is ready. The available options are:

• dns instructs HAProxy to resolve the TXT record to ensure that it's ready. 

• cli instructs HAProxy to use an external tool to check DNS. 

• delay instructs HAProxy to add a delay period.

• none instructs HAProxy to proceed with validation immediately.

The defaults are sensible for most deployments, so this directive can usually be left unset. Two complementary directives tune the active modes: dns-delay sets the delay wait period under delay, and dns-timeout sets the maximum resolution time for the TXT record under dns.

The acme configuration section also introduces a profile directive that implements the ACME Profiles extension. An ACME profile indicates the type of certificate to request from the certificate authority; valid options are determined by the profiles offered by the CA. For example, Let's Encrypt offers several ACME profiles.

In addition, this release supports the inclusion of IP addresses in the Subject Alternative Name (SAN) field of ACME-issued certificates, configured via the ips argument on the load directive within a crt-store section.

HAProxy 3.4 further introduces support for ACME EAB (External Account Binding), which aims to protect ACME accounts against unauthorized access. You can configure EAB through the following directives:

• eab-key-id – Configure the path to the EAB key ID file. The credential is provided by the CA and must be placed at the specified path before starting HAProxy. It's used during account creation only.

• eab-mac-key – Configure the path to the EAB MAC key file. The credential is provided by the CA and must be placed at the specified path before starting HAProxy. It's used during account creation only.

• eab-mac-alg – Configure MAC algorithm used for EAB signing. The default is HS256. The EAB MAC key must be large enough to support the specified MAC algorithm. Not all CAs support algorithms other than HS256.

TLS dummy certificate

HAProxy can now generate a self-signed TLS certificate directly, which can be useful in testing and scenarios where certificates might become available only after HAProxy has started. The following arguments are available on the load directive within a crt-store section:

• generate-dummy – Sets a self-signed certificate and private key.

• keytype – Sets the type of key, either RSA or ECDSA.

• bits – Sets the number of bits to use for RSA certificate generation.

• curves – Sets the elliptic curve to use for ECDSA certificate generation.

TLS certificate compression

HAProxy now supports TLS certificate compression as defined by RFC 8879. The new global directive tune.ssl.certificate-compression governs the feature. The default value, auto, follows the configuration of the underlying TLS library, while a value of off disables compression entirely. Compressing certificates exchanged between clients and HAProxy reduces transferred bytes and can lead to latency improvements.

Decrypting TLS 

This release simplifies decrypting TLS during debug sessions by introducing variables that return the properties required to create a keylog file. Previously, you had to combine several variables into a log format string to produce the keylog output. Two new consolidated variables, HAPROXY_KEYLOG_FC_LOG_FMT and HAPROXY_KEYLOG_BC_LOG_FMT, can be referenced directly in a log format.

Reliability

HTTP/1 glitches

Two updates affect HTTP glitch detection:

• HAProxy 3.4 expands the glitch detector to include the HTTP/1 multiplexer. Previously, only HTTP/2 and QUIC were covered.

• When HAProxy is configured to terminate connections that have too many glitches, it will now try to gracefully close the connection upon reaching 75% of the configured threshold rather than waiting until the limit is reached. Frontend and backend thresholds are set with tune.h1.fe.glitches-threshold and tune.h1.be.glitches-threshold.

HAProxy 3.0 introduced the concept of glitches. The term refers to unusual HTTP messages that could cause problems in the infrastructure if handled. Glitches might signal a malfunctioning client or server, or in some cases it may indicate a protocol attack. Several of the recent HAProxy releases have steadily expanded the glitch detector: the fc_glitches and bc_glitches fetches return the number of glitchy requests and responses; glitch_cnt and glitch_rate stick table data types make it possible to track glitches over time; and global options can terminate connections that exceed a configured glitch threshold. Expanding this functionality to HTTP/1 rounds out this helpful feature.

Health check section

A new healthcheck section promotes defining reusable health-check directives. Directives declared in a healthcheck section are applied to a server via the healthcheck argument on the server line, as shown below:

Better random algorithm

The random load balancing algorithm, which became the default in version 3.3, replacing roundrobin, now provides improved traffic distribution. The algorithm selects two servers at random from the pool of available servers and chooses the least loaded server, with load measured by the concurrent connection count. 

When comparing servers with the same number of concurrent connections, HAProxy now also considers recent traffic history (HTTP requests per second). This produces a more even distribution across large backend pools where many servers sit at identical connection counts. HAProxy can then make a more informed choice when selecting a server.

Fetching the HTTP version

HAProxy 3.4 standardizes the retrieval of the HTTP protocol version associated with a request or response.

Identifying the HTTP version is non-trivial, as HTTP/1, HTTP/2, and HTTP/3 each indicate their versions differently. HAProxy provides several fetches for this purpose, such as req.ver, res.ver, capture.req.ver, and capture.res.ver, but coverage across protocol versions has been inconsistent. In this release, these fetches operate uniformly across all supported HTTP versions. Both req.ver and res.ver return the version as major.minor; the capture variants return HTTP/major.minor.

Prometheus local update metric for stick tables

The HAProxy Prometheus endpoint exposes stick table metrics whenever a stick table is declared in the configuration. HAProxy 3.4 adds a stick table metric named haproxy_sticktable_local_updates. This gauge reports the cumulative number of updates on the stick table, allowing you to monitor the rate of updates over time.

HTTP/2 error logs

While having comprehensive logging is essential, controlling the volume of logs is also important. A new global directive named tune.h2.log-errors defines the scope of error logging for HTTP/2 traffic, accepting values of stream, connection, or no error. The default, stream, is the most verbose. Having the ability to adjust this setting as needed lets you favor efficient resource use while preserving the option to increase verbosity when required.

Debugging

The global directive set-dumpable supports a new value, libs, which instructs HAProxy to embed a copy of the binaries and libraries required for debugging into the resulting core dump. This eliminates the need to locate these files on the filesystem after the fact and removes the risk that they don't match the core. You can then extract the embedded libraries by using the libs-from-core tool, which is published in the HAProxy GitHub repository.

Also, the show profiling HAProxy Runtime API command now provides finer-grained information about runtime memory consumption when invoked with the memory argument, thanks to the notion of execution context.

Observability with OpenTelemetry

The new OpenTelemetry filter allows HAProxy to generate spans (the individual units of work that make up a distributed trace) alongside logs and metrics, all in the standard OpenTelemetry format. This makes each request's journey through the load balancer directly consumable by any OTLP collector over gRPC, HTTP endpoints, or local files.

HAProxy's event subsystem provided the architectural groundwork for this integration, enabling fine-grained hooks into the load balancer's inner workings.

OpenTelemetry is the industry standard for distributed observability. By adopting it, HAProxy can now surface telemetry data in the same unified view as the rest of the stack, providing full visibility into the many steps a request undergoes as it traverses the infrastructure — without the need for custom integrations or proprietary SDKs.

Enabling the feature requires a new filter opentelemetry directive. The integration is controlled by two configuration files that define which HAProxy events are subscribed to and the endpoints to which telemetry data is forwarded.

Events can be enriched with key-value attributes, custom log messages, and ACL conditions to filter which events are captured. 

The OpenTelemetry client library is experimental and ships as a separate add-on via the haproxy-opentelemetry repository and must be compiled into HAProxy to be enabled. The GitHub repository has build instructions and documentation. Configuration tutorials are coming soon.

New fetch methods in this release are as follows:

New converters in this release are as follows:

HAProxy 3.4 deprecates these features:

• The compression-direction directive is deprecated.

• OpenTracing is deprecated in version 3.4 and will be removed in 3.5.

Breaking changes

HAProxy 3.4 has the following breaking changes:

• The Stats page won't display the HAProxy version, but it can be enabled by using stats show-version.

Conclusion

HAProxy 3.4 introduces a dynamic backend system that streamlines operation in modern architectures, smarter buffer allocation, measurable throughput gains, native JWT decryption and AES processing at the proxy layer, and native OpenTelemetry support — alongside operational improvements in health checking, attack resistance, and log management.

Ready to upgrade or make the move to HAProxy? Now’s the best time to get started. You can install HAProxy 3.4 in any of the following ways:

• Install the new HAProxy packages for Ubuntu, Debian, and RHEL.

• Run it as a Docker container. View the Docker installation instructions.

• Compile it from source. View the compilation instructions.