CVE-2026-8037: The Progress LoadMaster Bug Now on CISA's KEV List

A load balancer sits in front of everything. It sees every request before your application does, and it usually runs with enough privilege to touch the whole cluster behind it. That’s exactly why CVE-2026-8037, an unauthenticated command injection in Progress Kemp LoadMaster, is bad news: a CVSS 9.6 bug that hands an anonymous attacker a shell on the one box your entire application tier trusts implicitly. CISA added it to the Known Exploited Vulnerabilities catalog on August 7, and if you’re running an unpatched LoadMaster reachable from the internet, the working assumption should be that someone has already tried it against you.

What’s actually broken

The root cause is unglamorous, which is usually how the worst ones look. LoadMaster’s management API includes a function called escape_quotes(), whose whole job is to sanitize user-supplied input before it gets anywhere near a shell command. It allocates a heap buffer with malloc(), sized to hold the escaped version of the input, writes the escaped characters into it, and then hands that buffer off to be treated as a string.

The bug is that it never writes a null terminator after the escaped output. Anything that later reads this buffer as a C string doesn’t stop where the actual escaped data ends. It keeps reading into whatever memory happens to sit next to it on the heap, which can include the leftover contents of a previously freed allocation. That’s an out-of-bounds read, and on its own it would just be an information leak or a crash. What makes it a remote code execution bug is that an attacker who can shape what ends up in that adjacent freed memory, through other requests to the same API, can plant command fragments there. escape_quotes() reads those fragments back as if they were part of the legitimately escaped input, and the result gets passed to system(). A sanitization function becomes the delivery mechanism for the exact class of attack it was written to prevent.

None of this requires a login. The vulnerable endpoints sit on LoadMaster’s management API surface, and an attacker who can reach that surface over the network is the only prerequisite.

The timeline that made this urgent

Progress actually fixed this quietly back on June 4, 2026, in LoadMaster GA 7.2.63.2 and LTSF 7.2.54.18, bundled alongside a separate fix for CVE-2026-33691. For three and a half weeks, that was a routine patch note most administrators had no particular reason to rush.

That changed on June 29, when a public proof of concept and a detailed technical writeup of the bug went live. Exploitation attempts started within a day, according to eSentire’s monitoring. By early August, The Hacker News reported hundreds of distinct exploitation attempts logged against internet-facing LoadMaster instances. CISA formally added CVE-2026-8037 to its KEV catalog on August 7, which triggered a mitigation deadline of August 10 for U.S. federal civilian agencies under Binding Operational Directive 26-04.

That’s the pattern worth internalizing here, independent of this specific product: a quiet patch in a release note is not the same signal as a public proof of concept. The gap between “fixed and available” and “actively exploited in the wild” was three and a half weeks, and the gap between “PoC published” and “attacks observed” was under 24 hours. If your patch cadence for infrastructure appliances is measured in months, this is the kind of bug that finds you first.

What to check right now

If you operate LoadMaster in any capacity, run through this in order:

1. Confirm your version. Anything at GA 7.2.63.1 or LTSF 7.2.54.17 or earlier is vulnerable. Check against 7.2.63.2 / 7.2.54.18 or later.
2. Patch immediately if you’re behind, then don’t stop there. Patching closes the hole going forward; it does nothing about a window that’s already been open for over a month with public exploit code circulating.
3. Check for signs of prior compromise on any instance that was internet-reachable and unpatched between June 29 and whenever you apply the fix. That includes unexpected processes, modified configuration, new admin accounts, and outbound connections you can’t account for.
4. Get the management interface off the public internet, full stop. A load balancer’s admin API has no legitimate reason to be reachable from anywhere but a management network or VPN, and every unauthenticated RCE in a network appliance over the past few years has followed the same shape: a device that should never have been internet-facing, was.

The specific bug here is a memory-safety mistake in a sanitization function, similar in spirit to the TeamCity deserialization flaw that landed on the KEV list a few days earlier: different code, same category of failure, where a component built to enforce a trust boundary turned out to have a gap in exactly the place that boundary depended on. If your infrastructure includes appliances like this, a periodic security review that specifically inventories internet-facing management interfaces catches this class of exposure before a KEV alert forces the question.

Load balancers, VPN concentrators, and CI servers keep showing up in this same story: high-privilege infrastructure that isn’t code your team wrote, doesn’t get the same scrutiny as application code, and sits exactly where an attacker wants to land. Patch it like it’s exposed, because eventually it will be.