Built on HAProxy 3.4, this release creates and removes endpoint servers at runtime, keeping backend server pools aligned with changes in the Kubernetes cluster. It also supports more controlled configuration through custom resource definitions (CRDs) and helps shared controllers recover from rejected resources.

Read the full release notes for the complete list of changes.

HAProxy Enterprise Kubernetes Ingress Controller 3.4 is coming soon with exclusive enterprise features.

What is HAProxy Kubernetes Ingress Controller?

HAProxy Kubernetes Ingress Controller is a free, open-source product providing high-performance Kubernetes-native application routing for the Ingress API. It supports HTTP/S and TCP (via CRD), and is built on HAProxy's legendary performance, flexibility, and reliability. Additionally, it provides a low-risk migration path to Gateway API via the HAProxy Unified Gateway.

New in HAProxy Kubernetes Ingress Controller 3.4

Dynamic server management for Kubernetes

Kubernetes applications add or remove pods as demand changes; backend server pools need to follow those endpoints as applications grow or shrink.

Version 3.4 creates and deletes endpoint servers through the HAProxy Runtime API as pods appear or disappear. The controller also records those servers in its generated configuration, keeping the file aligned with runtime changes.

Endpoint management becomes part of your application's existing scaling workflow. Backend server pools grow and shrink with Kubernetes endpoints, without operators preallocating server slots.

The HAProxy Runtime API documentation explains runtime server creation. These operations manage servers within existing backends.

Customization with structured configuration

Custom resources give teams a structured way to configure application traffic, while resource-level error handling helps keep valid changes moving when a resource is rejected.

Build on custom resources and user-defined annotations

Previously, version 3.2 introduced user-defined annotations and Frontend custom resources; version 3.4 continues that configuration direction by removing raw config snippets.

Use supported custom resources or validated user-defined annotations for customization. For example, a Backend custom resource can hold supported backend settings alongside the Kubernetes resources that use them.

User-defined annotations let administrators define configuration templates and validation rules for application teams. This capability already exists and predates version 3.4.

The benefit is a more controlled way to expose supported HAProxy settings. You can check each snippet's behavior against its replacement rather than assuming every raw directive has a direct equivalent.

Recover from invalid custom resources

A shared controller may serve applications owned by several teams. Resource-specific recovery helps each team manage its configuration while other valid updates continue.

The controller can now set aside the rejected resource and retry synchronization without it. Other valid changes can proceed while the resource owner corrects the problem. Editing the resource triggers another attempt automatically.

Logs identify the rejected resource, and a Prometheus gauge exposes its rejected generation:

haproxy_rejected_custom_resource_generation{kind,namespace,name}

This gives operators a resource-specific signal for alerting and troubleshooting. It's recovery from a failed configuration check, rather than a replacement for validation.

While a resource is set aside, its customization is not applied: depending on the resource, configuration can fall back to annotations or omit its listeners. We recommend reviewing the rejection before assuming that the resource's intended policy is in effect.

Built on HAProxy 3.4

HAProxy Kubernetes Ingress Controller 3.4 uses the HAProxy 3.4 core and its default random algorithm, based on Power of Two Random Choices. It selects two servers at random and chooses the less-loaded one, an approach that has demonstrated better performance and fairer load distribution across uneven servers.

Existing policies configured through a Backend custom resource or the load-balance annotation remain unchanged. If you relied on the implicit round-robin default, configure roundrobin explicitly in a Backend custom resource before upgrading.

The load-balance annotation remains functional in version 3.4, but is deprecated and will be removed in version 3.6.

Scale centralized operations with HAProxy One

HAProxy Kubernetes Ingress Controller serves the free, in-cluster use case. Enterprises that need centralized control and application security across a larger deployment have a separate path through HAProxy One.

Coming with HAProxy Fusion 2.1, enterprises will be able to centrally manage Ingress and Gateway API resources using HAProxy Enterprise as the data plane. In that model, HAProxy Fusion reads those Kubernetes resources and configures a managed HAProxy Enterprise fleet from a central control plane.

• HAProxy Enterprise adds an integrated web application firewall (WAF), bot management, and global rate limiting.

• HAProxy Fusion provides fleet-wide load balancer management and observability. Together, HAProxy Fusion and HAProxy Enterprise support external load balancing for Kubernetes and multi-cluster routing.

• HAProxy Edge supplies the platform's secure edge network. 

This enterprise operating model combines Kubernetes routing with centralized security and management across your deployment.

Deprecations and breaking changes

Deprecated: Configuration annotations

Annotations superseded by custom resources are deprecated but remain functional in version 3.4—emitting deprecation notices. Their removal is planned for version 3.6.

Where a supported replacement exists, move the setting into the corresponding custom resource. Check the documented replacement for each setting; some annotations don't yet have a direct equivalent.

Deprecated: SSL passthrough

The ssl-passthrough annotation is deprecated but still functional in version 3.4. Its removal is planned for version 3.6. Check the supported migration procedure before changing workloads that depend on it.

Breaking change: Config snippets

Config snippets are removed in version 3.4. This breaking change affects global-config-snippet, frontend-config-snippet, stats-config-snippet, and backend-config-snippet, and we've also removed the --disable-config-snippets startup argument.

Migrate each supported setting to a custom resource or validated user-defined annotation, then check the generated configuration before upgrading.

Breaking change: Default load balancing algorithm

Version 3.4 inherits HAProxy's random default when no balancing policy is explicitly configured. Existing Backend custom resource settings and load-balance annotations remain effective. To retain the previous round-robin default, configure roundrobin explicitly in a Backend custom resource before upgrading.

Breaking change: Server-slot annotations

