Progress Kemp LoadMaster Command Injection Under Active Exploitation — CISA KEV Alert, Detection & Remediation Guide

CISA has issued an urgent warning: a critical-severity command injection vulnerability in Progress Kemp LoadMaster is being actively exploited in the wild. This is not a theoretical exposure or a researcher proof-of-concept — threat actors are using this flaw against real organizations, and it has been added to CISA's Known Exploited Vulnerabilities (KEV) catalog, which carries mandatory remediation timelines for federal agencies and serves as a de facto triage priority for every enterprise SOC.

Load balancers and application delivery controllers (ADCs) occupy one of the most sensitive positions in your architecture. They terminate TLS, route production traffic, sit in front of authentication infrastructure, and — critically — are frequently excluded from EDR coverage because they are network appliances. A successful compromise of a LoadMaster gives an attacker a durable, low-visibility foothold at the exact chokepoint where your most sensitive traffic flows. If you run LoadMaster in any capacity — hardware, virtual, or bare-metal — treat this as an incident, not a patch ticket.

Technical Analysis

What Is Affected

Progress Kemp LoadMaster is a widely deployed application delivery controller and load balancer available as a hardware appliance, virtual appliance (VLM), and bare-metal install. It is used extensively in mid-market and enterprise environments to front-end Exchange, SharePoint, RDS, and line-of-business web applications — which means a disproportionate share of deployments sit directly in the DMZ with management interfaces that are, in practice, more exposed than administrators realize.

The Vulnerability

The flaw is an unauthenticated command injection in the LoadMaster management plane. From a defender's perspective, the attack chain looks like this:

1. Reconnaissance: The attacker scans for internet-exposed LoadMaster web management interfaces (commonly on TCP 443/8443) using fingerprinting of the Kemp UI login page and banner artifacts. Shodan and Censys make this trivial.
2. Injection: A crafted HTTP request to a vulnerable management endpoint smuggles operating system commands through an input field or parameter that is passed unsanitized to an underlying shell invocation in the appliance's command execution framework.
3. Execution: Injected commands execute with the privileges of the appliance's web/management service — on LoadMaster, this frequently means root-equivalent context on the appliance OS.
4. Post-exploitation: Typical follow-on activity for appliance compromises includes establishing outbound reverse shells or beaconing, harvesting configuration and credentials (ADC configs often contain service account credentials and TLS private keys), modifying traffic flow for interception, and using the appliance as a pivot into the backend server VLANs it load-balances.

Command injection on a management plane is dangerous precisely because it requires no credentials, no user interaction, and no prior access. The only mitigating factor is whether your management interface is reachable from the internet or a flat internal network — and in every IR engagement we run involving network appliances, we find management planes that are reachable from far more of the network than the asset owner believed.

Exploitation Status

• Confirmed active exploitation in the wild — this is the reason for the CISA warning.
• Listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, which for federal civilian agencies triggers a binding remediation deadline under BOD 22-01. Private-sector organizations should treat the same timeline as their SLA.
• Network appliance flaws of this class are historically adopted quickly by both ransomware initial access brokers and espionage actors. Expect scanning and exploitation volume to increase, not decrease.

Detection & Response

This is a technical, actively exploited threat. The detection content below is built around the observable behaviors of command injection exploitation against an ADC: web service processes spawning shells, anomalous outbound connections from the appliance, and post-exploitation tooling on adjacent hosts.

Sigma Rules

---
title: LoadMaster or ADC Web Service Spawning Shell Processes
id: 8f2c1a94-3d67-4b58-ae91-2c4d6f8a0123
status: experimental
description: Detects command injection behavior on Linux/FreeBSD-based network appliances where the web management daemon spawns shell or command execution processes, consistent with exploitation of the Progress Kemp LoadMaster command injection flaw.
references:
  - https://www.bleepingcomputer.com/news/security/cisa-warns-of-critical-progress-loadmaster-flaw-exploited-in-attacks/
  - https://attack.mitre.org/techniques/T1059/
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
  - attack.execution
  - attack.t1059.004
logsource:
  category: process_creation
  product: linux
detection:
  selection_parent:
    ParentImage|contains:
      - '/httpd'
      - '/nginx'
      - '/apache'
      - '/lighttpd'
  selection_child:
    Image|endswith:
      - '/sh'
      - '/bash'
      - '/dash'
      - '/csh'
      - '/tcsh'
      - '/python'
      - '/perl'
      - '/wget'
      - '/curl'
      - '/nc'
      - '/ncat'
  condition: selection_parent and selection_child
falsepositives:
  - Appliance maintenance scripts invoked through legitimate admin UI actions (firmware updates, diagnostics bundles)
