Progress LoadMaster CVE-2026-8037: A Pre-Auth RCE in the Load Balancer

A load balancer is the one box on your perimeter that sees plaintext for everything behind it. It terminates TLS, rewrites requests, holds the certificates, and routes traffic into the parts of your network that never expected to be reachable from outside. CVE-2026-8037 is an unauthenticated command-injection flaw in Progress Kemp LoadMaster — one of the most widely deployed application delivery controllers in the enterprise — that hands an attacker code execution on exactly that box, with no login required. Progress shipped the fix in June. By August 7 the bug was on CISA's Known Exploited Vulnerabilities catalog with 792 recorded exploit attempts behind it. That two-month gap is the entire story.

What CVE-2026-8037 actually is

The one-line description reads like a hundred other advisories: "OS command injection in the API allows an unauthenticated attacker to execute arbitrary commands." NVD rates it CVSS 9.8 (AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H); Progress and CISA carry it at 9.6. Either way it is a pre-auth remote code execution on an internet-facing appliance, which is the worst combination of properties a bug can have.

The mechanism is more interesting than the headline. According to watchTowr Labs, who reverse-engineered the patch, the flaw lives in a helper called escape_quotes(), reached through the unauthenticated /accessv2 endpoint that parses apiuser and apipass from a JSON body. Two mistakes stack:

• The function allocates its output buffer with malloc() instead of calloc(), so it starts life full of uninitialized heap contents — allocator metadata, remnants of freed chunks.
• It never writes a null terminator after the escaped output.

