LoadMaster in der KEV-Liste: Patch liegt seit Juni bereit

Am 7. August 2026 nahm die CISA mit CVE-2026-8037 genau eine neue Schwachstelle in den Known Exploited Vulnerabilities Catalog auf. Die Command-Injection in Progress Kemp LoadMaster ist seit Juni 2026 gepatcht. Ein Exploit liegt seit dem 29. Juni öffentlich vor. Die Frage für CISO und SOC-Leitung lautet, warum die eigene Priorisierung diese Lücke so lange nicht nach oben gezogen hat.

Verwandt: KEV nach BOD 26-04 – EPSS sortiert den Rest  ·  Windows-Lücken: Patch-Reihenfolge für kritische Assets

Was die KEV-Aufnahme am 7. August signalisiert

Was ist der KEV-Katalog? Der Known Exploited Vulnerabilities Catalog der CISA listet Schwachstellen mit belegter aktiver Ausnutzung. US-Bundesbehörden müssen Einträge innerhalb der genannten Frist nach Binding Operational Directive 26-04 beheben. Für Unternehmen und Behörden im DACH-Raum entsteht daraus keine eigene Rechtspflicht. Der Katalog bleibt dort ein priorisierbares Dringlichkeitssignal aus belastbarer Telemetrie und Behördenbewertung.

Am 7. August 2026 fügte die CISA dem KEV-Katalog genau einen neuen Eintrag hinzu: CVE-2026-8037 unter der Bezeichnung Progress LoadMaster Command Injection Vulnerability. Die dueDate im Eintrag lautet 2026-08-10. Drei Tage trennen Aufnahme und Frist. Für US-Bundesbehörden ist das eine verbindliche Vorgabe nach BOD 26-04. Für deutsche und österreichische Organisationen und für die Schweiz ist es ein priorisiertes Warnsignal ohne eigene Rechtswirkung.

Das Canadian Centre for Cyber Security hat sein Advisory AV26-552 am selben Tag um die KEV-Aufnahme ergänzt. Die parallele Aktualisierung zeigt, dass mehrere Behörden denselben Schwellenwert für öffentliche Eskalation erreicht sahen. Die CISA stuft knownRansomwareCampaignUse zugleich als Unknown ein. Das Feld erlaubt keine Verkürzung auf „keine Ransomware“.

Der eigentliche Befund für die eigene Steuerung liegt im Abstand. Der Herstellerpatch liegt seit dem 4. Juni 2026 vor. Der öffentliche Proof-of-Concept liegt seit dem 29. Juni 2026 vor. Die KEV-Aufnahme folgt erst am 7. August. Wer Patch-Queues nur über CVSS und Release-Fenster steuert, erkennt diesen Abstand zu spät. Wer Ausnutzbarkeit und Exposure früher gewichtet, hat die Lücke bereits im Juni an die Spitze gesetzt.

Der technische Angriffspfad auf LoadMaster

CVE-2026-8037 erlaubt einem unauthentifizierten Angreifer, über unsanitisierten Input an mehreren Command-Endpoints beliebige Befehle auf der LoadMaster-Appliance auszuführen. Der Pfad läuft über den API-Endpoint /accessv2, sofern die API aktiviert ist. Die Ursache liegt in der Funktion escape_quotes(). Es fehlt die Null-Terminierung. Daraus entsteht ein Heap-Out-of-Bounds-Read. Diese Kette beschreibt eSentire mit technischen Details von watchTowr Labs.

Bei erfolgreicher Ausnutzung laufen die injizierten Befehle als root. Gültige Credentials sind nicht erforderlich. LoadMaster sitzt typischerweise vor sensiblen Diensten und steuert den Verkehr. Eine root-Schale auf der Appliance ist deshalb kein isoliertes Host-Problem. Sie eröffnet den Weg in nachgelagerte Systeme und in Konfigurationen, die den Produktivverkehr steuern.

