CVE-2024-3544: Progress LoadMaster Auth Bypass Vulnerability

CVE-2024-3544 Overview

CVE-2024-3544 affects Progress LoadMaster deployments configured in High Availability (HA) or Cluster groups. Unauthenticated attackers on the same network segment as a cluster member can perform actions using SSH private keys. The flaw stems from partner communications relying on trust based only on IP address and network position, without any shared secret exchange. The vulnerability is categorized under [CWE-798] Use of Hard-coded Credentials. Progress Kemp addressed the issue by enhancing LoadMaster partner communications to require a shared secret between partners before communication can proceed.

Critical Impact
An adjacent-network attacker who reaches an HA or Cluster member can authenticate as a peer using SSH private keys and execute actions on the LoadMaster appliance, compromising confidentiality, integrity, and availability.

Affected Products

Progress LoadMaster (GA branch)
Progress LoadMaster LTS branch
Progress LoadMaster LTSF branch

Discovery Timeline

2024-05-02 - CVE-2024-3544 published to the National Vulnerability Database
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2024-3544

Vulnerability Analysis

Progress LoadMaster is an application delivery controller and load balancer that supports HA pairs and Cluster groups for redundancy. In vulnerable versions, cluster members trust peer communications based on network reachability rather than a cryptographic handshake. An attacker positioned on the same adjacent network as a LoadMaster node can impersonate a legitimate partner and use SSH private keys already trusted by the cluster to invoke privileged operations.

The root weakness is classified as [CWE-798] Use of Hard-coded Credentials, indicating that the SSH key material used for partner-to-partner authentication was shared or embedded in a manner that allowed reuse by any host reaching the management interface. Successful exploitation gives an attacker the same capabilities as a legitimate cluster peer.

Root Cause

The LoadMaster HA and Cluster communication channel accepted SSH-authenticated commands from any host that could reach a cluster member on the appropriate network, using key material that was not uniquely bound to individual partners. No pre-shared secret was required to establish that the peer was authorized to participate in the cluster.

Attack Vector

Exploitation requires network adjacency to an HA or Cluster member and knowledge of that member's IP address. The attacker uses the trusted SSH private key to connect to the partner interface and issue commands as a cluster peer. No user interaction is required, and no prior authentication to LoadMaster is needed, though attack complexity is elevated because the adversary must first gain access to the cluster's network segment.

See the Kemp Vulnerability Advisory for CVE-2024-3544 and CVE-2024-3543 for vendor technical details.

Detection Methods for CVE-2024-3544

Indicators of Compromise

Unexpected SSH sessions to LoadMaster HA/Cluster partner ports originating from hosts that are not registered cluster members.
Configuration changes, certificate updates, or administrative actions on LoadMaster with no corresponding operator activity in change-management records.
New or modified virtual services, real servers, or content rules appearing on one cluster node but not initiated by an authenticated administrator.

Detection Strategies

Baseline the source IP addresses of all inbound SSH connections to LoadMaster management and partner interfaces, then alert on any deviation.
Correlate LoadMaster audit logs with network flow data to identify partner-channel activity from hosts outside the approved cluster inventory.
Monitor for lateral movement into subnets that host LoadMaster HA or Cluster interfaces from workloads that have no operational reason to reach them.

Monitoring Recommendations

Forward LoadMaster syslog and SSH authentication events to a centralized SIEM and retain them long enough for retrospective hunting.
Segment the HA/Cluster synchronization network and monitor east-west traffic on that segment for unauthorized SSH sessions.
Alert on configuration drift between cluster members that cannot be tied to an authorized administrator action.

How to Mitigate CVE-2024-3544

Immediate Actions Required

Inventory all Progress LoadMaster appliances running in HA or Cluster configurations and identify the branch (GA, LTS, or LTSF) in use.
Upgrade each appliance to a fixed LoadMaster release that enforces the shared-secret partner handshake, as published by Progress Kemp.
Restrict access to the HA/Cluster synchronization interfaces to a dedicated management VLAN unreachable from user or server networks.
Rotate any SSH keys and cluster credentials after patching to invalidate material that may have been captured pre-patch.

Patch Information

Progress Kemp closed CVE-2024-3544 by modifying LoadMaster partner communications to require a shared secret that must be exchanged between partners before communication can proceed. Refer to the Kemp Vulnerability Advisory for CVE-2024-3544 and CVE-2024-3543 for the fixed version list applicable to the GA, LTS, and LTSF branches. Additional product information is available on the Kemp Technologies homepage.

Workarounds

Place LoadMaster HA and Cluster synchronization traffic on an isolated, non-routable management network with strict access control lists.
Apply host-based firewall rules on each LoadMaster node to accept partner-channel SSH connections only from known peer IP addresses.
Disable HA or Cluster mode on appliances that do not require it until the patched firmware can be deployed.

bash

# Example: restrict SSH partner traffic to known cluster peers only
# Replace 10.10.10.11 and 10.10.10.12 with actual cluster member IPs
iptables -A INPUT -p tcp --dport 22 -s 10.10.10.11 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -s 10.10.10.12 -j ACCEPT
iptables -A INPUT -p tcp --dport 22 -j DROP