Each single quote in the input expands to four bytes (' becomes \'\'). Feed apiuser: "''''" and you produce sixteen bytes of escaped output with no terminating null anywhere in it. When the appliance later builds a shell command with __sprintf_chk(), it reads past the buffer — through the surrounding heap — until it finds a null byte that is no longer there. An attacker who has sprayed a command payload into adjacent JSON values gets that payload read straight into the command string and executed as root.

Reviewer: "It's a quoting bug. Our WAF strips shell metacharacters, so we're covered."

Reality: The injection point isn't a metacharacter you can blocklist. It's a missing null terminator that lets the parser walk into memory you control. The malicious bytes arrive as ordinary-looking API field values; there is no ; or | for a WAF to catch. The exploit is a heap layout, not a payload signature.

This is why the bug is dangerous well beyond its CVSS number. It defeats the two controls most teams lean on for edge appliances — "it needs authentication" (it doesn't) and "our WAF filters injection" (this isn't the injection your WAF models).

Why a load balancer is the worst place to lose

Application delivery controllers sit at a structural chokepoint. Compromise one and you inherit its position, not just its shell:

• TLS termination. The appliance holds the private keys for the sites it fronts. Root on the box is root over the certificates.
• Backend reachability. Load balancers are, by design, allowed to talk to the internal services no one else can reach. A shell there is a pre-authorized pivot into the application tier.
• Credential exposure. Health-check accounts, API tokens, and backend service credentials are configured on the appliance in the clear or near-clear.
• A blind spot in your monitoring. Nobody runs EDR on a LoadMaster. The one host positioned to see all your traffic is usually the one host with no endpoint telemetry of its own.

This lineage is not new. Zero Hunt's knowledge base flags the same class of bug going back years — Barracuda Load Balancer command injection (CVE-2017-6320), the Zen Load Balancer certificate-parameter injections (CVE-2019-7301) — all root-via-shell-metacharacters on the device that fronts everything. CVE-2026-8037 is the 2026 entry in a long list, distinguished only by being pre-authentication.

From June patch to August KEV: the timeline

The uncomfortable part of this story is chronology. The fix existed for weeks while exploitation ramped.

Date	Event
June 2026	Progress issues fixed builds (GA 7.2.63.2, LTSF 7.2.54.18) and the security bulletin
~June 29, 2026	First exploitation attempts observed
July 2026	eSentire reports active but "largely unsuccessful" exploitation in the wild
August 4, 2026	Latest recorded activity in eSentire's telemetry window
August 7, 2026	CISA adds CVE-2026-8037 to the KEV catalog
August 10, 2026	Federal remediation deadline under Binding Operational Directive 26-04

Across that window eSentire logged 792 exploitation attempts from 65 unique IP addresses across 18 countries — Australia, China, Indonesia, Japan, Poland, and the United States among them. The "largely unsuccessful" note matters: it means the attackers were spraying the exploit at unpatched targets and mostly missing, which is exactly what a mass-scanning campaign against a two-month-old CVE looks like before someone tunes the heap spray. "Largely unsuccessful" is a status, not a guarantee.

The three-day federal deadline (August 7 to August 10) is worth reading carefully. Under BOD 26-04, CISA replaced its old flat 14-day KEV rule with risk-based tiers; a pre-auth RCE on an edge appliance lands in the shortest-clock tier. If your organization tracks NIS2 or DORA obligations, that tiering is the emerging European reference standard for "how fast is fast enough," and three days is now the answer for this class of exposure.

Remediation

Progress calls out one non-obvious condition: exploitation targets the API, so an appliance with the LoadMaster REST API enabled and reachable is what an attacker looks for. That shapes both the exposure check and the compensating controls.

1. Am I affected?

Check the running firmware version from the LoadMaster UI (System Configuration → Update Software) or over SSH:

# On the appliance
cat /etc/version    # or check "Firmware Version" in the WUI banner

You are vulnerable if you run:

• LoadMaster GA 7.2.63.1 or older
• LoadMaster LTSF 7.2.54.17 or older

The same code path also affects the ECS Connection Manager, Connection Manager for ObjectScale, and MOVEit WAF builds derived from LoadMaster. Then confirm exposure — is the management/API interface reachable from untrusted networks?

# From an external vantage point, is /accessv2 reachable?
curl -sk -o /dev/null -w "%{http_code}\n" https://<lb-mgmt-ip>/accessv2

Any response other than a connection refusal means the pre-auth endpoint is reachable and you should treat the appliance as exposed.

2. Patch — exact fixed versions

Upgrade to the builds Progress shipped in June:

• LoadMaster GA → 7.2.63.2 or later
• LoadMaster LTSF → 7.2.54.18 or later

Apply the corresponding fixed builds for ECS Connection Manager, Connection Manager for ObjectScale, and MOVEit WAF from the Progress security bulletin. Patching is the only complete fix; the controls below buy time, not safety.

3. Can't patch this hour? Compensating controls

• Take the API and management interface off the public internet. Bind LoadMaster administration to a dedicated management VLAN or restrict /accessv2 to an allowlist of admin source IPs. A pre-auth exploit against an endpoint no attacker can reach is a non-event.
• Front the management plane with a VPN or bastion. Do not expose appliance administration directly; require an authenticated network hop first.
• Rate-limit and alert on /accessv2. Bursts of POSTs to that path from many source IPs are the campaign signature — 65 IPs is a spray, not a targeted probe.

4. Hunt for compromise

This maps cleanly to MITRE ATT&CK. Treat the appliance as potentially breached if it was internet-exposed and unpatched at any point since late June.

• T1190 (Exploit Public-Facing Application): review load balancer and upstream logs for POSTs to /accessv2 with abnormally long or quote-heavy apiuser/apipass values. eSentire named 192.42.116.58, 192.42.116.105, and 146.70.139.154 as source IPs — search for these, but do not treat the list as exhaustive.
• T1059 (Command and Scripting Interpreter): look for shell processes spawned by the appliance's web/API service — anything the load balancer's normal operation would never launch.
• T1505.003 (Web Shell): inspect appliance-writable web directories for new or modified files. Detection-rule libraries (for example the public Sigma "Webshell Detection With Command Line Keywords" rule) key on interpreter processes invoking recon commands like whoami, id, and ipconfig from a web context.
• T1071 / egress anomalies: a load balancer historically only receives connections. New outbound sessions from the appliance to unfamiliar ASNs — a reverse shell calling home — are one of the highest-fidelity signals available, precisely because this host has no legitimate reason to initiate them.

5. Eradicate and verify

• Remove any web shells, cron entries, or modified binaries found; on an embedded appliance the cleanest path after confirmed compromise is a wipe and rebuild from a known-good image, then patch before returning it to service.
• Rotate every secret the appliance touched: TLS private keys for the fronted sites (root on the box means the keys are assumed disclosed), backend and health-check credentials, and any API tokens configured on it.
• Re-run the exposure check from step 1 to confirm the API is no longer reachable from untrusted networks, and confirm the running version is a fixed build — an implant that survived can also spoof a "patched" banner, so verify from the outside as well as on-box.

Where continuous testing changes the math

Every hard number in this post points at the same gap: the fix shipped in June, the exploitation ran through July, and the KEV listing landed in August. Nothing was hidden. The vulnerable appliances were reachable and the patch was available the entire time. What was missing was anything that continuously asked "is our LoadMaster still reachable and still exploitable, today?" between the quarterly assessment and the incident.

That question is what Zero Hunt's 10-agent generative engine exists to answer. Rather than pulling a static exploit from a database, the Exploit agent writes a per-target proof for the specific appliance and firmware in front of it — the same reasoning watchTowr applied by hand, executed on your perimeter on a schedule and re-run automatically the hour a new appliance appears. Every exploit skill is backtested in the AI Gym before it touches production, and every finding is ECDSA-signed for the audit trail — so "the LoadMaster was patched on this date" is evidence, not a recollection. Against BOD 26-04's three-day clock, evidence you can produce on demand is the difference between a closed finding and an open one.

And because a compromised load balancer is a stealth position more than a loud one, the AI Traffic Analysis model covers the other half. Its four inference heads run on the appliance GPU at wire speed, watching for exactly the signal step 4 describes: a device that has only ever accepted connections suddenly opening an outbound session to a never-seen ASN. That is the reverse shell leaving the load balancer — caught while it happens, not in the next morning's log review. For the broader pattern of edge appliances that stay exploitable after the vendor ships a fix, see our coverage of CitrixBleed 3 and the NGINX HTTP/3 RCE.