Betroffen sind Progress Kemp LoadMaster GA bis einschließlich 7.2.63.1 und LTSF bis einschließlich 7.2.54.17. Behoben sind 7.2.63.2 beziehungsweise 7.2.54.18. Diese Versionsspanne stammt aus der eSentire-Tabelle nach Herstellerstand vom 30. Juni 2026 und ist durch AV26-552 des Canadian Centre for Cyber Security bestätigt. Wer Asset-Inventare ohne Build-Stand und ohne API-Flag führt, kann den betroffenen Bestand nicht zuverlässig eingrenzen.

Die Schwerebewertung divergiert sichtbar. In der Berichterstattung und bei eSentire steht der CVSS-Score bei 9,6. Die Zero Day Initiative bewertet denselben CVE unter der Referenz ZDI-26-342 mit 9,8. Beide Werte beschreiben kritische Auswirkungen. Die Abweichung gehört in die Entscheidungsakte. Sie ersetzt jedoch nicht die Frage, ob die API erreichbar ist und ob der Patch-Stand stimmt.

Zeitstrahl: von der Meldung zur Behördenfrist

Die Zero Day Initiative meldete die Schwachstelle am 15. April 2026 an Progress. Am 4. Juni 2026 folgten Herstellerbulletin und CVE-Disclosure. Am 29. Juni 2026 erschien ein funktionsfähiger Proof-of-Concept. eSentire beobachtete Ausnutzungsversuche ab genau diesem Tag. Am 7. August 2026 nahm die CISA den CVE in den KEV-Katalog auf. Die Frist für US-Bundesbehörden endet am 10. August 2026.

Zwischen Disclosure und KEV liegen rund zwei Monate. Zwischen öffentlichem Exploit und KEV liegen knapp sechs Wochen. In diesem Fenster war der Patch verfügbar und der Angriffspfad öffentlich. Organisationen, die KEV als primären Trigger nutzen, handeln erst wenn die CISA den Eintrag setzt. Organisationen, die Herstellerfixes und Proof-of-Concept-Veröffentlichungen als eigene Trigger führen, haben den gleichen CVE bereits im Juni priorisiert.

Die kurze Frist von drei Tagen nach Aufnahme zeigt, wie die CISA die Lage für den eigenen Geltungsbereich bewertet. Sie verdichtet die Erwartung auf sofortige Remediation. Für DACH-Verantwortliche bleibt die Frist ein Maßstab für Dringlichkeit. Sie schafft keine eigene behördliche Deadline. Wer sie als alleiniges Signal liest, übernimmt die Logik des US-Bundesapparats und übersieht den früheren Handlungsraum.

Telemetrie: 792 Versuche und was sie nicht belegen

KEVIntel meldet 792 Ausnutzungsversuche in 41 Tagen von 65 eindeutigen IP-Adressen aus 18 Ländern. Genannt sind unter anderem Australien, China, Indonesien, Japan, Polen und die USA. Die letzte erfasste Aktivität lag am 4. August 2026 bei fünf Versuchen. Diese Zahlen beschreiben Scan- und Exploit-Versuche. Sie belegen keine erfolgreichen Kompromittierungen.

eSentire beobachtete Ausnutzungsversuche ab dem 29. Juni 2026, dem Tag der Proof-of-Concept-Veröffentlichung. In den von eSentire beobachteten Fällen war die Ausnutzung nicht erfolgreich. Es gab keine Post-Compromise-Aktivität. Diese Einschränkung muss jede Nennung der 792 Versuche begleiten. Wer die Zahl als Beleg für flächendeckende Übernahmen liest, verlässt die Quellenlage.

Für das SOC folgt daraus eine klare Trennung. Telemetrie zu Versuchen rechtfertigt erhöhte Detection und beschleunigtes Patchen. Sie ersetzt keine forensische Bestätigung eines Einbruchs. Gleichzeitig entlastet die bisherige Erfolglosigkeit in den eSentire-Fällen die Risikobewertung nicht dauerhaft. Der Pfad bleibt unauthentifiziert und endet bei Erfolg mit root. Ein später erfolgreicher Versuch ändert die Lage abrupt.

