HAProxy Release History: LTS Branches, SSL, HTTP/2 and HTTP/3

HAProxy ships two feature branches a year. Even-numbered branches (3.0, 3.2, 3.4) are long term support (LTS) lines maintained for five years; odd-numbered branches (3.1, 3.3) are "stable" lines maintained for 12 to 18 months. As of 25 October 2026 the newest LTS is 3.4, released 3 June 2026 and supported until 2031-Q2.

Native SSL arrived in 1.5 (June 2014), HTTP/2 on the client side in 1.8 (November 2017), and QUIC with HTTP/3 in 2.6 (May 2022) as an experimental feature that 2.8 declared ready for production in May 2023. Dates and versions below come from haproxy.org, the project documentation, its git CHANGELOG and its mailing list. The one action to take today: run haproxy -v, read its "Status:" line and confirm you are on the newest release of a maintained branch.

Key takeaways

• HAProxy started as Willy Tarreau's project. The CHANGELOG records the "first write" on 26 November 2000, and 1.0 shipped on 16 December 2001. It is licensed under GPL 2 or later, with headers under LGPL 2.1.
• A version is a branch (3.2) plus a fix release number (3.2.26). Staying on the newest fix release of your branch is the most important habit, because fixes are backported into every maintained branch.
• Even branches are LTS and get five years. Odd branches get 12 to 18 months, on purpose, so they do not end up embedded in products.
• Maintained on 25 October 2026: 3.4 and 3.2 and 3.0 (LTS), 3.3 (stable, until 2027-Q1), and 2.8 and 2.6 (LTS in "critical fixes only" mode until 2028-Q2 and 2027-Q2). 3.1 went unmaintained in 2026-Q1 and 2.4 in 2026-Q2.
• The Runtime API (the "stats socket") is off by default. When you enable it, keep it on a UNIX socket with tight permissions. The documentation calls a TCP listener for it "dangerous".
• Distribution packages lag upstream fix releases and often carry backported patches, so a distro version string will not match upstream fix ranges. Debian 13 ships a 3.0.11-based package while upstream 3.0 is at 3.0.30.

How did HAProxy begin, and how do the project and HAProxy Technologies relate?

Willy Tarreau and the first versions

The project's git CHANGELOG ends, at the very bottom, with three short lines: a "first write" dated 26 November 2000, a "major rewrite" on 28 November, and a "first fully working release with complete FSMs and timeouts" on 29 November 2000. The management guide carries the notice "Copyright 2000-2015 Willy Tarreau", and the haproxy.org home page still asks would-be contributors to write to "willy at haproxy".

The branch table gives 1.0 a release date of 16 December 2001 and an end of life two weeks later. 1.1 followed on 10 March 2002 with health checks and cookie insertion. The 1.1.7 release on 12 April 2002 added uid, gid and chroot settings, so privilege dropping and a chroot jail have been part of the design for almost as long as the project has existed. The haproxy.org home page section on reliability is titled "keeping high-traffic sites online since 2002".

From one maintainer to a company-backed core team

The 1.5.0 announcement on 19 June 2014 thanked a list of sponsoring organisations, starting with "HAProxy Technologies (formerly Exceliance)". During 1.5 development the news page credits Exceliance engineers with major work, including the native SSL layer in 1.5-dev12 in September 2012. When 1.6.0 shipped in October 2015, its announcement said about two thirds of the more than 1,150 commits came from HAProxy Technologies and one third from the wider community.

That is still the model. The community project lives at haproxy.org (sources, branch table, bug pages, mailing list), with a GitHub mirror of the development branch for issues and CI. The starter guide describes the commercial versions from haproxy.com as packages "based on the latest stable versions", and the home page says each branch is maintained for five years by the same developers who write new features. This post covers the open source project only.

How do HAProxy branches, LTS and stable releases work?

The numbering rule

haproxy.org explains the scheme in a few sentences. The first digit "usually indicates a breaking change (config format etc) but in practice rarely changes". The second digit indicates new features. Together they form a branch, such as 3.2. A third number is the fix release: 3.2.26 is the 26th fix release of the 3.2 branch.

The starter guide adds a rule that matters for upgrades: "An existing feature may never be modified nor removed in a stable branch". Moving from 3.2.10 to 3.2.26 should never break a working configuration. Moving from 3.0 to 3.2 can, which is why branch moves need a test plan and fix releases mostly do not.

