A second maximum-severity, unauthenticated command execution flaw has now hit Progress Kemp LoadMaster in under two years. Attackers began testing the latest one, CVE-2026-8037, within hours of the technical detail going public. This Kemp LoadMaster vulnerability should be the moment businesses stop treating load balancers as invisible plumbing and start patching them like the internet-facing systems they are.
It is tempting to file this away as one more CVE in a week that always has several. That temptation is exactly the problem. The device sitting behind this particular flaw is not a laptop or a single web server. It is the piece of infrastructure that every customer request passes through before it reaches anything else, which is a strange thing to leave under-patched.
Table of Contents
The Kemp LoadMaster vulnerability fits a pattern
CVE-2026-8037 is a command injection bug in a function called escape_quotes(). It was supposed to sanitise input before it reached a shell command. Per a technical breakdown from watchTowr Labs, the function allocates memory without clearing it. It then fails to terminate the cleaned string properly, leaving room for a remote, unauthenticated attacker to smuggle commands through the appliance’s /accessv2 API. Progress rated it 9.6 on the CVSS scale. The Zero Day Initiative, which received the original report, rated it 9.8.
On its own, that is a serious but ordinary vulnerability disclosure. What makes it worth an opinion, not just a summary, is the company it keeps. This is the same product line that shipped CVE-2024-1212 in 2024, also rated at or near the maximum severity, also pre-authentication, also exploited once it became public. Two incidents do not prove a company is careless. They do prove that this class of appliance, edge devices with privileged network positions and infrequent patch cycles, keeps producing exactly this kind of bug, in this vendor and others.
Vendors say “no evidence of exploitation.” Read that literally.
Progress said, when it first published its advisory in early June, that it had not seen exploitation. That statement was accurate. It was also, in hindsight, not very reassuring. watchTowr Labs published a detailed exploit chain on 29 June. eSentire’s Threat Response Unit recorded exploitation attempts starting that same day. The attempts observed so far failed, according to eSentire. But the gap between “no evidence yet” and “under active attack” was measured in hours, not weeks.
This Kemp LoadMaster vulnerability makes the point well. Security teams that read “no known exploitation” as “not urgent” are drawing the wrong lesson. They draw it every time a technical write-up follows a patch. The absence of evidence is a snapshot, not a forecast. It describes what was true on the day it was written, and nothing about the week after.
Load balancers do not get the attention they deserve
Ask most IT teams when they last checked their firewall’s firmware version. You will likely get an answer. Ask about the load balancer sat in front of it and you often will not. It rarely gets restarted, rarely breaks, and rarely comes up in a change-management meeting. That is precisely the profile that makes it valuable to an attacker. It is internet-reachable, trusted by everything behind it, and easy to forget.
A load balancer compromise is not equivalent to losing one application server. It sits in front of everything the appliance routes to. That means an attacker with a shell on it can potentially intercept traffic, manipulate routing, or use it as a launch point into the internal network. The blast radius is larger than the device’s low profile suggests, and it is rarely accounted for in the risk register.
What should actually change after this Kemp LoadMaster vulnerability
If you run Kemp LoadMaster, patch to GA 7.2.63.2 or LTSF 7.2.54.18 now. Disable the API if you are not using it. That is the mechanical fix, and it takes an afternoon at most.
The more useful change is structural. Put every internet-facing appliance, load balancers, VPN gateways, remote access gear, on the same patching cadence as your public web servers. Review it monthly rather than reactively after a headline. If nobody currently owns that review, that gap is worth fixing before the next one of these arrives. On current form, there will be a next one, and it probably will not announce itself in advance either.
A periodic external penetration test earns its cost precisely here. It tells you honestly whether that edge appliance is reachable, patched and configured the way you assume it is, rather than the way a change log says it should be. Most organisations only learned about this Kemp LoadMaster vulnerability from an advisory. Waiting for the next one to find out is the expensive way to learn the answer.
Subscribe to our newsletter for a weekly round up of what's happening in the cyber security world