level: high
---
title: Network Appliance Initiating Outbound Connection to Rare External Host
id: 3b7e5d12-8f49-4a2c-bd65-9e1a3c7f2048
status: experimental
description: Detects load balancer or ADC management interfaces initiating outbound connections to external destinations, a strong indicator of post-exploitation reverse shell or beaconing activity following command injection compromise.
references:
  - https://attack.mitre.org/techniques/T1071/
  - https://attack.mitre.org/techniques/T1572/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.command_and_control
  - attack.t1071.001
logsource:
  category: firewall
detection:
  selection:
    DeviceVendor|contains:
      - 'Kemp'
      - 'Progress'
    Initiated: 'true'
    IsDestinationIPPublic: 'true'
  filter_update:
    DestinationIp|cidr:
      - '8.8.8.0/24'
      - '1.1.1.0/24'
  condition: selection and not filter_update
falsepositives:
  - Firmware/license update checks to Progress update servers (baseline and allowlist known update endpoints)
  - NTP and DNS if routed through the appliance management interface
level: medium

KQL — Microsoft Sentinel / Defender

LoadMaster appliances do not run Defender for Endpoint, so hunt this through your perimeter telemetry: firewall logs, syslog ingestion, and web proxy data. This query looks for the exploitation pattern at the network layer — inbound requests to the management interface followed by outbound appliance-initiated sessions.

// Hunt: Outbound connections originating from LoadMaster/ADC appliances
// Assumes firewall syslog is ingested via CommonSecurityLog (CEF) or Syslog
// Adjust SourceIP to your LoadMaster management IPs or tag them in a watchlist
let LoadMasterIPs = _GetWatchlist('adc-appliances') | project WatchlistItem;
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where SourceIP in (LoadMasterIPs)
| where DestinationIP !startswith "10." and DestinationIP !startswith "172.16." and DestinationIP !startswith "192.168."
| where IsIPPublic(DestinationIP)
| summarize FirstSeen=min(TimeGenerated), LastSeen=max(TimeGenerated), ConnectionCount=count(), Ports=make_set(DestinationPort)
  by SourceIP, DestinationIP, DestinationHostName
| extend Verdict = iff(ConnectionCount > 50 and FirstSeen > ago(2d), "Suspect - new high-volume egress from ADC", "Review")
| sort by FirstSeen asc;
// Secondary: web requests hitting the LoadMaster management interface with suspicious payloads
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DestinationIP in (LoadMasterIPs)
| where RequestURL has_any ("cmd=", "exec", "%3B", "|", "$(", "`/", "bash", "curl", "wget", "nc+")
| project TimeGenerated, SourceIP, DestinationIP, RequestMethod, RequestURL, SourceUserAgent
| sort by TimeGenerated desc;

Velociraptor VQL

The appliance itself typically cannot host Velociraptor, but the moment an ADC is compromised, attackers pivot to the backend servers it front-ends. Hunt the Windows/Linux servers in the load-balanced pool for shells spawned by service accounts and unexpected egress — the classic signature of a pivot from the perimeter device.

-- Hunt backend pool servers for post-compromise shells and pivots
-- following ADC exploitation: service accounts spawning shells,
-- and processes with outbound connections to rare external IPs
SELECT Pid, Ppid, Name, Exe, CommandLine, Username, CreateTime
FROM pslist()
WHERE (
  (Username =~ 'IIS APPPOOL|NETWORK SERVICE|SYSTEM|www-data|nginx|apache')
  AND (Name =~ 'cmd.exe|powershell.exe|pwsh|bash|sh$|python|nc.exe|ncat')
)
OR (
  CommandLine =~ 'curl|wget|invoke-webrequest|certutil|bash -i|/dev/tcp/'
  AND Name !~ 'msiexec|svchost|update'
)
ORDER BY CreateTime DESC

Remediation & Verification Script

Run this from a management workstation with API/SSH access to your LoadMaster estate to inventory versions, verify management-plane exposure, and check logs for injection artifacts.

#!/bin/bash
# LoadMaster Compromise Triage & Hardening Script
# Run from a jump host with network access to appliance management interfaces

APPLIANCES="lm01.corp.local lm02.corp.local"   # Replace with your LoadMaster hostnames/IPs
ADMIN_USER="bal"
EVIDENCE_DIR="./lm_triage_$(date +%Y%m%d)"
mkdir -p "$EVIDENCE_DIR"

echo "=== Step 1: Inventory firmware versions via LoadMaster REST API ==="
for host in $APPLIANCES; do
  echo "--- $host ---"
  # The REST API 'get' endpoint returns firmware/build info
  curl -sk -u "$ADMIN_USER" "https://$host/access/get?param=version" \
    | tee "$EVIDENCE_DIR/${host}_version.txt"