Die CISA belässt knownRansomwareCampaignUse bei Unknown. Auch hier gilt die strikte Lesart. Unknown heißt nicht widerlegt. Es heißt, dass die Behörde keine belastbare Zuordnung zu Ransomware-Kampagnen dokumentiert. Incident-Response-Pläne sollten LoadMaster-Kompromittierung deshalb weiterhin mit lateraler Bewegung und Datenabfluss modellieren. Eine Ransomware-Schiene darf weder unterstellt noch ausgeschlossen werden.

Was die Verzögerung über die eigene Priorisierung verrät

Der Fall CVE-2026-8037 entlarvt Steuerungslücken, die in vielen Patch-Programmen strukturell angelegt sind. Eine Lücke mit unauthentifizierter root-Ausführung auf einem Load Balancer hat hohe Asset-Kritikalität. Der Patch lag früh vor. Der öffentliche Exploit setzte einen klaren Zeitstempel. Trotzdem markiert erst die KEV-Aufnahme den Moment, in dem viele Organisationen den Vorgang als „wirklich dringend“ behandeln.

Drei typische Mechanismen erklären das Muster. Erstens: Priorisierung nur über CVSS ohne Exposure. Die Werte 9,6 und 9,8 signalisieren Schwere. Sie sagen nichts über die Erreichbarkeit von /accessv2 im eigenen Netz. Zweitens: Abhängigkeit von Behördenkatalogen als Startsignal. KEV ist ein starkes Signal. Es kommt nach der Phase, in der Angreifer den PoC bereits testen. Drittens: unvollständige Inventare zu Appliance-Builds und API-Status. Ohne diese Attribute bleibt die Lücke in der Queue unsichtbar.

Die Verzögerung der öffentlichen Eskalation ist damit kein Argument gegen KEV. Sie ist ein Argument für eine eigene Frühphase. Herstellerbulletin, CVE-Disclosure und öffentlicher Proof-of-Concept sind eigenständige Trigger. Wer sie mit Asset-Klasse und Internetnähe kombiniert, setzt LoadMaster-Fixes vor die KEV-Zeile. Wer wartet, kauft Zeit für Angreifer und verliert Steuerungszeit im Change-Fenster.

Für die Leitungsebene eignet sich eine knappe Prüfung. Wann ging der Patch in die Freigabe? Wann war der Bestand mit Build-Stand und API-Flag inventarisiert? Wann startete die Ausrollung? Liegt der Start erst nach dem 7. August, steuert das Programm zu stark über externe Kataloge. Liegt der Start bereits im Juni, hat die Organisation den Abstand zwischen Patch und KEV produktiv genutzt.

Handlungsrahmen für DACH-Verantwortliche

Zuerst gehört der Bestand in den Blick. Alle Progress Kemp LoadMaster-Instanzen sind gegen GA 7.2.63.2 und LTSF 7.2.54.18 zu prüfen. Parallel zählt der Status der API und die Erreichbarkeit von /accessv2 aus nicht vertrauenswürdigen Netzen. Systeme unter den genannten Maximalständen sind zu patchen. Systeme mit unnötiger API-Exposition brauchen eine Härtungsentscheidung, auch nach dem Fix.

Detection sollte die bekannten Versuchsmuster ab dem 29. Juni 2026 berücksichtigen. Die 792 erfassten Versuche und die fünf Versuche am 4. August 2026 markieren anhaltendes Scanning. In den eSentire-Beobachtungen blieb die Ausnutzung erfolglos und es folgte keine Post-Compromise-Aktivität. Trotzdem lohnt die Prüfung von Logs auf ungewöhnliche API-Aufrufe und unerwartete Prozessstarts auf der Appliance.

