August 7, 2026 update: CISA added Progress LoadMaster CVE-2026-8037 to the Known Exploited Vulnerabilities Catalog and lists August 10, 2026 as the remediation due date for the federal directive. If your organization runs LoadMaster, treat that addition as a high-priority change signal: identify every appliance, reduce unnecessary management exposure, apply the supported Progress security release, and verify traffic and high-availability health before closing the change.
The vendor's LoadMaster security release notes identify CVE-2026-8037 as a command-injection remote-code-execution issue. This guide deliberately does not include vulnerability testing, diagnostic request details, or attack instructions. It is an operations checklist for owners of hardware, virtual, cloud, primary, standby, and recovery appliances.
Decide what needs attention first
Start with internet-facing or partner-reachable appliances and any LoadMaster instance that fronts sign-in, payment, customer portal, remote-access, or administrative applications. Include standby nodes, disaster-recovery sites, lab copies that mirror production, and management systems that can restore an older appliance image. An update is not complete if a vulnerable peer can later take over traffic.
Map each appliance to an owner, support entitlement, deployed branch, current firmware, HA role, maintenance window, and the applications it routes. Separate direct appliance administration from normal application traffic when reviewing exposure. Administrative access should be limited to the small, approved network path your operating model requires.
Plan a controlled security change
- Record the current appliance health, traffic role, HA synchronization state, customer impact window, and a responsible recovery contact.
- Use the vendor-supported process to preserve the configuration and confirm that the intended recovery path is available. This is an appliance-level recovery check, not a request to make a full hosting-account backup.
- Check the Progress advisory, model support, and release guidance for the branch that the appliance runs. The Progress 7.2.54.18 release notes document the fix; where a later supported release is appropriate, use the current supported release for that appliance rather than moving backward to an older line.
- For a high-availability pair, agree on traffic ownership, capacity, validation points, and a pause condition before beginning. Follow the vendor's HA guidance for the particular deployment rather than relying on a generic node order.
Progress documents its supported software update process, including firmware verification requirements. Obtain the update only through the approved Progress channel, retain the advisory and release evidence in the maintenance record, and keep unrelated platform upgrades out of the same urgent change unless they are required by the vendor.
Reduce exposure while the change is prepared
- Restrict administration to the approved management VPN, jump host, or private administrator network. Review firewall, provider, and routing policy for accidental broader access.
- Confirm that named administrators, support accounts, and emergency access match the current operating roster. Escalate unexpected accounts or configuration changes to incident response.
- Use monitoring and log review to establish a pre-change baseline for appliance health, administrative activity, and the applications behind the load balancer.
- Use any edge or WAF controls only as a temporary compensating measure where they are already owned and tested. They do not replace the vendor update or a management-access review.
Apply and validate the supported update
Perform the update in the approved window using the Progress process for the exact appliance model and branch. Keep the change narrow. After each planned transition, verify that the appliance reports the approved release, its HA state is healthy, and the intended node is serving traffic. Do not close the change on a version check alone.
- Test representative public application paths, authentication where applicable, and the services that depend on the appliance for routing or TLS handling.
- Confirm virtual services, back-end health, certificates, persistence behavior, monitoring, alerts, and HA synchronization are operating as intended.
- Review administrative activity and configuration history for the exposure period. Investigate unexplained changes rather than overwriting evidence during routine cleanup.
- Update the maintenance record with the affected assets, supported release, change window, post-change results, exceptions, and follow-up owner.
How to use the CISA KEV date
CISA's date is the directive deadline for the covered federal audience. Other organizations should not describe it as their own regulatory deadline, but it is still a useful urgency benchmark for risk owners. If an appliance cannot be updated immediately, document the system owner, exposure, temporary controls, review date, and escalation decision. A vague "pending maintenance" note is not an adequate exception for an edge appliance.
Related security maintenance
For another example of turning a CISA KEV addition into a production-safe maintenance record, read the Apache Tomcat CISA KEV patch checklist. Browse the FixItPhill security guides for platform-specific update, validation, and recovery guidance.
Authoritative references
- CISA Known Exploited Vulnerabilities Catalog
- Progress LoadMaster 7.2.54.18 security updates
- Progress LoadMaster software update documentation
Bottom line: CISA KEV status makes this an urgent LoadMaster maintenance item. Inventory every appliance and peer, apply the supported Progress update through a controlled change, confirm application and HA health, restrict administration to its intended network, and retain a clear record of any exception.