The server-slots, scale-server-slots, and servers-increment annotations are ignored in version 3.4 and produce warnings. Although the warnings describe deprecation, their behavior has already changed: these settings no longer control server allocation.

We consider this a breaking change for deployment automations that rely on slot sizing. Dynamic server management follows application endpoints instead.

Breaking change: Backend server-switching rules

The Backend custom resource no longer accepts server_switching_rule_list in version 3.4. This is a breaking change. We suggest reviewing and adapting configurations that currently use these rules to target individual servers before upgrading.

Breaking change: Experimental Gateway API integration

Version 3.4 removes the controller's experimental Gateway API integration. This is a breaking change for deployments using that integration.

Users who require Gateway API can migrate to HAProxy Unified Gateway, a separate open-source controller that supports both Gateway API and Ingress. Since version 1.0, HAProxy Unified Gateway has been out of beta and ready for production workloads. See the announcement of HAProxy Unified Gateway 1.1 for the latest features.

Review resource compatibility and deployment requirements before redirecting traffic. The Ingress controller continues to support Ingress routing and TCP through its own custom resources.

Try HAProxy Kubernetes Ingress Controller

Review the breaking changes and deprecations before upgrading to version 3.4, particularly if your deployment uses config snippets or experimental Gateway API support:

• Existing installations: follow the community upgrade instructions. Helm updates CRDs during upgrade; kubectl installations require the documented CRD update procedure.

• New installations: choose Helm or kubectl, or follow the installation guide for your environment.

The Helm chart version and controller version are separate. Check the chart's appVersion and any image-tag override to confirm that you're deploying the intended version 3.4 release.

Test migrated configuration before directing production traffic to the updated controller. The configuration reference describes all supported settings and custom resources.

Next steps

We welcome feedback and contributions through the community project on GitHub. Tell us how dynamic server management works in your deployment, or report configuration cases that need attention.

Thank you to everyone who contributes code and helps test the controller.

This release delivers a milestone in the migration path we introduced with the public beta and the version 1.0 release. You can simultaneously serve supported Ingress resources and adopt Gateway API, without converting Ingress rules into Gateway API manifests. Backend custom resources let you configure the traffic policies your applications need.

Version 1.1 also adds Gateway API TCPRoute support for port-based routing of TCP services. Gateway API ListenerSet enables shared-Gateway delegation, Gateway API 1.7.0 is supported at launch, and this release reduces the container image size by 40%.

HAProxy Unified Gateway remains the free, in-cluster option. For organizations that need centralized management and enterprise-grade security, HAProxy One provides a separate operating model.

What is HAProxy Unified Gateway?

HAProxy Unified Gateway is a free, open-source project maintained by HAProxy Technologies that enables Kubernetes-native traffic management using the Gateway API specification.

Organizations are moving more workloads to Kubernetes, which requires routing methods that handle diverse applications and organizational complexity. The Gateway API standard provides a solution through role-based access control (RBAC), enabling a clear separation of concerns among infrastructure providers, cluster operators, and application developers.

HAProxy Unified Gateway provides flexible protocol support, RBAC, and integrated Ingress support. It brings exceptional performance and efficiency to Kubernetes traffic management because it's built on HAProxy, the world's fastest software load balancer. By adopting HAProxy Unified Gateway, teams can scale reliably across any Kubernetes infrastructure.

New in HAProxy Unified Gateway 1.1

Gradual path from Ingress to Gateway API

Version 1.1 lets you adopt Gateway API alongside supported Ingress workloads, with Kubernetes-native controls for routing and backend configuration.

Serve both Kubernetes objects with one controller

HAProxy Unified Gateway 1.1 adds Ingress and IngressClass support alongside Gateway API resources. You can keep supported Ingress rules in use while introducing Gateway API resources for new or migrated applications.

Internally, the controller translates Ingress resources into virtual Gateway and HTTPRoute representations; these exist in memory, rather than as additional objects in the Kubernetes API. Application teams continue working with their Ingress resources until they choose to migrate those rules.

Teams planning their next step after the Ingress NGINX retirement can introduce Gateway API alongside supported Ingress workloads.

Bring existing Ingress workloads forward

Ingress support includes exact and prefix path matching, with host-based routing for multiple domains and wildcard hosts. TLS termination uses the certificates declared in your Ingress resources.

Backend custom resources let you define load balancing policies and health checks alongside your applications. This gives you a Kubernetes-native way to configure traffic handling while retaining supported Ingress rules. The process is as follows:

1. Enable Ingress support through --enable-ingress. 

2. Configure IngressClass matching and RBAC for the resources managed by the controller. 

3. Expose the dedicated Ingress ports, which default to 8080 for HTTP and 8443 for HTTPS. 

4. Direct incoming traffic from the previous controller to HAProxy Unified Gateway. 

Our documentation covers supported configuration and deployment requirements.

Route TCP services with Gateway API

HAProxy Unified Gateway 1.1 adds TCPRoute support, bringing port-based TCP routing into the Gateway API configuration model. A TCPRoute attaches to a TCP listener on a Gateway and forwards connections to backend Services.

Weighted backend references distribute new connections between Services, so you can gradually shift traffic as you roll out a new backend. Service-level Backend custom resources let you tune timeouts and load balancing policies while managing TCP and HTTP routing through Kubernetes.

Try the TCPRoute configuration examples for basic forwarding and weighted backend distribution.

Share a Gateway with ListenerSet

A shared Gateway can become a coordination problem when every listener change requires the platform team to edit the same object.

Gateway API ListenerSet support lets application teams contribute listeners without taking ownership of the Gateway. The Gateway owner controls admission through allowedListeners, preserving the platform's authority over what can attach.