Die US-Frist 10.08.2026 gilt für US-Bundesbehörden nach BOD 26-04. Sie ist im DACH-Raum kein Rechtsbefehl. Sie ist ein Maß dafür, wie eng die CISA den verbleibenden Handlungsspielraum bemisst. Wer LoadMaster im Produktivpfad betreibt und den Patch noch nicht ausgerollt hat, sollte denselben Zeitdruck intern setzen. Die Begründung lautet Exposure und Exploit-Lage, nicht die US-Direktive selbst.

Abschließend gehört die Steuerungslogik auf den Prüfstand. KEV-Einträge bleiben Pflichtlesestoff. Sie dürfen nicht der einzige Eskalationshebel für internetnahe Appliances sein. Disclosure, Herstellerfix, PoC und Telemetrie zu Versuchen müssen früher greifen. CVE-2026-8037 zeigt diesen Ablauf in reiner Form: Patch früh, Exploit öffentlich, Ausnutzungsversuche über Wochen, KEV spät, Frist kurz, Ransomware-Nutzung Unknown.

Häufige Fragen

Jede Frage ist verschlossen. Ein Tippen entriegelt die Antwort.

Gilt die Frist 10.08.2026 auch für deutsche Unternehmen?

Nein. Die Remediation-Frist 2026-08-10 im KEV-Eintrag gilt für US-Bundesbehörden nach Binding Operational Directive 26-04. Im DACH-Raum ist sie ein Dringlichkeitssignal ohne eigene Rechtspflicht. Die operative Konsequenz ergibt sich aus Exposure und Ausnutzungslage, nicht aus der US-Direktive.

Bedeuten die 792 erfassten Aktivitäten erfolgreiche Angriffe?

Nein. KEVIntel zählt 792 Ausnutzungsversuche in 41 Tagen von 65 IP-Adressen aus 18 Ländern. eSentire beobachtete Versuche ab dem 29.06.2026. In den von eSentire beobachteten Fällen war die Ausnutzung nicht erfolgreich und es gab keine Post-Compromise-Aktivität. Die Zahl beschreibt Versuche. Belegte Kompromittierungen sind darin nicht enthalten.

Welche Versionen von Progress Kemp LoadMaster sind betroffen?

Betroffen sind GA bis einschließlich 7.2.63.1 und LTSF bis einschließlich 7.2.54.17. Behoben sind 7.2.63.2 beziehungsweise 7.2.54.18. Der Angriffspfad läuft über /accessv2, wenn die API aktiviert ist. Ursache ist escape_quotes() mit fehlender Null-Terminierung und einem Heap-Out-of-Bounds-Read.

Welcher CVSS-Wert gilt für CVE-2026-8037?

In der Berichterstattung und bei eSentire wird der Score mit 9,6 angegeben. Die Zero Day Initiative bewertet denselben CVE unter ZDI-26-342 mit 9,8. Beide Werte stehen nebeneinander. Die Abweichung ist real und sollte in der Risikodokumentation sichtbar bleiben.

Wird die Lücke in Ransomware-Kampagnen genutzt?

Die CISA stuft knownRansomwareCampaignUse für CVE-2026-8037 als Unknown ein. Das ist keine Aussage über ausgeschlossene Ransomware-Nutzung. Eine Verkürzung auf „keine Ransomware“ ist unzulässig. Die Bewertung bleibt offen, solange die Behörde keine andere Einstufung setzt.

Lesetipps der Redaktion

LesetippCERT-Bund zieht Zabbix-Warnung nach 24 Stunden zurückLesetippffmpeg steckt überall: PixelSmash zwingt zur InventurLesetippChainDrop: npm-Wurm trifft keyv und cacheable

Mehr aus dem MBF Media Netzwerk

cloudmagazinHerunterladbar heißt nicht betreibbarDigital ChiefsLocal AI: Governance vor dem HardwarekaufMyBusinessFutureIhre Cyberversicherung zahlt nicht – warum das kein Einzelfall ist

Bildquelle: KI-generiert (August 2026)