Pre-Auth Root RCE in Progress Kemp LoadMaster: Patch the API Now

Another load balancer, another pre-auth root RCE.

Progress Kemp LoadMaster — the application delivery controller that fronts a lot of enterprise web traffic and, often, a lot of identity infrastructure — has a critical flaw in its management API. Tracked as CVE-2026-8037, the bug carries a CVSS of 9.8. An unauthenticated attacker can hit the API with a crafted request and execute arbitrary commands as root on the appliance. No credentials. No session. No prompts.

A patch is out. If your LoadMaster API is reachable, install it.

The authentication distinction matters here, because there isn't one. This isn't a privilege escalation from a low-privileged operator. It's not an authenticated admin abusing a debug endpoint. The vulnerable path sits in front of any identity check the appliance would normally enforce, which means MFA on the admin UI does precisely nothing for you. The API is the front door, and the lock is missing.

Would MFA have helped? Honestly, no. This is an authn bypass at the protocol handler, not a credential problem. The only mitigations that matter are patching and not exposing the management plane to anything you wouldn't trust with a root shell.

That last part is the uncomfortable bit. LoadMaster appliances frequently sit on the edge, and their management interfaces have a long history of being one firewall rule away from the public internet. Shodan tends to find more of them than operators expect. If yours is one of those, assume the window between disclosure and exploitation is short. Edge appliances with pre-auth RCE are catnip for initial-access brokers, and LoadMasters are particularly attractive because they often terminate TLS for downstream apps — including SAML IdPs and OIDC relying parties. A root shell on the box that holds your TLS private keys is not a contained incident.

What to do, in order:

• Apply the vendor patch from the Progress security advisory for your LoadMaster branch.
• Restrict the management API to an admin VLAN or jump host. The API should never have been internet-reachable, and now is a good moment to fix that.
• Rotate any TLS private keys, API tokens, and shared secrets the appliance handled. If it was exposed and unpatched, treat the keys as burned.
• Pull access logs for the API endpoint and look for unexpected POSTs prior to patching.

There's no public exploit code at time of writing, but a 9.8 unauthenticated RCE on a widely deployed edge device does not stay theoretical for long. The ZDI advisory and the vendor bulletin are the authoritative references; ignore anyone selling urgency beyond that.

Patch the box. Then go look at what else is listening on its management interface.