Even LTS branches and odd stable branches

The home page sets out the two kinds of branch:

• Even branches are LTS. They are "maintained for 5 years after their release" and are "aimed at general users who seek extreme stability".
• Odd branches are "stable". They are aimed at "highly skilled users who prefer to upgrade often" and can roll back if something breaks. They are maintained "between 12 and 18 months", and the page says the short, deliberately loose window exists partly so that "these versions do not end up in embedded products".

The starter guide words the odd branch rule more strongly: since 1.9, odd branches are "likely to trigger more bugs" and "must not be deployed where they cannot be rolled back in emergency". The 1.9.0 news entry called 1.9 "not suitable for inclusion in distros".

Two releases a year

The home page says that "since version 1.8, two major version are emitted every year". Since 2.6 the rhythm has been regular: the even LTS branch at the end of May or start of June, and the odd branch at the end of November or start of December (see the table below). The next branch, 3.5, is listed as "~2026-Q4" and was at 3.5-dev9 on 14 October 2026.

Each new release opens the next development branch on the same day. The CHANGELOG shows 3.5-dev0 dated 3 June 2026, the same date as 3.4.0.

What "critical fixes only" means

Older LTS branches pass through a final phase before they become unmaintained. On 25 October 2026 the branch table lists 2.6 and 2.8 as "critical fixes only", ending 2027-Q2 and 2028-Q2. Its timing is discussed on the mailing list; when 2.6.0 was announced, a contributor replied that it was "an appropriate time to put 2.0 into 'critical fixes' only". Such a branch still gets fixes for serious problems, but not every bug fix, so you should already be planning the move.

How backports work

The starter guide states that "all fixes that go into a stable branch necessarily come from the master branch", so no fix is lost after an upgrade. The contribution guide (CONTRIBUTING) makes this enforceable: every bug fix must carry a BUG tag, a severity, the affected subsystem, a user-visible impact explanation and an explicit statement of whether it needs backporting. It asks authors to consider security implications even for bugs found by accident, and to name an assigned CVE in the commit because "it will help distro maintainers".

Severities run MINOR, MEDIUM, MAJOR and CRITICAL; the bug pages describe CRITICAL as "a short-term reliability or security issue for which there is no workaround". Each branch has a "known bugs" page (for example bugs-3.2.html) listing its releases and the fixes queued for the next one. It is blunt: "if you are running any 3.2 version other than 3.2.26, you're running with known bugs".

Branch table: release dates, end of life and notable features

The table below reproduces the haproxy.org branch table as of 25 October 2026, with the feature summary the project publishes for each version. Dates are release dates of the .0 version.

Before 1.9 there was no formal odd and even split; earlier branches were simply maintained for years. One discrepancy: the haproxy.org Quick News entry for 3.2.0 is dated 24 June 2025, while the branch table, bug page and CHANGELOG all give 28 May 2025. We use the release date.

Timeline: how SSL, HTTP/2, HTX and HTTP/3 arrived

Before SSL: ACLs, the CLI and stick tables (1.3 and 1.4)

1.3 (June 2006) introduced the frontend and backend split, ACLs and content switching, and a command line interface. These are still the core of every HAProxy configuration and the basis of most of its security controls: an ACL is a named condition, and rules such as http-request deny act on it.

1.4 (February 2010) brought stick tables. The CHANGELOG entry for 1.4-dev7 on 25 January 2010 reads "Add stick table configuration and init". Stick tables store per-key data, usually per client IP address, and later versions extended them with counters and rates. They became the standard way to rate limit in HAProxy.

Native SSL (1.5, 2014)

Before 1.5, HAProxy did not terminate TLS; 1.3.1 (July 2006) only had "option ssl-hello-chk", a health check sending an SSLv3 hello. Native SSL landed in 1.5-dev12 on 10 September 2012. The news entry calls it "the main, long-awaited, feature" and says it brought SSL "on both sides, with SNI and multi-process session sharing", after a "major rewrite of the lower connection layers".

1.5.0 shipped on 19 June 2014, after what the announcement called "4 years of hard work": 1,574 calendar days, 26 development versions and 2,549 commits. The feature list included "native SSL support on both sides with SNI/NPN/ALPN and OCSP stapling", IPv6 and UNIX sockets everywhere, full HTTP keep-alive, HTTP compression, PROXY protocol versions 1 and 2, and stick table counters that track activity on any sample. The home page summary for 1.5 calls this "DDoS protection".

