Fünf Wochen Angriffe, bevor die Warnung kam

Die Sicherheitsfirma watchTowr veröffentlichte am 29. Juni 2026 eine technische Analyse samt Proof-of-Concept für CVE-2026-8037, weniger als einen Monat nachdem Progress Software die Lücke am 4. Juni offengelegt hatte. Schon einen Tag später protokollierte das Threat-Response-Team von eSentire erste Angriffsversuche gegen Progress-Kemp-LoadMaster-Geräte, eine unauthentifizierte Command-Injection-Lücke mit einem CVSS-Wert von 9.6.

Als die US-Behörde CISA die Lücke am 7. August 2026 in ihren Known-Exploited-Vulnerabilities-Katalog aufnahm, zeigten die von eSentire und KEVIntel zusammengetragenen Telemetriedaten bereits 792 Angriffsversuche innerhalb von 41 Tagen, ausgehend von 65 einzelnen IP-Adressen aus 18 Ländern, darunter Australien, China, Indonesien, Japan, Polen und die USA. Die CISA setzte US-Bundesbehörden eine Frist bis zum 10. August 2026, gerade einmal drei Tage, um gemäß der Binding Operational Directive 26-04 zu patchen. Entscheidender als diese Drei-Tage-Frist war jedoch die Lücke von rund fünfeinhalb Wochen zwischen dem ersten realen Angriff und dem Moment, in dem eine KEV-Listung das Thema auf die Agenda der meisten Sicherheitsteams zwang.

Warum ein Load Balancer ein unterschätztes Ziel ist

Ein Load Balancer ist kein Randsystem. Er terminiert oder leitet in der Regel den Datenverkehr für jede öffentlich erreichbare Anwendung eines Unternehmens weiter, wodurch er über Netzwerksichtbarkeit und Routing-Kontrolle verfügt, die kaum ein anderes Gerät besitzt. Wer ihn kompromittiert, gewinnt einen Fuß in der Tür mit Sicht auf alles, was dahinterliegt, weit über den Ausfall einer einzelnen Website hinaus.

Trotz dieser Exposition werden Load Balancer und ähnliche Netzwerkgeräte routinemäßig langsamer gepatcht als die Webanwendungen, die sie absichern. Netzwerk- und Infrastrukturteams behandeln sie oft als Verkabelung, die einmal konfiguriert außerhalb geplanter Wartungsfenster nicht angerührt werden soll. Genau diese Gewohnheit macht eine unauthentifizierte Remote-Code-Execution-Lücke wie CVE-2026-8037 so gefährlich: Das dem Internet am stärksten ausgesetzte Gerät ist häufig jenes, das am wenigsten im Notfallmodus gepatcht wird.

Die Lücke im Detail: Eine Bereinigungsfunktion, die nicht bereinigt

CVE-2026-8037 steckt in einer Funktion namens escape_quotes, deren Aufgabe es ist, gefährliche Zeichen aus Benutzereingaben zu entfernen, bevor diese an einen Shell-Befehl weitergereicht werden. Die Funktion tut dies nicht vollständig, und die Lücke ist über den API-Endpunkt /accessv2 erreichbar, sobald die LoadMaster-API aktiviert ist. Ein Angreifer benötigt dafür keinerlei Zugangsdaten; eine speziell präparierte Anfrage genügt, damit das Gerät beliebige Befehle ausführt.

Betroffen sind LoadMaster GA-Version 7.2.63.1 und älter sowie LoadMaster LTSF-Version 7.2.54.17 und älter. Progress Software bestätigte zudem denselben zugrunde liegenden Fehler in MOVEit-WAF-Builds vor GA 7.2.63.2. Korrigierte Versionen stehen bereit: LoadMaster GA 7.2.63.2 und LoadMaster LTSF 7.2.54.18. Es gibt keinen Ersatz für das Einspielen dieser Patches; das Deaktivieren der API, wo sie nicht benötigt wird, verringert die Angriffsfläche, schließt die Lücke aber nicht für Umgebungen, die auf sie angewiesen sind.

Warum das ein NIS2-Auslöser ist, kein reines Patch-Ticket

Für Organisationen, die unter der EU-Richtlinie NIS2 als wesentliche oder wichtige Einrichtung eingestuft sind, ist eine unauthentifizierte Remote-Code-Execution-Lücke auf einem internetseitigen Infrastrukturgerät nahezu ein Lehrbuchbeispiel dessen, wofür die Meldepflichten der Richtlinie geschrieben wurden. Ein Load Balancer am Netzwerkrand, ohne Zugangsdaten erreichbar und nachweislich unter aktivem Angriff, erfüllt praktisch jedes Kriterium, das Aufsichtsbehörden wie das deutsche BSI zur Definition eines erheblichen Sicherheitsvorfalls heranziehen: eine Beeinträchtigung von Vertraulichkeit, Integrität oder Verfügbarkeit mit dem Potenzial für erheblichen betrieblichen oder finanziellen Schaden.

Das hat eine praktische Konsequenz über das reine Patchen hinaus. War ein unter NIS2 fallendes LoadMaster-Gerät während des Angriffsfensters internetseitig erreichbar und lief eine verwundbare Version, läuft die Meldefrist womöglich bereits, unabhängig davon, ob eine Kompromittierung bislang bestätigt wurde. Auf forensische Gewissheit zu warten, bevor die Meldepflicht geprüft wird, ist ein verbreiteter und teurer Fehler.

Was Betreiber diese Woche tun sollten

Wer ein Kemp-LoadMaster-Gerät mit GA 7.2.63.1 oder älter beziehungsweise LTSF 7.2.54.17 oder älter betreibt, sollte sofort patchen und internetseitige Instanzen priorisieren. Auf ein geplantes Wartungsfenster zu warten, ist keine Option; die Angriffstelemetrie zeigt, dass Angreifer bereits breit und wahllos scannen, wodurch ungepatchte Geräte durch automatisierte Scans gefunden werden.

Über diesen einen Fix hinaus lohnt es sich, die fünfwöchige Lücke zwischen erstem Angriff und KEV-Listung zum Anlass zu nehmen, zu überprüfen, wie das eigene Unternehmen Herstellerhinweise speziell für Netzwerk- und Infrastrukturgeräte verfolgt, eine Kategorie, die Patch-Programme rund um Anwendungssoftware oft übersehen. Ein Patch-Management-Programm, das erst eskaliert, sobald etwas auf einer staatlichen Liste ausgenutzter Schwachstellen erscheint, liegt per Definition immer hinter den Angreifern, die die Lücke zuerst gefunden haben.

Weiterlesen: 45.601 Lücken, 171 werden wirklich genutzt  |  Ein totes Gebäude kostet mehr als ein Lösegeld