For example, a platform team can own a shared Gateway while an application team defines the listeners needed for its service. The application team's routes attach to its ListenerSet. Changes stay with the team responsible for the application, within the Gateway owner's admission policy.

This extends the Gateway API's separation of responsibilities to listener management; platform engineers can delegate routine changes rather than handling each one themselves.

Built on the latest core technology

Updated Gateway API support broadens routing options, while the newer HAProxy core brings improvements in performance and reliability.

Gateway API specification and HTTP routing

HAProxy Unified Gateway 1.1 supports Gateway API specifications from 1.6 onwards, with 1.7.0 support included at launch. Match your routing resources to the features documented for the controller.

HAProxy Unified Gateway 1.1 passes all Gateway API Core conformance tests for HTTP, TCP, and TLS. For practical routing examples, see the HTTPRoute documentation.

HAProxy Unified Gateway 1.1 expands HTTPRoute support with more request-matching options and filters, giving you greater control through standard Gateway API resources.

A newer HAProxy core

Version 1.1 upgrades the HAProxy core from 3.2 to 3.4. This brings improvements in performance and reliability, with greater configuration flexibility for Kubernetes traffic management.

Read the HAProxy 3.4 release announcement for the underlying changes.

Scale centralized operations with HAProxy One

HAProxy Unified Gateway serves the free, in-cluster use case. Enterprises that need centralized control and application security across a larger deployment have a separate path through HAProxy One.

Coming with HAProxy Fusion 2.1, enterprises will be able to centrally manage Ingress and Gateway API resources using HAProxy Enterprise as the data plane. In that model, HAProxy Fusion reads those Kubernetes resources and configures a managed HAProxy Enterprise fleet from a central control plane.

• HAProxy Enterprise adds an integrated web application firewall (WAF), bot management, and global rate limiting.

• HAProxy Fusion provides fleet-wide load balancer management and observability. Together, HAProxy Fusion and HAProxy Enterprise support external load balancing for Kubernetes and multi-cluster routing.

• HAProxy Edge supplies the platform's secure edge network. 

This enterprise operating model combines Kubernetes routing with centralized security and management across your deployment.

Try HAProxy Unified Gateway

Choose the installation method that fits your environment:

• Docker: Get the HAProxy Unified Gateway image and select the release version you intend to deploy.

• Helm: Use the official Helm chart for Kubernetes deployment.

We highly recommend starting with our installation documentation. Gateway API Custom Resource Definitions (CRDs) are required even when serving Ingress resources.

The Helm chart version and application version are separate: check the chart's appVersion and any image.tag override before upgrading.

Next steps

Start with a supported Ingress workload, or define a new Gateway API route for HTTP or TCP traffic. Then, check the result in your environment before moving more traffic.

We welcome feedback and contributions through the community project on GitHub.

Two big things happened for me in the last two months. First, in September, we deployed our own internal AI platform at HAProxy Technologies, running an HAProxy-based AI gateway, deploying Kubernetes-based hosted chatbots for every single company employee, and a local sandbox for developers.

Right after that, in October, a lot of new models were released, including Kimi K3.1 Pro and others. Some of these models are clearly less protected against cyber research than others, and the security community, both the good guys and the bad guys, took notice.

CVE explosion in the last 12 months

Check out this chart comparing the number of CVEs published per month; we're looking at a more than 4x increase compared to last year.

We've also seen some high-profile attacks. The one most emblematic of this new reality was the attack on Binance, the crypto platform.

Back in June, an engineer at Binance searched for an AI coding tool and installed a trojanised Homebrew package from a poisoned result. Binance caught it, swapped the laptop and rotated credentials — but the attacker had already learned who worked on the wallet team. In September, a second engineer sat two fake interviews on a legitimate job platform and was handed a coding 'assignment' that executed on setup. The malware was a 0-day that endpoint protection missed. In October, the attacker used that machine, and one of Binance's own internal AI tools, to pivot onto two more engineers and pick up a deployment token.

From there, everything moved quickly: the actual attack was executed within minutes, with total damage of over $6 billion.

We've seen similar situations at other companies, with many different scenarios playing out:

• CVEs are coming faster than we can patch them.

• Attackers used to take weeks or months to explore breached networks; AI agents do it in minutes.

• Supply chain attacks are still on the rise, effectively punching holes through firewalls and VPNs.

Security in layers

HAProxy has been talking about security in layers for a long time. We usually talk about the L4/L7 layers, but this goes deeper. It is imperative that you:

• Patch systems as quickly as you can.

• Deploy MDM on all company assets.

• Deploy proper L4 firewalls.

• Run an L7 web application firewall, with brute-force and scanner detection with it.

Customers often say, "Our apps are internal; we don't need this stuff." My message for them right now is: as of this moment, all apps are external, whether we like it or not. No matter the use case, network, or scope, all apps are at risk and can often serve as springboards for further internal attacks.

BTW, EU DORA + NIS2 require proportionate, risk-based controls... and in practice, a WAF is the easiest way to implement them.

Internal isn't a boundary anymore

With that in mind, here is what I did on our internal AI infrastructure and internal apps:

• We deployed our multi-layered securityin learning mode last week

• Tuned all rules and false positives

• And will now be deploying in enforcement mode

Here is what our Security Profile looks like in HAProxy Fusion Control Plane. If it looks like the profile for external applications, that's the point:

Your setup probably doesn't look like this. Most internal apps don't have a WAF in front of them at all, let alone a profile that drops anything from outside a private address space.

The gap is the assumption that internal means safe, and that assumption is no longer reasonable.