One small security detail from that period: the 1.5-dev24 news entry on 26 April 2014 said that Heartbleed attacks (CVE-2014-0160) were "detected and blocked even on vulnerable OpenSSL implementations". That was a filter in the proxy, not a fix: HAProxy is only as current as the TLS library it links.

Lua, DNS and TLS tickets (1.6 and 1.7)

1.6 (October 2015) added an embedded Lua interpreter, DNS-based server resolution, server state kept across reloads, server connection multiplexing and TLS ticket secret sharing between nodes. Lua runs inside the proxy, which is one reason the later "fork prevention" default exists. 1.7 (November 2016) added the Stream Processing Offload Engine (SPOE) for handing work to external agents, and OpenSSL 1.1.0 support.

Threads, HTTP/2, master-worker and TLS 1.3 (1.8, 2017)

1.8.0 shipped on 26 November 2017 and the news entry called it "by far the most feature-rich version ever produced". The home page summary lists multi-threading, HTTP/2, a cache, on-the-fly server addition and removal, reloads that keep listening sockets, DNS SRV records and hardware SSL engines.

Three security-relevant changes came with it:

• HTTP/2 on the client side. 1.8 accepted HTTP/2 from clients and talked HTTP/1.1 to servers. The haproxy.org news page had marked the publication of the HTTP/2 RFC on 15 May 2015, while saying 1.6 would not support it yet.
• TLS 1.3. The CHANGELOG entry for 1.8-dev2 (2 June 2017) reads "support TLSv1.3 for bind and server". The same development release added ssl-min-ver and ssl-max-ver, which replaced long lists of "no-sslv3"-style options with a simple version floor and ceiling. 1.8-rc1 added keywords for TLS early data (0-RTT).
• Master-worker mode. 1.8-dev2 also added the master-worker mode, in which a master process supervises workers and handles reloads. Today it is started with -W or -Ws; the 3.4 configuration manual marks the old master-worker keyword as deprecated.

End-to-end HTTP/2 and HTX (1.9 to 2.1)

1.9 (December 2018) added HTTP/2 to servers as well, which the home page describes as "end-to-end HTTP/2". The CHANGELOG entry for 1.9-dev9 reads "implement encoding of H2 request on the backend side". 1.9 also introduced HTX, a new internal representation of HTTP messages that does not depend on the HTTP version on the wire, first as an option ("http-use-htx" in 1.9-dev5). The master CLI, a socket on the master process, also arrived in 1.9-dev5.

2.0 (16 June 2019) turned HTX on by default ("Enable the HTX mode by default for all proxies", 2.0-dev3). 2.1 (25 November 2019) went "HTX-only" and removed obsolete keywords. For security, HTX meant that HTTP/1, HTTP/2 and later HTTP/3 traffic all pass through one normalised message model, so header rules and checks apply the same way whatever protocol the client used.

TLS 1.2 by default and runtime certificates (2.2 to 2.5)

2.2 (7 July 2020) made TLS 1.2 the minimum default on bind lines. The CHANGELOG entry for 2.2-dev9 reads "use TLSv1.2 as the minimum default on bind lines", and the 2.2 configuration manual documents ssl-min-ver with "The default value is 'TLSv1.2'". The same wording is still in the 3.4 manual. 2.2 also added runtime certificate additions and crt-list management, and 2.1 had already added runtime certificate updates, so certificates could be rotated through the Runtime API without a reload.

2.3 (November 2020) made configuration checks stricter by default, and 2.5 (November 2021) added runtime CA and CRL updates and JWT validation.

QUIC and HTTP/3: experimental in 2.6, production in 2.8

QUIC code appears in the CHANGELOG from 2.4-dev5 (January 2021) and HTTP/3 from 2.5-dev8 (September 2021). On 26 March 2022 the news page described trial QUIC on haproxy.org itself, in a separate process advertised with a short-lived alt-svc header, and said "do not reproduce these experiments at home".

2.6.0 shipped on 31 May 2022, and the news entry called QUIC "the star of this release". The 2.6 configuration manual, however, repeats a warning beside each QUIC setting: "QUIC support in HAProxy is currently experimental". QUIC listeners use quic4@ or quic6@ addresses with alpn h3.

