Kemp LoadMaster's quote sanitizer became a pre-auth root RCE, exploited hours after the writeup dropped

A load balancer is supposed to sit in front of everything and stay boring. Progress Kemp LoadMaster just failed at that in the worst way. The flaw now under active exploitation, CVE-2026-8037, does not hide in some obscure feature. It lives inside the exact function the appliance uses to sanitize input before handing it to a shell, the one piece of code written to prevent this class of bug. That function fails open. The result is remote code execution as root with no login at all. If your LoadMaster exposes its management API, this is today's work.

The sanitizer that failed open

The bug sits in a helper called escape_quotes(), whose only job is to neutralize single quotes in user-supplied text so they cannot break out of a shell command. Two mistakes turned that defense into the way in. It allocated its working buffer with malloc(), which hands back memory without clearing whatever was already there, and it never wrote a terminating null byte at the end of the escaped string.

When the appliance assembled the login command and read the escaped username back, the read ran past the intended data into neighboring heap memory. An attacker who had already placed a command string in that adjacent memory got it stitched straight into the shell command. The entry point is the /accessv2 endpoint, which checks API credentials before any session exists, so the whole chain runs unauthenticated and as root. watchTowr Labs reverse-engineered the patch and documented the technique; the working exploit is theirs to publish, not ours to reprint.

The Zero Day Initiative scored it 9.8, though some advisories list it at 9.6. The number is a detail. A pre-auth root RCE on an internet-facing appliance is as bad as this category gets.

Exposure hinges on one setting: is the API reachable

Two things have to be true for CVE-2026-8037 to touch you. You are running a vulnerable build, and the management API is enabled and reachable by whoever is knocking.

The API gate matters more than the version number. A LoadMaster whose management interface answers only on an internal segment is far harder to reach than one whose API responds on an internet-facing address, which is common where teams drive configuration through automation. Check reachability first, then check the build. Progress fixed the flaw in GA v7.2.63.2 and in the long-term LTSF branch at v7.2.54.18. Instances with the API disabled are not exploitable through this path.

How a quiet 25-day window closed in a single day

Progress shipped the fix on June 4 and said at the time it had no reports of exploitation. For 25 days that held. Then on June 29 watchTowr published a full walkthrough of the exploit chain, and the same day eSentire's Threat Response Unit began seeing exploitation attempts against the /accessv2 endpoint.

The lesson is about clocks. For an internet-reachable appliance, the patch-release date is not when the risk spikes. It spikes when a working exploit becomes public, and that can land weeks after the fix and then convert to real attempts within hours. Teams that read "patched, no known exploitation" as breathing room keep getting caught on exactly this seam. We made the same point when INC ransomware built its whole operation on unpatched appliances instead of zero-days.

Watch the API, not the box

LoadMaster is an appliance. You do not install an endpoint agent on it, so the usual place you would catch a root shell, process telemetry on the host itself, is not available. Detection has to move to the network in front of the management interface. Three things are worth an alert:

• POST requests to /accessv2 from sources outside your expected administrator ranges.

• Requests to that endpoint with abnormally large bodies or many repeated fields, the shape a heap-spray attempt takes.

• Connections from the addresses eSentire flagged: 192.42.116.58, 192.42.116.105, and 146.70.139.154. Treat these as a starting point, not a full list; infrastructure rotates.

eSentire reported attempts but no confirmed successful post-compromise activity yet. That distinction only exists because a network sensor saw the attempts. The appliance's own logs may show nothing useful, which is the recurring blind spot with security middleboxes: they inspect everyone else's traffic and instrument their own poorly. The same reflex applied to a NetScaler memory bug earlier this year, and to gateways that stayed breached after the patch went on.

The second pre-auth RCE in LoadMaster's API in two years

This is not LoadMaster's first pre-auth command-injection bug. In 2024, CVE-2024-1212 (CVSS 10.0) let unauthenticated attackers run operating-system commands through the same management API. Two bugs of the same class, in the same interface, inside two years, is a pattern rather than bad luck.

The management plane of a load balancer parses attacker-controllable strings and hands them to a shell, and that design keeps producing the same failure. The practical read: treat the LoadMaster API as hostile-reachable by default, and do not expose it to any network you would not trust to send it a crafted request.

Patch to 7.2.63.2, then take the management API off the open internet

Two actions, in order. Patch every LoadMaster to GA v7.2.63.2 or LTSF v7.2.54.18 today. This is a pre-auth root RCE with a public exploit and confirmed in-the-wild attempts, so it belongs at the front of the queue, ahead of higher-scored bugs that nobody is touching yet. A high CVSS does not always mean a live shell; this one does.

Then, patched or not, restrict the management API so it answers only to your administration network or a VPN, never the public internet. The patch closes this specific bug. Restricting reachability is what protects you from the next one, and the two-bug history says there will be a next one. If your interface was internet-facing during the exploitation window, assume probing and hunt: review /accessv2 access for the request patterns above, and check the appliance for unexpected processes or outbound connections.