If you want to close it, don't start with everything. Pick one internal app, put a profile in learn mode in front of it, and read the logs for a week. You'll get false positives, tune them, and then enforce.

Let me know if you need help spinning up the same thing in your own infrastructure!

UDP load balancing becomes programmable, and whole backends can be published dynamically through the HAProxy Runtime API or the HAProxy Data Plane API. The HAProxy Enterprise WAF gains configurable inspection limits that tune efficiency under heavy load, with the inspection verdict unchanged, and bot management gains self-hosted CAPTCHA options with a local audit trail.

This release builds on the industry-leading flexibility, performance, security, and resilience that HAProxy Enterprise is known for. All of it runs in line, on customer infrastructure, and inside the perimeter. No traffic leaves for a third-party scrubbing network, and the same configuration language and APIs drive every capability.

HAProxy Enterprise load balancer provides high-performance load balancing for TCP, UDP, QUIC, and HTTP-based applications, high availability, an API/AI gateway, Kubernetes application routing, SSL processing, DDoS protection, bot management, global rate limiting, and the HAProxy Enterprise WAF.

HAProxy Enterprise combines the performance, reliability, and flexibility of our open-source core (HAProxy, the most widely used software load balancer) with ultra-low-latency security layers and world-class support. HAProxy Enterprise benefits from full-lifecycle management, monitoring, and automation (provided by HAProxy Fusion), and security layers powered by threat intelligence from HAProxy Edge and enhanced by machine learning.

Together, this flexible data plane, scalable control plane, and secure edge network form HAProxy One: the world's fastest application delivery and security platform that is the G2 category leader in Load Balancing, API Management, Container Networking, DDoS Protection, and Web Application Firewall (WAF).

To learn more, contact our sales team for a demonstration or request a free trial.

New in HAProxy Enterprise 3.4

Ready to upgrade?

When you are ready to start the upgrade procedure, go to the upgrade instructions for HAProxy Enterprise.

Flexibility

UDP services like DNS, RADIUS, NTP, and syslog sit underneath everything else. A reachability check cannot flag when one of these services hangs while the host stays up. Catching it takes checks and rules that understand the protocol.

The goal was to bring UDP services up to parity with TCP and HTTP services in traffic control and health awareness.

HAProxy Enterprise 3.4 makes UDP load balancing programmable. New udp-request content rules act on each datagram: filter traffic, select a server, set variables, track, and rate-limit. A new track keyword adds stick-table counters for UDP and cross-protocol server-status tracking. Protocol-aware UDP health checks confirm DNS, RADIUS, NTP, and syslog services are answering.

Silent UDP failures become detected failures, and traffic moves to healthy servers. Per-datagram rate limiting helps limit targeted UDP abuse at the load balancer, without a separate appliance or application-level workaround. 

To get started, see the UDP load balancing documentation.

This example balances DNS over UDP, applies per-datagram rules, rate-limits connections, and builds a smart health check that validates the remote applications and lets HAProxy Enterprise mark each server as up or down.

The udp-check send-binary directive sends a full DNS query instead of an empty probe. The 32-byte payload is a standard 32-byte A-record lookup encoded in hexadecimal.

DNS header (12 bytes)

DNS question section (20 bytes)

As shown in the "DNS header" table above, udp-check expect rbinary 0002 matches the response payload against the transaction ID. DNS servers echo that ID at the start of the response header, so a match confirms the server received, processed, and replied to this specific health check query.

Meanwhile, udp-request track-sc0 src adds the client source address to the stick table, and stores the number of times a connection request was received from the client over a five-second window.

The udp-request reject line drops datagrams from 10.20.120.0/24 and 10.20.130.0/24 once a client exceeds ten connections in five seconds.

This example uses DNS, but the same pattern applies to other UDP protocols.

Dynamic backends at runtime

For platforms that update services constantly, i.e. add and remove backends, every change used to require a configuration update. We wanted to remove this operational friction that particularly affects enterprises with multi-tenant platforms, per-customer backends, and CI-driven environments.

HAProxy Enterprise 3.4 creates, updates, and deletes whole backends at runtime, with no reload. It covers full backends, including mode tcp, driven through the HAProxy Runtime API or HAProxy Data Plane API. This capability comes from the open-source HAProxy 3.4 release and is fully available in HAProxy Enterprise 3.4.

High-churn platforms can now publish and unpublish backends dynamically using the same APIs and Infrastructure as Code (IaC) tooling they already use to automate HAProxy Enterprise, including CI/CD pipelines. This cuts operational overhead and shortens the time needed to bring a new tenant or environment online.

Refresh certificates from a remote store

The crt-store section can now fetch and refresh certificate material from a remote source. In this release, it covers JWE key material as well as certificates; more may be added in future versions.

Key material for JWT and bearer-token validation rotates on the issuer's schedule rather than the user's. Remote refresh removes the operational burden of rotation and reduces the risk of an expired or stale key reaching production.

Security

The next-generation HAProxy Enterprise WAF, powered by the Intelligent WAF Engine, provides exceptional balanced accuracy of 99.65% and ultra-low latency with 100% local processing. Advanced threat detection powered by threat intelligence from HAProxy Edge, enhanced by machine learning, virtually eliminates false negatives and false positives with almost zero performance impact on legitimate traffic.

HAProxy Enterprise 3.4 builds on this market-leading foundation with improved performance efficiency under heavy load. Inspection limits and tuning options allow enterprises to optimize WAF performance and resource consumption, even under conditions that stress the processing and log-writing capabilities of a typical WAF. All of this is possible without affecting the inspection verdict.