2.8.0 (31 May 2023) removed that label. The CHANGELOG entry for the release reads "DOC: quic: remove experimental status for QUIC", and the news entry says QUIC "is now considered production ready after having been running on this site for more than a year".

QUIC needs TLS library support. 2.9 (December 2023) added a "QUIC OpenSSL compatibility layer": per the 3.4 manual, limited-quic enables QUIC on OpenSSL builds without a QUIC API, via USE_QUIC_OPENSSL_COMPAT=1 at build time, "albeit without QUIC 0-RTT capability". 3.2 added support for OpenSSL 3.5's QUIC API. The same HAProxy version can therefore behave differently on QUIC depending on its TLS library, which is why haproxy -vv output belongs in your records.

3.3 (November 2025) added experimental QUIC towards servers, and 3.4 added an experimental QMux mode that carries HTTP/3 over TCP.

Protocol protections, ACME and ECH (3.0 to 3.4)

3.0 (29 May 2024) listed "H2/H3 protocol-level protections" among its features. The mechanism is the "glitch" counter, added in 3.0-dev2 in January 2024: HAProxy counts protocol anomalies per connection and can close connections that exceed a threshold. The 3.4 manual documents tune.h2.fe.glitches-threshold, which is zero (off) by default, with advice that any non-zero value "should probably be in the hundreds or thousands", and an option to apply it only when CPU usage crosses a level. There is a QUIC equivalent, tune.quic.fe.sec.glitches-threshold.

3.2 (28 May 2025) added "early support of the ACME protocol for certificates renewal" and ssl-f-use lines shared across bind lines. 3.3 added kernel TLS and TLS Encrypted Client Hello (ECH), which lets clients "encrypt the SNI". 3.4 (3 June 2026) added HTTP/2 limits on frames and RST_STREAM processed at once, dynamic concurrent-stream limits "that throttle smoothly under attack", ACME DNS-01 and "dns-persist-01" challenges, and OpenSSL 4.0 support.

TLS library choices

2.6 brought OpenSSL 3.0 support, 2.7 eased switching to alternative TLS libraries, and 2.8 and 2.9 each added support for one more. On 3 December 2025 haproxy.org described the "massive performance cost caused by the switch to OpenSSL 3.x" for large users. Whichever library you use, record it per instance: a fix in that library needs its own update and rebuild.

Which built-in security features matter most?

Chroot and privilege drop

The management guide's "Security considerations" section is short and worth reading in full. HAProxy "is designed to run with very limited privileges": start as root, isolate itself in a chroot jail, drop to a non-root user, so that "if any future vulnerability were to be discovered, its compromise would not affect the rest of the system". It warns that many administrators "confuse 'start as root' and 'run as root'" and recommends:

global
    chroot /var/empty
    user haproxy
    group haproxy
    stats socket /var/run/haproxy.stat uid hatop gid hatop mode 600

with the empty directory prepared as mkdir /var/empty && chmod 0 /var/empty. Since 2.9, builds with USE_LINUX_CAP=1 can keep selected Linux capabilities (such as cap_net_bind_service) through the setcap keyword after dropping root, and since 3.1 HAProxy checks the binary's permitted capability set, which removes most reasons to keep running as root.

Fork prevention and setuid locking

The home page lists "chroot, privilege drops, fork prevention, strict protocol validation" among HAProxy's defensive measures and says they "have to be purposely disabled by the user using sufficiently evocative commands". Two of those commands are in the configuration manual:

• insecure-fork-wanted: by default HAProxy "tries hard to prevent any thread and process creation after it starts", which matters "when using Lua files of uncertain origin". The manual says it is "a bad idea to disable it".
• insecure-setuid-wanted: on Linux, HAProxy by default locks the process so that setuid bits on executables are ignored, which "significantly reduces the risk of privilege escalation".

External health checks (external-check) are disabled by default "as a security precaution" and need insecure-fork-wanted to work. If you see either insecure keyword in a configuration, treat it as a finding to justify, not a default.

TLS settings

The global keywords ssl-default-bind-ciphers (TLS 1.2 and earlier), ssl-default-bind-ciphersuites (TLS 1.3) and ssl-default-bind-options set defaults for every bind line that does not override them. The 3.4 manual points to the Mozilla server-side TLS guidance for cipher recommendations and lists OpenSSL's default TLS 1.3 suites. ssl-min-ver defaults to TLS 1.2 on bind lines, strict-sni refuses handshakes whose SNI matches no certificate, and ssl-default-bind-options can carry both. A modern baseline looks like this:

global
    ssl-default-bind-options ssl-min-ver TLSv1.2 no-tls-tickets
    ssl-default-bind-ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256
    ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305

Note that the example in the 3.4 manual's own ssl-default-bind-options entry shows ssl-min-ver TLSv1.0, which is there to illustrate syntax, not to recommend a floor. For background on what to disable, see our post on TLS 1.3 versus TLS 1.2 and what to disable.

Stick tables for rate limiting

Stick tables store counters keyed on a sample, usually the client address. The configuration manual's own example tracks request rates over ten seconds and rejects clients above a threshold. A simpler, common form:

frontend fe_https
    bind :443 ssl crt /etc/haproxy/certs/
    stick-table type ip size 1m expire 5m store http_req_rate(10s)
    http-request track-sc0 src
    http-request deny deny_status 429 if { sc_http_req_rate(0) gt 100 }
    default_backend be_app

Tables can be replicated between nodes with peers sections (full replication arrived in 1.6), so limits hold across a pair of load balancers. Pick thresholds from your own traffic, and remember that many users can share one address behind carrier-grade NAT.

ACLs and request rules

ACLs, from 1.3, are named conditions on any sample: path, header, source address, TLS SNI, JWT claim (since 2.5) and more. http-request deny, tcp-request connection reject and their relatives act on them. Since 2.0 every HTTP version passes through HTX, so these rules apply equally to HTTP/1.1, HTTP/2 and HTTP/3 requests.

The Runtime API and its exposure

The Runtime API is what the manuals call the stats socket. "The stats socket is not enabled by default." When enabled, it can read statistics and, depending on its level, change server states, maps, ACLs and certificates. The level setting has three values: user (read non-sensitive stats only), operator (the default, reads everything and makes "non-sensitive changes") and admin ("everything is permitted").

The management guide shows how to put the socket on a TCP port and immediately adds that this "is never done by default because this is dangerous". Keep it on a UNIX socket with mode 600 (or a group you control), owned by the account that needs it. In master-worker mode the master CLI, bound with -S, gives access to every worker's Runtime API, so protect it the same way: the manual shows -S /tmp/master-socket,uid,1000,gid,1000,mode,600.

The stats web page is a separate thing. It is read-only by default ("By default, statistics page is read-only for security reasons"), and stats admin enables state changes from the page. Put it behind authentication and on an internal listener.

Master-worker mode

Master-worker mode (-W, or -Ws with systemd notify) has a master process read the configuration, fork a worker and handle reloads while old workers finish their connections; 3.1 made the model more reliable by saving a re-exec. Reloads that do not drop connections remove an operational excuse for postponing certificate and configuration updates.

Hardening switches for QUIC

harden.reject-privileged-ports.quic, on by default, rejects QUIC clients that use a privileged source port, a pattern the 3.4 manual links to spoofing and "DNS/NTP amplification".

How are HAProxy security fixes announced and backported?

At concept level, the flow is the same every time:

1. A fix lands in the development branch first. The commit carries a BUG tag with a severity and a backport note, as CONTRIBUTING requires.
2. Maintainers backport it to every affected maintained branch. They do this several fixes at a time, which is why each bug page lists fixes already queued for the next release of its branch.
3. New fix releases ship on the same day across branches. On 14 October 2026, for example, the branch table shows 3.5-dev9, 3.4.7, 3.3.17, 3.2.26, 3.0.30, 2.8.31 and 2.6.35 all dated that day.
4. Announcements go to the mailing list, and the branch table links each version's announcement. Notable security issues also get a Quick News entry on haproxy.org.

The news page gives two dated examples of that last step. On 14 February 2023 it reported a request smuggling issue (CVE-2023-25725) affecting "all currently supported branches", with a fixed version listed for each, from 2.0.31 to 2.7.3. On 12 February 2026 it reported two QUIC parsing issues (CVE-2026-26080 and CVE-2026-26081) where crafted packets "could crash the process", fixed in 3.0.12, 3.1.14, 3.2.12 and 3.3.3.

