There Is a Public Exploit for a Pre-Auth Root Bug in Kemp LoadMaster. If Your Load Balancer's API Is On, Read This First.

# There Is a Public Exploit for a Pre-Auth Root Bug in Kemp LoadMaster. If Your Load Balancer's API Is On, Read This First.

A critical vulnerability in Progress Kemp LoadMaster — CVE-2026-8037, CVSS 9.8 — lets an unauthenticated attacker run commands as root on the appliance by sending a single crafted request to its management API. Progress published the advisory on June 4 and said, truthfully at the time, that it had seen no exploitation. On June 29 that calculus changed: watchTowr Labs published a full technical write-up walking through the entire exploit chain. A pre-auth root bug on an internet-facing load balancer, with a public map to working exploitation, is not a patch-next-cycle problem. This is a tonight problem, and here is exactly what to check.

---

What LoadMaster is, and why a bug in it is worse than a bug in your app

Kemp LoadMaster is an application delivery controller — a load balancer that sits at the front of your network and steers traffic across your servers. By definition it lives at the edge, with a foot in the untrusted internet and a foot inside your environment. It is the thing your real applications hide behind. A vulnerability in the appliance that guards the door is categorically worse than a vulnerability in any one application, because the appliance can see, and often route, everything.

The same Progress advisory that covers LoadMaster also names ECS Connection Manager, Object Scale Connection Manager, and — the one that will make some readers wince — the MOVEit WAF. These are all products built to sit in front of other things and be trusted. When the guard is the weak point, every asset it was guarding inherits the risk.

The bug, in plain language

CVE-2026-8037 is an OS command injection that becomes a pre-auth remote code execution. The root cause is a subtle one, and it is worth understanding because it explains why the fix matters and why guessing at a workaround is dangerous.

The flaw lives in a function called escape_quotes(), whose entire job is to sanitize user-supplied input before it gets handed to a shell command. The implementation failed to properly terminate its output, and combined with the way the surrounding heap memory is laid out, that failure lets an attacker's input escape the intended quoting and reach the shell as commands rather than as data. The result: an unauthenticated remote attacker sends a crafted request to the LoadMaster API and the appliance executes their commands as root. No credentials. No prior foothold. The Zero Day Initiative rated it CVSS 9.8, which is about as high as these numbers go without being a self-propagating worm.

The one meaningful precondition is that the API feature has to be enabled on the device. That is your first triage question tonight: is the LoadMaster management API turned on, and is the management interface reachable from anywhere it should not be?

Who is affected

The vulnerability affects Kemp LoadMaster GA version 7.2.63.1 and older, and LTSF version 7.2.54.17 and older, specifically when the API feature is enabled. If you are on those trains with the API on, you are in scope. Progress's advisory is the authoritative source for the fixed builds — apply the vendor's patched version rather than trusting any partial mitigation, because with a heap-and-quoting bug like this one, "we filtered the obvious payload at the WAF" is not a fix, it is a speed bump.

Where the timeline actually puts you

Here is the honest state of play, and the honesty matters because the risk is a function of the calendar, not just the CVSS score.

Progress published its advisory on June 4 and stated it had received no reports of exploitation. For roughly three and a half weeks that was a "patch on a sane schedule" situation. On June 29, watchTowr Labs published a detailed technical write-up that walks through the full exploit chain — how the escape_quotes() flaw is reached, how the heap semantics are abused, how it lands as root. A public, step-by-step exploitation write-up for a pre-auth root bug on an edge appliance collapses the window. The gap between "described in a research blog" and "sprayed by a botnet against every exposed instance" for this class of vulnerability has historically been measured in days, not months.

We want to be precise here rather than dramatic: as of this writing we have not confirmed indicators of in-the-wild mass exploitation of CVE-2026-8037 in our own corpus, and neither the vendor advisory nor the public reporting we reviewed claims confirmed ransomware use yet. What exists is a maximum-severity pre-auth RCE, a public exploit chain, and an edge appliance that is internet-facing by design. That is the precise moment to move — before the confirmation, not after it. Waiting for someone else's incident to prove the risk is how you become the incident.

What to do tonight

Start with exposure. Find every Kemp LoadMaster, ECS Connection Manager, Object Scale Connection Manager, and MOVEit WAF in your estate — including the ones a team stood up two years ago and forgot. For each one, answer two questions: is it on an affected version, and is the management API enabled and reachable? An affected version with the API off and the management interface locked to an internal admin network is a very different exposure than an affected version with the API answering the open internet.

Then patch to the fixed version Progress specifies in its advisory. Do not settle for a workaround if a patch is available; a quoting-and-heap bug does not have a reliable input-filter mitigation you should bet the edge on.

While you patch, tighten the blast radius: restrict the LoadMaster management interface and its API to a trusted management network rather than exposing it to the internet. A load balancer needs to serve traffic on its front end; it does not need its administrative API answering the whole world, and it never did.

And because a pre-auth RCE means an attacker who got in left as root, treat any exposed-and-unpatched appliance as potentially compromised rather than assuming you were quick enough. Review it for unexpected processes, unfamiliar accounts or SSH keys, outbound connections you cannot explain, and configuration changes you did not make. If you find any of that, the appliance goes into incident response, not back into production with a fresh patch on top of an attacker's foothold.

Why we are writing this up

This is the beat we keep returning to because the pattern keeps proving itself: the foot in the door is every foot. Edge appliances — VPN concentrators, load balancers, firewalls, secure file transfer gateways, web application firewalls — are the highest-value target on the modern network precisely because they are trusted, internet-facing, and often under-monitored. A pre-auth root bug in the thing that guards the door is the whole game, and the attackers know it. We have watched this movie with Ivanti, with Fortinet, with Cisco ASA, with SonicWall, with MOVEit itself. Kemp LoadMaster is the same story with a new CVE number.

We will not overstate our position on this one. We do not have exploiter IPs to hand you tonight, and we are not going to invent confidence we have not earned — the value here is the timeline and the triage, delivered on the day the exploit chain went public rather than the week after the first victim. If your load balancer is running an affected build with the API on, the useful thing we can do is make sure you heard it in time to move: patch to the version Progress specifies, get the management API off the open internet, and go look at anything that was exposed before you did. The clock on this one started on June 29.

---

Her name was Renee Nicole Good.

His name was Alex Jeffery Pretti.