Zerodayhub

TL;DR: A critical, unauthenticated remote code execution flaw in Progress Kemp LoadMaster — the load balancer that sits at the edge of a lot of corporate networks — is now being actively targeted, days after a working exploit chain was published. If you run LoadMaster with the API enabled and haven’t patched to 7.2.63.2 / 7.2.54.18, treat this as urgent.

Key takeaways

• CVE-2026-8037 lets an attacker with no credentials run arbitrary commands, as root, on the LoadMaster appliance itself.
• The bug lives in a string-sanitisation helper (escape_quotes()) that allocated an uninitialised heap buffer and forgot to null-terminate it — a classic “small” memory bug that researchers at watchTowr Labs turned into full RCE.
• Progress patched it quietly on 4 June 2026. A public proof-of-concept and a detailed technical write-up landed on 29 June, and exploitation attempts started the same day.
• eSentire’s Threat Response Unit says the attempts it observed failed, but expects that to change now the exploit chain is public.
• No confirmed addition to the CISA KEV catalogue at time of writing — patch anyway, this appliance sits at your network edge.

What is CVE-2026-8037?

CVE-2026-8037 is a pre-authentication remote code execution vulnerability in Progress Kemp LoadMaster, a load balancer and application delivery controller (ADC) that many organisations run at the very edge of their network to distribute traffic across backend servers. Progress disclosed the flaw on 4 June 2026 as part of a June security bulletin, describing it plainly as a “Command Injection Remote Code Execution Vulnerability” reachable by an unauthenticated attacker. It was reported by researcher Syed Ibrahim Ahmed of TrendAI Research through Trend Micro’s Zero Day Initiative (tracked as ZDI-26-342).

The flaw only matters if LoadMaster’s API feature is switched on — but where it is, the impact is about as bad as it gets: full command execution on the appliance, no credentials needed. Because LoadMaster typically sits at the network perimeter with visibility into internal services, a compromised appliance is a highly attractive foothold for anything from ransomware crews to more patient, espionage-minded intruders.

It’s also the second Kemp LoadMaster flaw to see active exploitation in as many years, following CVE-2024-1212 (CVSS 10.0), another unauthenticated OS command injection bug in the same product line.

How the Kemp LoadMaster exploit works

In plain terms: LoadMaster has a function that’s supposed to make user input “safe” before stuffing it into a shell command, but the safety check had a bug that let attackers smuggle extra command data in from an adjacent, unrelated area of memory.

The mechanism, in more depth. LoadMaster’s /accessv2 API endpoint checks credentials by building and running a shell command with the apiuser and apipass values the caller supplied, via a helper called escape_quotes(). That helper’s job is to escape any single quotes in the input so an attacker can’t use one to “break out” of the quoted shell argument and inject their own commands.

Researchers at watchTowr Labs, who published a detailed technical breakdown on 29 June, found that the unpatched escape_quotes() had two separate small mistakes that combined into something serious: when it needed to build an escaped copy of the input, it allocated the new buffer with malloc() — which does not zero out the memory it hands back, so if that memory was previously used and freed by something else, it can still contain that old data — and it never wrote a terminating null byte (\0) at the end of the escaped string.

Normally this wouldn’t matter much. But because the escaped string has no guaranteed end marker, and the memory in front of it hasn’t been cleared, the C string-formatting call that builds the final shell command can keep reading straight past the end of the intended buffer — into whatever happens to be sitting in adjacent heap memory.

Attackers can influence what’s “adjacent” by heap-spraying: sending a JSON request body to /accessv2 stuffed with dozens of extra key/value pairs, each containing a shell metacharacter payload, so that one of those chunks lands right next to the apiuser buffer once it’s allocated. A carefully crafted apiuser value made of four single quotes then expands (through the same escaping logic) into exactly enough bytes to overwrite the allocator metadata at the start of that neighbouring chunk — clearing out the null bytes that would otherwise stop the read early. With that stopgap removed, the string-building function reads straight through into the attacker’s sprayed payload and appends it to the shell command, which LoadMaster then executes via system().

NON-OPERATIONAL, ILLUSTRATIVE ONLY — do not use to test production systems.
POST /accessv2 HTTP/1.1
Content-Type: application/json
{
  "cmd": "getall",
  "apiuser": "''''",
  "apipass": "<base64>",
  "g0":  "<padding>'; <injected command> #",
  "g1":  "<padding>'; <injected command> #",
  ... (many more padding/spray entries) ...
}

The end result: an unauthenticated POST request can cause LoadMaster to run an attacker-chosen shell command, as root, on the appliance.

