Progress Kemp LoadMaster — Pre-Auth RCE (CVE-2026-8037)

CVE-2026-8037 (CVSS 9.6) is a pre-authentication remote code execution flaw in the Progress Kemp LoadMaster load-balancing appliance. The root cause is an uninitialized-heap bug in the API's escape_quotes() routine: the function allocates a buffer with malloc() and never writes a null terminator, so when the escaped value is folded into a validuser command line via __sprintf_chk() and executed through system(), an attacker can read past the buffer into adjacent heap memory and inject shell metacharacters — yielding full root code execution with no credentials.

watchTowr Labs published a working exploitation analysis on 2026-06-29, and The Hacker News reported active exploitation attempts beginning the same day. The exploit is delivered as a single POST to the /accessv2 endpoint: an apiuser value of four single quotes overwrites allocator metadata, while dozens of padding JSON keys (g0–g60+) spray the heap so the injected command lands in the shell.

Highest-value defensive angle: LoadMaster is a network appliance — it does not run the Falcon sensor — so the primary detections live in ingested appliance access/syslog (the /accessv2 exploit body and any post-exploit shell/egress) plus network- and host-side telemetry on the Falcon-covered assets behind the load balancer. Patch to 7.2.63.2 and restrict API exposure first; hunt second.

Defender priority: Treat any internet-reachable LoadMaster on GA ≤ 7.2.63.1 / LTSF ≤ 7.2.54.17 with the API enabled as presumed-targeted. Patch or take the API off the perimeter today, then hunt the /accessv2 access logs for the heap-spray body and the appliance's egress for reverse-shell callbacks.

Intel note: No public atomic IOCs (attacker IPs, payload hashes, C2) were published at time of writing — exploitation is characterized by the request shape against /accessv2 and post-exploit behavior, not by fixed indicators. IOC blocks below use placeholders to be filled from local findings.

Hypotheses (fidelity-ordered)

1. H1 (high): An unauthenticated POST to /accessv2 carrying four single quotes in apiuser and repeated g0–g60+ padding keys is an exploitation attempt for CVE-2026-8037 — visible in ingested LoadMaster web/API access logs.
2. H2 (medium): A successfully exploited LoadMaster will spawn a shell (sh/bash) or fetch tooling (curl/wget) as a child of its web/API service — visible in appliance OS syslog/auditd if forwarded.
3. H3 (medium): A compromised appliance beacons or pulls a payload outbound to an unusual destination — visible in perimeter firewall/proxy logs as egress from the LoadMaster management IP to non-update destinations.
4. H4 (medium): Post-foothold, the actor pivots from the appliance to a backend/web host that is Falcon-covered, spawning recon or web-shell processes off the web-server parent.
5. H5 (medium): Pre-exploit reconnaissance shows a single source probing /accessv2 across multiple web-facing assets.

Attack chain

No vendor-published atomic IOCs at time of writing. The indicators below are behavioral / request-shape indicators derived from the watchTowr analysis; fill placeholder infrastructure values from local hunt findings.

Telemetry reality: the appliance itself is the blind spot. If LoadMaster access/syslog is not already shipped to NG-SIEM, stand that up (Section 13) — it converts H1–H3 from theoretical to live.

• LoadMaster WUI: System Configuration → Logging Options → review the API/access log for POST /accessv2 entries with abnormally large bodies or repeated keys.
• Version check: confirm running firmware against GA ≤ 7.2.63.1 / LTSF ≤ 7.2.54.17; anything at or below is vulnerable when the API is enabled.
• API exposure: confirm whether the RESTful API is enabled and whether the management/API interface is reachable from untrusted networks.
• Config drift: review LoadMaster admin users, SSH authorized keys, and cron/scheduled jobs for unauthorized additions (post-exploit persistence on the appliance).
• Perimeter: pull firewall logs for outbound sessions sourced from the LoadMaster management IP outside its normal update/NTP/DNS pattern.

The appliance is not Falcon-covered, so IOAs apply to the backend/pivot hosts (Q4). Promote the rest as Scheduled Searches over the ingested appliance repos.

Keep Q2 and Q5 as investigate-only hunts — their FP profile is environment-dependent and needs tuning before alerting.

No atomic IOCs published — the blocks below use REPLACE_WITH_… placeholders. Fill from confirmed local findings before importing.

type,value,action,severity,expiration,description,tags
ipv4,REPLACE_WITH_ATTACKER_SRC,detect,high,2027-01-02,CVE-2026-8037 exploit source,campaign:KempLoadMaster
domain,REPLACE_WITH_C2,detect,high,2026-10-02,LoadMaster reverse-shell C2,campaign:KempLoadMaster
sha256,REPLACE_WITH_TOOL_HASH,prevent,critical,2027-01-02,post-exploit tool pulled to appliance,campaign:KempLoadMaster

POST /accessv2 with apiuser value of four single quotes ('''')
POST /accessv2 body with repeated JSON keys g0..g60+
appliance web service spawning sh/bash/nc/curl/wget
outbound session from LoadMaster mgmt IP to non-update destination
web-server process spawning whoami/id/uname/curl on backend host

CVE: CVE-2026-8037 (CVSS 9.6)
Product: Progress Kemp LoadMaster (load balancer appliance)
Endpoint: /accessv2 (POST) — RESTful API
Root cause: uninitialized malloc() in escape_quotes(), missing null terminator
Chain: escape_quotes -> __sprintf_chk -> validuser -> system()
Primitive: four-quote apiuser + g0..g60+ heap spray

Fixed: LoadMaster 7.2.63.2 (malloc -> calloc + null termination)
Vulnerable: GA <= 7.2.63.1  |  LTSF <= 7.2.54.17  (when API enabled)
Audit: confirm firmware version in WUI (Home -> firmware)
Audit: confirm RESTful API enabled state and mgmt-interface reachability
Action: patch, then restrict API to trusted mgmt network only

A · Confirm version & API exposure (appliance CLI / WUI)

# In the LoadMaster WUI:
#   Home -> confirm firmware version (compare to GA 7.2.63.1 / LTSF 7.2.54.17)
#   Certificates & Security -> Remote Access -> confirm "Enable API Interface" state
#   System Configuration -> Interfaces -> confirm mgmt bound to non-Internet interface
# Any device at/below the vulnerable versions with API enabled = patch now.

B · Firewall egress allow-list for the appliance (illustrative iptables/edge policy)

# Replace 192.0.2.10 with the LoadMaster management IP.
# Permit only vendor-update / NTP / DNS egress; drop the rest (reverse-shell containment).
-A FORWARD -s 192.0.2.10 -p udp --dport 53  -j ACCEPT
-A FORWARD -s 192.0.2.10 -p udp --dport 123 -j ACCEPT
-A FORWARD -s 192.0.2.10 -d UPDATE_CIDR -p tcp --dport 443 -j ACCEPT
-A FORWARD -s 192.0.2.10 -j DROP

C · Stand up appliance log forwarding (syslog)

# LoadMaster WUI: System Configuration -> Logging Options -> Syslog Options
#   Set the SIEM collector as the Info/Notice/Warn/Error/Critical syslog target.
# Confirm ingestion, then point Q1/Q3 #repo at the parser that receives it.

Validation: the pack is only as strong as appliance log ingestion. Until LoadMaster access/syslog reaches NG-SIEM (Playbook C), Q1–Q3 are aspirational and the primary live coverage is Q4 on backend hosts plus §7 native WUI checks. Close the ingestion gap first.