HAProxy Enterprise 3.4 makes the inspection limits of the Intelligent WAF Engine configurable. Users set them globally, per WAF profile, or inline on a single rule. The limits bound four things: how many arguments a request carries, how long an argument name may be, how much content is inspected, and how many JSON arguments are read.

Those limits bound what one request can do. They can:

• Stop processing once a request reaches its match budget

• Stop capturing matches past a threshold, while still counting them

• Cap the log lines a single request can produce

Inspection depth no longer has to be set by the strictest application, so a low-risk static site and a high-risk API can be tuned differently on the same instance. Users can also choose which built-in rules write log lines, and request normalization is more thorough before matching.

Configuration example: setting WAF inspection limits for the Intelligent WAF Engine

This example tunes inspection for two applications, a strict profile for an API and a lighter one for a static site. It sets the three caps first, then the per-application limits. 

This configuration is for performance tuning only; users do not need to configure WAF detection rules when using the non-signature-based detection of the Intelligent WAF Engine.

Optimized buffer size for payload inspection

HAProxy 3.4 introduced a large-buffer pool in the open-source core. HAProxy Enterprise 3.4 extends it to the Enterprise modules, such as the HAProxy Enterprise WAF and Bot Management Module. The modules select the optimal buffer size automatically, so the size does not have to be raised globally for every request. Memory use tracks the workload rather than the largest possible request. Body limits stay tunable per WAF profile, so each application gets the inspection depth it needs.

XML request body inspection (experimental)

HAProxy Enterprise 3.4 adds experimental XML request body inspection to the HAProxy Enterprise WAF. The WAF parses XML request bodies as a stream, item by item, and applies rules for problems specific to XML. APIs that accept XML are inspected directly.

The feature ships as experimental in 3.4 and is turned off by default.

Compact WAF logs, separate destinations

The HAProxy Enterprise WAF now supports the CBOR log format. CBOR logs are compact, faster to process, and resilient to format changes.

WAF logs can also go to a different destination from HAProxy Enterprise traffic logs. Security teams typically route WAF logs to a SIEM or SOAR platform, and to a log archive that satisfies their retention and audit obligations. Separate destinations let each stream follow its own retention rules, access controls, and budget. For the basics, see an introduction to HAProxy logging.

The native CAPTCHA Module has shipped since HAProxy Enterprise 3.0. It supports Google reCAPTCHA v2 and v3, reCAPTCHA Enterprise, hCaptcha, Friendly Captcha, Turnstile, and custom providers. HAProxy Enterprise 3.3 added token-based callback verification, multiple CAPTCHA configurations per resource, and custom challenge HTML.

Every one of those providers verifies the challenge through an external or third-party service. For enterprises in regulated, air-gapped, or data-sovereignty environments, the challenge means a data-flow review before a CAPTCHA can go live.

We wanted to give those enterprises a CAPTCHA challenge that works inside their own perimeter.

HAProxy Enterprise 3.4 adds native support for self-hosted CAPTCHA options to the CAPTCHA Module: Altcha and Cap. Both are open-source projects. The user runs the challenge and verification endpoints, so no third-party CAPTCHA service sits in the request path. Neither option needs a site key or a secret key from a vendor account, giving enterprises native options that require no third party at all, alongside a full roster of external providers.

This extends the on-premises approach of our bot management solution. Detection and challenge both run on customer infrastructure, and HAProxy Technologies never receives customer traffic or user data.

Resilience

Broader GSLB coverage

HAProxy Enterprise Global Server Load Balancing (GSLB) keeps services available across sites and supports disaster recovery. Real deployments need DNS records beyond basic addresses for domain verification, certificate authority policy, telephony, and reverse lookups. Without them, users ran a second DNS system alongside GSLB.

HAProxy Enterprise 3.4 adds TXT, CAA, NAPTR, RDATA, and PTR record types to HAProxy Enterprise GSLB. A new cold-check verification mode also validates GSLB configuration syntax before changes are applied, preventing reload failures when multiple administrators make concurrent updates.

DNS-based global load balancing now resides in a single stack, reducing implementation costs. Traffic across sites follows current health, not an out-of-date verdict.

High-availability state in JSON

HAProxy Enterprise 3.4 adds a JSON option for VRRP status. Automation can now read the high-availability state directly rather than parsing text output. Runbooks that react to failover become more robust, and failover monitoring is easier to maintain. 

Management and observability

HAProxy Enterprise 3.4 adds native OpenTelemetry support, emitting OTel traces, logs, and metrics from the data plane. It replaces the OpenTracing support in previous versions of HAProxy Enterprise. This enables users to easily integrate HAProxy Enterprise telemetry with an existing observability stack.

Compliance and administration

FIPS-ready builds

In US federal, defense, and regulated finance, FIPS (Federal Information Processing Standards) is often a requirement for critical infrastructure products such as HAProxy Enterprise. We wanted to make procurement as simple as possible without compromising the high performance achieved by adopting AWS-LC as the default TLS library back in HAProxy Enterprise 3.2.

HAProxy Enterprise 3.4 offers FIPS-ready builds, using AWS-LC in FIPS mode. FIPS mode is a compliance-grade mode of the crypto engine customers already run, with no separate hardware appliance and no different product SKU.

External authentication on OVA images

Users deploying HAProxy Enterprise from OVA images used to install external-authentication packages after deployment. On an appliance-style image in a locked-down network, even fetching packages can be a change request.

HAProxy Enterprise 3.4 OVA images ship with external authentication pre-installed. RADIUS, LDAP/LDAPS, Active Directory, ADFS, Kerberos, OIDC/OAuth2, and SAML are available for management-plane authentication. Management access binds to a corporate identity provider from the first boot.