The project does not tell you to jump branches to get security fixes. The home page says the core team "doesn't insist on users to upgrade" to a new branch, but "will often ask the user to re-check with the latest version of their branch before reporting a problem". If you run a maintained branch at its newest fix release, you have every fix the project has shipped for that branch.

Distribution packages versus the project's own packages

Where HAProxy comes from

The starter guide lists the sources and their trade-offs. haproxy.org provides source tarballs only ("whatever comes from there needs to be rebuilt and/or repackaged"). Operating system packages "generally provide long-term maintained versions which do not always contain all the fixes from the official ones, but which at least contain the critical fixes".

For Debian and Ubuntu there is a middle path. The Debian HAProxy packaging team runs haproxy.debian.net, which publishes per-branch repositories (for Debian) and points to per-branch PPAs (for Ubuntu). Its instructions add a signed-by keyring and a repository line of the form <release>-backports-<branch>, and note that "you will automatically get updates for this major version" while older minor versions are not kept.

What version lag looks like in October 2026

Package archives show the gap clearly. From the Debian sources API and Launchpad on 25 October 2026:

Two lessons come out of this table. First, a distribution package can sit far behind the upstream fix release number while still carrying security patches: the "+deb13u4" suffix means the Debian team has applied its own updates to 3.0.11. Comparing that version string with an upstream "fixed in 3.0.12" line tells you nothing. Use the distribution's security tracker or the package changelog. Second, once the upstream branch goes unmaintained (2.2 and 2.4 above), the distribution is maintaining the code alone. That can be fine for a stable internal service, but for an internet-facing proxy that handles hostile traffic, it is a decision to make on purpose.

Why lag matters more for an edge proxy

The home page puts it plainly: a load balancer "runs at the edge and takes all the dirty traffic", and while you can harden the operating system, "the load balancer itself stays exposed". HAProxy parses HTTP/1, HTTP/2 and QUIC from anyone, terminates TLS through a library with its own release cycle and often runs Lua. An application server behind a firewall can wait for a patch window; the proxy in front of it usually should not.

Packagers also change what haproxy -v tells you. The "Status:" line comes from compile-time macros (PRODUCT_STATUS, PRODUCT_URL_BUGS) that a packager can override, and the starter guide warns that other version formats "may indicate a system-specific package with its own patch set". Container images add one more layer: an image freezes its distribution's HAProxy and TLS library at build time, so only a rebuild pulls in fixes.

Step by step: check what you run and plan the next LTS

1. Find the version, status and build options

# Which binary does the service actually start?
systemctl cat haproxy | grep -E '^ExecStart'
command -v haproxy

# Version, branch status and known-bugs link
haproxy -v

An upstream 3.2 build prints lines like these (the status text is compiled in for each branch):

HAProxy version 3.2.26 2026/10/14 - https://haproxy.org/
Status: long-term supported branch - will stop receiving fixes around Q2 2030.
Known bugs: http://www.haproxy.org/bugs/bugs-3.2.26.html

Then capture the full build details. -vv displays "the version, build options, libraries versions and usable pollers", and the project asks for it with every bug report:

haproxy -vv > /tmp/haproxy-build-$(hostname).txt
grep -iE 'ssl|quic|lua|pcre' /tmp/haproxy-build-$(hostname).txt

Keep this file with your inventory. It tells you which TLS library and QUIC support each instance was built with.

2. Compare with the branch table and the bug page

Open the haproxy.org branch table and check three things: is your branch still maintained, what is its end of life, and what is the newest fix release. Then open the bug page from the "Known bugs" line. If your version is not the newest in the branch, the page lists what you are missing.

If the binary came from a distribution, check the distribution's security tracker for your package version instead, because backports change the picture.

3. Check the Runtime API exposure