done
# ACTION: Compare output against the fixed build listed in the Progress security advisory.
# Any build below the vendor-fixed version is VULNERABLE and must be patched immediately.

echo "=== Step 2: Check management interface exposure ==="
# Confirm the WUI is NOT reachable from untrusted networks.
# From an EXTERNAL vantage point, this should FAIL or time out:
#   curl -sk --max-time 5 https://<your-public-ip>:443  (look for Kemp UI banner)
# Also audit firewall policy for any permit rule targeting appliance mgmt IPs from 0.0.0.0/0

echo "=== Step 3: Pull logs for injection indicators ==="
for host in $APPLIANCES; do
  ssh "$ADMIN_USER@$host" 'cat /var/log/user_log 2>/dev/null; cat /var/log/message* 2>/dev/null' \
    > "$EVIDENCE_DIR/${host}_logs.txt" 2>/dev/null
  # Look for: unexpected command strings, shell metacharacters in request contexts,
  # curl/wget/nc references, and connections to unknown external IPs
  grep -iE 'curl|wget|/bin/sh|/bin/bash|nc -|; *cat |\$\(|`.*`|python -c' \
    "$EVIDENCE_DIR/${host}_logs.txt" > "$EVIDENCE_DIR/${host}_SUSPECT.txt"
done

echo "=== Step 4: Review established outbound connections on the appliance ==="
for host in $APPLIANCES; do
  ssh "$ADMIN_USER@$host" 'netstat -an 2>/dev/null | grep -i estab' \
    | tee "$EVIDENCE_DIR/${host}_netstat.txt"
  # Any ESTABLISHED session from the appliance to an unrecognized public IP = escalate to IR
done

echo "Triage evidence collected in $EVIDENCE_DIR — preserve before patching."

Remediation

Given confirmed active exploitation and KEV listing, sequence your response in this order — do not wait for a maintenance window to do steps 1 and 2:

1. Confirm exposure immediately. Determine whether any LoadMaster management interface (Web User Interface / WUI, REST API endpoints, SSH) is reachable from the internet or from user/server segments. Check public IP space, NAT rules, and cloud security groups. If you find an internet-exposed management plane, treat the appliance as potentially compromised until proven otherwise — do not just patch and move on.
2. Isolate the management plane. Restrict WUI/API access to a dedicated management VLAN or jump host via firewall ACL. This is a permanent architectural control, not a temporary workaround — no ADC management interface should ever be broadly reachable.
3. Apply the vendor fix. Patch to the LoadMaster firmware build specified in the official Progress security advisory (available via the Progress customer portal and the Progress Kemp security advisories page — https://support.kemptechnologies.com/ and the Progress security vulnerability disclosures). Verify the build number post-upgrade; do not rely on the update job reporting success.
4. Meet the KEV deadline. CISA's KEV listing carries a binding remediation due date for federal civilian agencies (typically three weeks from listing for newly added CVEs). Every organization should hold itself to the same clock. If you cannot patch within that window, take the affected appliances' management interfaces offline from any untrusted reachability until you can.
5. Hunt before and after patching. Patching closes the hole; it does not evict an attacker who got in last month. Run the detection content above against at least 30 days of retained firewall, proxy, and appliance logs. Rotate any credentials stored in or transiting the LoadMaster (service accounts, RADIUS/shared secrets, LDAP bind accounts) and reissue TLS private keys if compromise cannot be ruled out.
6. Assume lateral movement. The appliance routes traffic to your most critical application servers. If triage surfaces any evidence of exploitation, extend the IR scope to every host in the load-balanced pools and review authentication logs for anomalous service account use.
7. Close the telemetry gap. Forward LoadMaster syslog (WUI logs, system logs) to your SIEM permanently. An appliance you cannot log is an appliance you cannot defend.

The Bigger Lesson

This campaign follows a pattern we've watched accelerate through 2025 and into 2026: perimeter and edge devices — ADCs, VPN concentrators, firewalls, mail gateways — have become the preferred initial access vector precisely because they are powerful, internet-facing, and blind to EDR. Every one of these devices in your estate needs three things: a management plane that is architecturally unreachable from untrusted networks, log forwarding into your SIEM, and an entry in your vulnerability management program with KEV-driven SLAs. If LoadMaster is in your rack, this week's work is the patch and the hunt. Next quarter's work is making sure the next appliance CVE doesn't start with the same scramble.

Related Resources

Security Arsenal Managed SOC Services AlertMonitor Platform Book a SOC Assessment soc-mdr Intel Hub