Building on the HAProxy One platform

HAProxy Enterprise 3.4 continues the steady evolution of the HAProxy One platform. HAProxy Enterprise 3.2 brought the Threat Detection Engine to the Bot Management Module, with behavioral detection running on customer infrastructure, including air-gapped environments. HAProxy Enterprise 3.3 unified the HAProxy Enterprise WAF into a single multi-engine design. HAProxy Enterprise 3.4 makes those capabilities easier to operate in production.

A load balancer, a WAF, bot management, CAPTCHA, global server load balancing, and programmable UDP all run in one data plane that runs entirely on customer infrastructure. They share one configuration language and one support relationship. HAProxy Fusion adds fleet-scale management, automation, and observability on top of all these capabilities.

Deprecations and breaking changes

OWASP CRS v3

OWASP has declared that Core Rule Set (CRS) v3 has reached end-of-life. As a result, the HAProxy Enterprise WAF in 3.4 supports CRS v4 only when running in the optional CRS compatibility mode. This does not affect the default mode, which uses only the Intelligent WAF Engine. 

Users still running CRS v3 must migrate to CRS v4 (requires customer portal access). This migration procedure can be performed before or after upgrading to HAProxy Enterprise 3.4.

Legacy ModSecurity WAF module

The legacy ModSecurity WAF module is deprecated in HAProxy Enterprise 3.4. It is still included, and configurations that load it continue to work in 3.4. It will be removed in version 3.5.

The HAProxy Enterprise WAF is now the integration path. It runs in Intelligent WAF Engine mode, CRS compatibility mode, or both at once during a transition, so migration can be gradual. Plan the migration before the removal release. Migration guidance will be published in the HAProxy Enterprise documentation.

Per-module body directives

Per-module body directives are replaced by the WAF's large-buffer directives. The older directive remains functional in 3.4, and the new directives simplify configuration.

Upgrade to HAProxy Enterprise 3.4

When you are ready to upgrade, follow the links below:

Try HAProxy Enterprise

The world's leading platforms and cloud providers trust HAProxy Technologies to simplify, scale, and secure modern applications, APIs, and AI services in any environment. HAProxy Enterprise 3.4 gives enterprises more control over security, UDP traffic, and runtime changes, all within the HAProxy One platform.

There has never been a better time to start using HAProxy Enterprise. To explore the changes in HAProxy Enterprise 3.4 in greater detail, don't forget to join our upcoming HAProxy Enterprise 3.4 webinar. Ready to jump in? Request a free trial of HAProxy Enterprise and see it for yourself.

HAProxy Community and HAProxy Enterprise are not affected. 

No action is required on any version of HAProxy itself. It does not use or support Brotli; the only algorithms it supports (gzip, deflate, raw-deflate, and identity) come from a separate compression library with no Brotli code, and there is no Brotli decoder in HAProxy.

What is HTTP2Shell?

HTTP2Shell (CVE-2026-111497) is an out-of-bounds write in the Google Brotli decoder, affecting versions 1.0.3 through 1.2.0 across all platforms. It carries a CVSS v4.0 score of 9.2 and is classified as CWE-787.

The flaw sits in the decoder's block-switch routine. It returns a plain boolean that conflates two different outcomes: "this stream is malformed" and "I need more input." The fast path discards the return value entirely. A crafted Brotli stream can exploit that confusion to write past the end of a working buffer. From there, an attacker can corrupt memory, leak data, crash the process, or run arbitrary code.

The bug lives in the shared Brotli library, so every runtime that bundles it inherits the flaw. The disclosure rolled out in waves:

• October 21 — Node.js

• October 22 — Python (Brotli and brotlicffi)

• October 23 — Envoy, Istio, Bun, and libbrotli

• October 24 — Java (brotli4j) and Amazon Linux

• October 25 — .NET

• October 26 — Debian and Alpine; Fedora and RHEL partially; Ubuntu and SUSE still pending

The attack works in both directions. A malicious client can attack a server that decodes a Brotli request body, and a malicious server can attack a client that decodes a Brotli response. So "just update one thing" doesn't work here, because the flaw sits in every HTTP stack that handles Brotli.

There is one detail to keep in mind: the vulnerability is in decompression, not compression. Software that only compresses with Brotli is not affected. Apache's mod_brotli is unaffected for exactly this reason, since it compresses responses and never decodes them. 

If you need the details, the CVE record and the OpenCVE entry are good starting points. For per-runtime guidance, see the Node.js write-up, the Python advisory (GHSA-9v8h-qqgm-4m35), and the upstream fix commit. The fix is Brotli 1.2.1, or a patched 1.0.10 or 1.1.1.

Protecting your applications

HAProxy sits in front of the affected applications. That position lets you block the inbound attack vector while you patch.

Add this to the frontend in front of the affected backends:

• req.hdr(Content-Encoding) reads the request's Content-Encoding header, which states how the body is compressed. This is the inbound vector.

• -m str -i br dcb matches either br or dcb as a whole token, ignoring case. HAProxy splits a comma-delimited header value into tokens first, so br, gzip, br, br, gzip, and deflate, br, gzip all match, while hybrid and zebra do not.

• http-request deny status 415 rejects the request at the edge, before it reaches a backend that would decode it. The 415 status tells the client the body's encoding isn't accepted here. Use status, not deny_status because deny_status implies a built-in error file, and HAProxy has none for 415, so the configuration would fail to load.

This checks Content-Encoding rather than Accept-Encoding, because they do different jobs. Accept-Encoding says what a client can accept in a response, and every modern browser sends br there. Matching on it would reject normal traffic. Content-Encoding describes the body you're actually receiving, which is what you want to inspect.