# Which stats sockets and levels are configured?
grep -nE '^\s*stats (socket|admin|uri|auth)' /etc/haproxy/haproxy.cfg /etc/haproxy/conf.d/*.cfg 2>/dev/null

# Is anything listening on TCP that should be a UNIX socket?
ss -ltnp | grep haproxy

# Socket ownership and permissions
ls -l /var/run/haproxy*.sock /run/haproxy/*.sock 2>/dev/null

What you want to see: UNIX sockets only, mode 600 or a dedicated group, and level admin only where a tool truly needs it. If ss shows a TCP listener you did not expect, find the stats socket ipv4@... or bind line and remove it or move it to a protected management network.

Also check for the insecure switches:

grep -nE 'insecure-fork-wanted|insecure-setuid-wanted|external-check|^\s*(user|group|chroot)\b' /etc/haproxy/haproxy.cfg

4. Validate the configuration before every change

haproxy -c -V -f /etc/haproxy/haproxy.cfg

-c "only performs a check of the configuration files and exits before trying to bind". The exit status is zero when the configuration is valid, and with -V it prints "Configuration file is valid". Run it in CI on every configuration change, and run it with the target version's binary before a branch upgrade, because each branch tightens checks and drops deprecated keywords. 3.3, for example, dropped "a few long-deprecated keywords" and detects more "config traps".

-dD enables a diagnostic mode that prints extra warnings about suspicious settings; it is useful during an upgrade review.

5. Plan the move to the next LTS

A branch upgrade, for example 2.8 to 3.2 or 3.0 to 3.4, is a project, not a patch:

1. Read the release announcements for every branch in between, including the odd ones, because features and removals accumulate.
2. Run haproxy -c with the new binary against the current configuration and fix every warning, not just errors.
3. Check TLS library changes. A move from an OpenSSL 1.1.1 build to an OpenSSL 3.x build can change performance and default behaviour.
4. Test reloads, certificate rotation through the Runtime API and any Lua scripts on the new version.
5. Roll out to one node of a pair first, watch error rates and glitch counters, then complete the rollout.
6. Put the new branch's end-of-life quarter in your calendar with a year of warning.

6. Choose a branch on purpose

Common mistakes

• The stats page reachable from the internet. A stats uri on a public frontend leaks backend names, addresses and health, and with stats admin lets visitors change server states. Bind it to a management network and require authentication.
• The Runtime API on a TCP port. The management guide calls this "dangerous": anyone who reaches the port gets the socket's level of control. Use a UNIX socket, and protect the master CLI the same way.
• Old ssl-default-bind-ciphers lines copied from a decade-old guide. Long lists with CBC suites and options such as no-sslv3 suggest a configuration nobody has reviewed. Since 2.2 the default minimum is TLS 1.2, and TLS 1.3 suites are set separately with ssl-default-bind-ciphersuites.
• Running a branch past end of life. 2.4 became unmaintained in 2026-Q2 and 3.1 in 2026-Q1. A version that "works fine" is not the same as a version that still receives fixes.
• Stopping at the branch and not the fix release. Running 3.2.10 when 3.2.26 exists means running with known bugs, as the bug page says.
• Comparing distro version strings with upstream fix lines. Backports make "3.0.11+deb13u4" safer than its number suggests. Use the tracker that matches where the binary came from.
• Treating an experimental feature as production. QUIC was labelled experimental until 2.8, and QUIC to servers is experimental in 3.3. Directives tagged experimental need expose-experimental-directives, and the manual says they "are not expected to be supported beyond the release of the next LTS release".
• Forgetting the TLS library. HAProxy can be current while the OpenSSL it links is not. Inventory both.

FAQ

What is the latest HAProxy LTS version?

As of 25 October 2026 the newest LTS branch is 3.4, released on 3 June 2026 and listed as maintained until 2031-Q2. Its newest fix release is 3.4.7 from 14 October 2026. 3.2 (to 2030-Q2) and 3.0 (to 2029-Q2) are also maintained LTS branches.

How long is an HAProxy LTS branch supported?

Five years from release, according to haproxy.org. Near the end, older LTS branches move to a "critical fixes only" phase; on 25 October 2026 that applies to 2.6 and 2.8.

When did HAProxy add SSL support?

Native SSL termination arrived in the 1.5-dev12 development release on 10 September 2012 and in the 1.5.0 stable release on 19 June 2014, with SNI, NPN, ALPN and OCSP stapling.

Which HAProxy version added HTTP/2?

1.8 (26 November 2017) added HTTP/2 from clients. 1.9 (19 December 2018) added HTTP/2 to servers, which the project calls end-to-end HTTP/2.

Does HAProxy support HTTP/3 and QUIC?

Yes. QUIC and HTTP/3 arrived in 2.6 (31 May 2022) as an experimental feature, and 2.8 (31 May 2023) removed the experimental label. QUIC towards servers is experimental in 3.3. QUIC support depends on the TLS library the binary was built against.

How do I check my HAProxy version and whether it is supported?

Run haproxy -v. Upstream builds print the version, a "Status:" line with the branch type and its planned end of fixes, and a link to the known bugs page for that version. Run haproxy -vv for build options and library versions.

Is it safe to expose the HAProxy Runtime API?

Not on an open network. It is disabled by default; when enabled, keep it on a UNIX socket with restrictive permissions, use the lowest level that works, and never bind it to a public address. The project's own guide calls a TCP listener for it dangerous.

Should I use my distribution's HAProxy package or haproxy.org builds?

The project often suggests the operating system version when it follows the official maintenance cycle. If your distribution ships an unmaintained upstream branch, or lags a branch you need, the Debian packaging team's haproxy.debian.net repositories or building from haproxy.org sources are the alternatives. Whichever you choose, track fixes through that source's channel.

Where Safeguard fits

The fit is partial, and the boundary is worth stating. HAProxy usually reaches production as a distribution package, a container image or a binary built from haproxy.org sources, not as a library inside your application code. Safeguard does not patch the HAProxy binary on a host you run, and it does not replace your distribution's security updates or the project's fix releases.

Where it helps is the inventory and the gate around what you build. Scanning a container image with safeguard scan --image <name> lists the packages inside it, which is how you find every image that still carries an HAProxy or TLS library package from an unmaintained branch, and the platform shows which projects contain a given component and version. Policies and gates evaluated in CI can stop images with known vulnerable versions from shipping. For the application code behind the proxy, the same scans cover its open source dependencies, and reachability analysis ranks findings by whether your code calls the vulnerable path; how much that narrows the list depends on the codebase and is worth measuring during an evaluation. Gold Open Source at gold.safeguard.sh gives free CVE intelligence with affected and fixed versions for open source components.

HAProxy itself is one package, but the images it runs in, the TLS library it links and the services behind it all pull in open source components that drift the same way an unpatched branch does. The options below cover those dependencies and images you build and ship; fixes for the HAProxy binary still come from haproxy.org or your distribution.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Gold Registry provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

Start with the CLI. In this recorded session the assistant reads a finding and its advisory, asks before any command that changes something, edits the dependency version, then runs the install and the tests and pushes nothing. For HAProxy, the equivalent change you own is usually a base image tag or a package pin in a Dockerfile, and this is how you would get it as a tested edit instead of a ticket.

Click through it at your own pace, or open it full screen.

Edge proxy fixes often land outside office hours. The mobile demo is a real Android session that sends work to a computer running the CLI and approves the proposed command from the phone with Allow once, Allow for turn or Deny, so an on-call engineer can review a rebuild step without opening a laptop.

Click through it at your own pace, or open it full screen.

The last demo sets up the Safeguard runner on your own machine, approves it with its device code and scans from the terminal. Point it at the images that carry HAProxy in your build environment to see which branch and TLS library each one ships before it reaches a registry.

Click through it at your own pace, or open it full screen.

To try this on your own images and repositories, download Safeguard or read the CLI documentation. For the wider picture of proxy placement and hardening, see our posts on load balancer security considerations and Envoy proxy security hardening, and the companion histories of nginx and OpenSSL.

Quick check

Sources

• HAProxy home page, branch table and version history (haproxy.org)
• HAProxy news archive (haproxy.org)
• HAProxy CHANGELOG, development branch (git.haproxy.org)
• HAProxy 3.4 Management Guide
• HAProxy 3.4 Configuration Manual
• HAProxy 3.4 Starter Guide
• HAProxy 2.6 Configuration Manual
• HAProxy 2.2 Configuration Manual
• HAProxy documentation index (docs.haproxy.org)
• HAProxy known bugs for branch 3.2
• HAProxy 3.2 version.h, branch status string (git.haproxy.org)
• HAProxy 3.2 haproxy.c, version output (git.haproxy.org)
• HAProxy CONTRIBUTING guide (GitHub mirror)
• HAProxy README and licence (GitHub mirror)
• Mailing list reply to the HAProxy 2.6.0 announcement, 31 May 2022
• Debian and Ubuntu HAProxy packages (haproxy.debian.net)
• Debian sources: haproxy versions per suite
• Ubuntu Launchpad: haproxy source package

Last reviewed: 25 October 2026. HAProxy ships fix releases often; check the branch table on haproxy.org for the latest versions and end-of-life dates.