Progress’s fix, released as GA 7.2.63.2 / LTSF 7.2.54.18, changes exactly two things in escape_quotes(): it swaps malloc() for calloc() (so the buffer is zero-filled rather than uninitialised) and adds the missing null terminator. Small patch, serious bug.

Is CVE-2026-8037 actively exploited?

Yes, in the sense that real exploitation attempts are confirmed — but full compromise via this flaw has not been publicly confirmed as of this post.

eSentire’s Threat Response Unit (TRU) reported that it began observing exploitation attempts against CVE-2026-8037 on 29 June 2026 — the same day the watchTowr technical write-up and a functional public PoC appeared. eSentire has published three attacker IP addresses associated with the activity (see IOCs below) and says the attempts it observed did not succeed, with no post-compromise activity identified. However, TRU explicitly assesses that further exploitation attempts are highly likely to increase now that a working exploit chain and PoC code are public.

As of this writing, ZeroDayHub has not found confirmation that CVE-2026-8037 has been added to CISA’s Known Exploited Vulnerabilities (KEV) catalogue. Given the pre-auth nature of the bug, the public PoC, and LoadMaster’s typical position at the network edge, we’d treat that as a “when, not if” for anyone running an unpatched, internet-facing instance.

How to fix CVE-2026-8037: remediation & mitigation

Patch: Upgrade to Kemp LoadMaster GA version 7.2.63.2 or LTSF version 7.2.54.18 — both fix the underlying escape_quotes() bug. This is the only complete fix.

If you can’t patch immediately:

• Disable the LoadMaster API feature if you don’t strictly need it — the vulnerability is only reachable when the API is enabled.
• Restrict network access to the LoadMaster management interface and /accessv2 endpoint to trusted, internal management networks only; never expose it directly to the internet.
• If a firewall or WAF sits in front of the appliance, block or closely monitor POST requests to /accessv2 with unusually large numbers of JSON keys or embedded single-quote sequences.
• Block the known attacker infrastructure listed below at your perimeter as an interim measure (note: attackers will rotate IPs, so this is not a substitute for patching).

After patching: Review LoadMaster access and system logs covering the period since 29 June 2026 for suspicious /accessv2 requests, unexpected outbound connections from the appliance, or unfamiliar processes/cron entries. If LoadMaster has visibility into internal services or holds credentials for other systems, treat a suspected compromise as a broader incident — rotate any secrets the appliance had access to and review connected systems for lateral movement.

Detection / IOCs: eSentire’s TRU has published the following attacker IP addresses observed in exploitation attempts as of 30 June 2026:

• 192.42.116.58
• 192.42.116.105
• 146.70.139.154

Frequently asked questions

Do I need to do anything if I don’t use LoadMaster’s API feature?
The published exploitation path requires the API to be enabled. If it’s off, you’re not exposed to this specific chain — but Progress still recommends patching, since the underlying code flaw exists regardless of whether the feature is switched on.

Is authentication required to exploit this?
No. CVE-2026-8037 is pre-authentication — the attacker needs no valid credentials, only network access to the /accessv2 endpoint.

Has this been used to deploy ransomware or steal data?
Not that has been publicly confirmed at time of writing. eSentire reports the exploitation attempts it observed failed, with no post-compromise activity. That could change quickly given the public PoC — this article will be updated if that happens.

How is this different from the 2024 Kemp LoadMaster vulnerability?
CVE-2024-1212 (CVSS 10.0) was also an unauthenticated OS command injection flaw in LoadMaster, exploited in the wild and added to CISA’s KEV catalogue. CVE-2026-8037 is a distinct, newer bug with a different root cause (uninitialised heap memory rather than the earlier flaw’s injection point), but the pattern — unauthenticated command injection in an edge load balancer — is strikingly similar.

Sources & further reading

• Progress: LoadMaster Critical Security Bulletin, June 2026 (CVE-2026-8037, CVE-2026-33691)
• watchTowr Labs: Enterprise Tech In, Shell Out — Kemp LoadMaster Uninitialized Heap to Pre-Auth RCE (CVE-2026-8037)
• Zero Day Initiative: ZDI-26-342
• eSentire TRU: Progress Kemp LoadMaster Vulnerability Targeted (CVE-2026-8037)
• The Hacker News: Progress Kemp LoadMaster Pre-Auth RCE Flaw Faces Active Exploitation Attempts
• The Hacker News: Progress Kemp LoadMaster Flaw Could Let Attackers Run Root Commands Pre-Auth
• CVE Record: CVE-2026-8037

ZeroDayHub tracks critical vulnerabilities as they break. Subscribe for updates.