This works the same way on HAProxy Community and HAProxy Enterprise.

Scope it to the backends that need it, and remove it once they're patched. This rule is for one situation: a backend is known to be vulnerable, and you can't patch it yet. Apply it only to those backends, not to your whole frontend. Leaving it in place blocks legitimate Brotli request bodies, so if any of your clients send them, the rule will reject them.

Three more things to know:

• It only covers inbound request bodies. If a backend fetches and decodes Brotli responses from a third party, that path stays open, and you have to fix it in the client.

• It matches br and dcb only. If another content coding turns out to be Brotli-based, add its token to the end of the rule.

• It's a stopgap. Patch the backends.

When the next library CVE lands, the same move applies: enforce the policy at the edge, scoped to the affected backends, until the patch ships. That's HAProxy enforcing security policy at the edge.

HAProxy as a security component

HTTP2Shell is a good example of why the edge is the right place to enforce policy. You can't chase a flaw like this across every runtime in your fleet, but you can enforce one rule, once, in front of all of them.

The same discipline shapes HAProxy's security features. HAProxy Enterprise handles web application firewall, bot management, DDoS protection, rate limiting, and threat detection, with centralized management through HAProxy Fusion Control Plane.

A small attack surface is a security property. HAProxy isn't affected by HTTP2Shell because it doesn't carry the code, and that's the point.

To see what HAProxy can do for your security posture, explore our security solutions.

• For HAProxy Fusion 

  • Customers on version 2.x  should immediately update to 2.0.23

  • Customers on version 1.3.x should immediately update to 1.3.45-553.0

• If you run Data Plane API (CE or EE) with mutual TLS alongside an HTTP or UNIX socket listener, you should update now or disable the listeners as a workaround. 

• All other HAProxy products: Update HAProxy Enterprise, ALOHA, HAProxy Kubernetes Ingress Controller, HAProxy Unified Gateway, and Community Edition at the next reasonable opportunity. 

  • See the table below for more information about affected and fixed versions for each product.

• If you use image or marketplace versions of HAProxy, ensure you’re using the latest available version as of the publication date of this security bulletin.

1. CVE-2026-110351 and CVE-2026-110352: HAProxy Fusion privilege escalation and login token bypass

Severity: 9.9 Critical / 9.0 Critical (CVSS v3.1) · CWE-863 Incorrect Authorization, CWE-1023 Incomplete Comparison with Missing Factors

CVE-2026-110351 (role escalation): The user update API (PUT /controller/users/{id}) never checked role changes. Any user allowed to edit their own profile, such as one with the built-in read-only-plus-profile role, could give themselves the admin role and take control of Fusion and its managed nodes.

CVE-2026-110352 (login token claims): With ADFS/OIDC login using oic_indirect tokens, Fusion checked the token signature but not its expiry, start time or audience. An attacker holding a victim's token, even an expired one or one issued for another app, can sign in as that user.

Fixed in:

Recommended action: Update to 2.0.23, then check user roles for unexpected admin grants. Until you can update, remove roles with change_own_profile from users who don't need them, and switch off ADFS/OIDC login if you use oic_indirect tokens.

More detail: CVE-2026-110351 record · CVE-2026-110352 record

Our assessment

The scores reflect the practical risk. CVE-2026-110351 needs only a low-privileged account and one API request to reach full control. CVE-2026-110352 is harder to exploit, since the attacker must first obtain a token, and applies only to ADFS/OIDC setups, but the impact is the same. Treat this update as urgent. The Fusion Control Plane is only vulnerable depending on how access to it is handled on your network (e.g., behind your firewall).

2. CVE-2026-109575: Data Plane API authentication bypass with mutual TLS

Severity: 9.8 Critical (CVSS v3.1) · CWE-306 Missing Authentication for Critical Function · Reported by Yonghwa Lee

When mutual TLS is configured (tls_ca and tls_port), the Data Plane API turns off Basic authentication for all of its listeners, but checks client certificates only on HTTPS. Any HTTP or UNIX socket listener running at the same time accepts requests with no credentials, letting an attacker read or replace the HAProxy configuration.

Affects: Data Plane API 2.2.0 through 3.4.3 and the matching Enterprise releases, when mutual TLS runs alongside an HTTP or UNIX socket listener.

Fixed in:

Recommended action: Update to a fixed version. Until you can, turn off the HTTP and UNIX socket listeners, or block access to them.

More detail: Fix commit · Release notes · CVE record

Our assessment

The 9.8 score assumes the vulnerable configuration. You are exposed only if mutual TLS and an HTTP or UNIX socket listener are enabled together; HTTPS-only setups are safe. Where both conditions hold, the score is accurate: no credentials are needed, and the attacker can rewrite the load balancer configuration.

3. CVE-2026-110354 and CVE-2026-110353: HAProxy CPU exhaustion from malformed HTTP/1 and HTTP/2 requests

Severity: 7.5 High (CVSS v3.1) · CWE-835 Infinite Loop, CWE-252 Unchecked Return Value · Reported by Adam Crawford (CVE-2026-110354); found internally (CVE-2026-110353)

CVE-2026-110354 (HTTP/1 chunk-size line): A chunked request traps the parser in a loop. The thread stays at 100% CPU after the client leaves, and repeated requests can stall every thread until HAProxy restarts.

CVE-2026-110353 (HTTP/2 PING frame): A truncated PING frame is never consumed, so the HTTP/2 multiplexer spins until timeout http-request closes the connection. Many such connections keep CPU usage high.

Fixed in:

Recommended action: Update to the fixed build for your branch. For CVE-2026-110353, you can turn off HTTP/2 on exposed frontends or lower timeout http-request in the meantime. CVE-2026-110354 has no known workaround; restarting HAProxy frees a stuck thread.

More detail: HTTP/1 fix commit · HTTP/2 fix commit · CVE-2026-110354 record · CVE-2026-110353 record

Our assessment

Both issues affect availability only; neither exposes data. CVE-2026-110354 is more serious, since a few requests can stall the whole process until restart. CVE-2026-110353 is bound by timeout http-request. The 7.5 High score fits. Update at your next maintenance window, more urgent for internet-facing instances.

How to update

Users of affected products should update by pulling the latest image or package for their release track.

•  HAProxy Enterprise: see the upgrade instructions in the customer documentation.

• HAProxy Enterprise with HAProxy Fusion: upgrade your nodes from the Fusion control plane.

•  HAProxy Fusion: update the control plane to 2.0.23.

• HAProxy ALOHA: follow the standard firmware update procedure.

•  HAProxy Data Plane API: install the fixed Enterprise package, or download the Community Edition release from GitHub.

•  HAProxy Community Edition: update to the fixed tagged release, or compile from the latest source.

• HAProxy Enterprise Kubernetes Ingress Controller: update to the fixed tagged release.

• HAProxy Community Edition Kubernetes Ingress Controller: update to the fixed tagged release.

• HAProxy Unified Gateway for Kubernetes: update to the fixed tagged release.

Support

If you are an existing HAProxy customer with questions about these advisories or upgrade procedures, please consult our customer documentation or contact support.

HAProxy Technologies products (HAProxy One, HAProxy Enterprise, HAProxy Fusion, HAProxy Edge, and HAProxy ALOHA) are not impacted. However, HAProxy offers multiple options to protect against potential exploits targeting these PHP vulnerabilities:

• Option 1: HAProxy Enterprise WAF Updated Rules – Inspects incoming HTTP requests to block attack vectors targeting these PHP security issues without requiring changes to backend application code.

• Option 2: HAProxy Workaround Configuration – Uses HAProxy configuration syntax to block targeted attacks before traffic reaches PHP backends.

• Option 3: Use HAProxy Edge – Use HAProxy Edge to protect the origin network and servers. Fully managed application delivery and security services on our global network.

The disclosed critical PHP vulnerabilities (CVE-2026-109618 and CVE-2026-109619) impact various core PHP functions and runtime environments. Unauthenticated attackers could exploit these flaws to achieve remote code execution or cause severe system degradation, depending on the application environment.

RCE via OOM corruption, CVE-2026-109618 (GHSA-w8hw-w9fx-j79w): out-of-memory handling can interrupt PHP while internal request data is only partially initialized. Request cleanup may then treat the invalid data as valid.

RCE via stale global state, CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp): request-owned internal state can survive after its backing memory has been freed. A later request handled by the same worker may use that stale state before normal initialization resets it.

Affected versions

The vulnerabilities affect all PHP installations serving web traffic across common runtime environments, including PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, and LiteSpeed.

Patched releases, specifically PHP versions 8.5.12, 8.4.27, 8.3.36, and 8.2.35, address these security issues. For more detailed release notes and download links, please refer to the official PHP announcement.

Recommended actions

Customers using the HAProxy Enterprise WAF simply need to update their rules.

Option 1A: Update Intelligent WAF Engine rules

Update HAProxy Enterprise WAF to the latest Intelligent WAF Engine rules to enable immediate inspection and blocking of exploit attempts. Update instructions are covered in the customer documentation.

To confirm the integrity of the latest rules file, please use the shasum command to generate a SHA-1 hash and ensure it matches this output.

Update HAProxy Enterprise WAF to use a custom OWASP CRS rule file that protects against these vulnerabilties. Instructions for creating custom OWASP CRS rules are available in the customer documentation. They apply to both the HAProxy Enterprise WAF with OWASP CRS compatibility and the legacy HAProxy ModSecurity WAF. A sample rule that mitigates these CVEs was first published in the php2shell-CVE-2026-109618-CVE-2026-109619-PoC repository.

Recommendation: If this is the first time enabling a custom rule, we recommend running it in detection-only mode initially. This logs malicious requests without blocking them, so you can confirm the rule does affect legitimate traffic before switching to blocking mode.

HAProxy ALOHA customers can protect themselves against PHP2Shell by updating the security offloader service. Here is the list of updated security offloader images for each supported version:

• security-aloha18.0-1.0.12.img

• security-aloha17.5-1.0.17.img

• security-aloha16.5-1.0.26.img

For detailed instructions on updating these WAF rules, please view our WAF updates documentation.

Option 2: HAProxy workaround configuration

If updating WAF rules immediately is not feasible, implement a workaround configuration to the HAProxy frontend to filter suspicious requests before they reach the PHP backend:

• Payload padding: Attackers can pad the request payload to evade the ACL checks, whereas the WAF accounts for this evasion.

• Custom session settings: Administrators can change session.upload_progress.name. If the setting is changed, update the is_upload_progress ACL to match.

Option 3: Use HAProxy Edge

Use HAProxy Edge to protect the origin network and servers. HAProxy Edge is a secure global application delivery network and CDN in one. Fully managed application delivery and security services on our global network. Get global delivery, DDoS protection, bot management, WAF, high availability and acceleration on a fully managed network. For more information, see HAProxy Edge.

Protect yourself today

We strongly recommend upgrading PHP installations to the fixed releases as soon as they are made available by the PHP security team. For further security notices and release updates, visit the PHP 2026 news archive.

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