On September 4, Rapid7 Labs published research on a Linux espionage toolkit found at two organizations in South Korea. The centerpiece is a backdoor the researchers call "Ted," which was hidden inside a modified HAProxy build running on the victims' load balancers. Rapid7 attributes the campaign to North Korean state-sponsored actors with medium confidence.
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:
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.
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.
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.
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.
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)/rootshould point to an empty or deleted directory (the chroot)Uidin/proc/$(pidof haproxy)/statusshould be non-zero, with effective capabilities at or near nothingMax processesin/proc/$(pidof haproxy)/limitsshould 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.
Subscribe to our blog. Get the latest release updates, tutorials, and deep-dives from HAProxy experts.
