CVE-2026-8037: Kritische Pre-Auth-RCE trifft Progress Kemp LoadMaster (jetzt patchen)

Eine kritische Schwachstelle in Progress Kemp LoadMaster, geführt als CVE-2026-8037, erlaubt es einem nicht authentifizierten Angreifer, per einer einzigen präparierten Anfrage an dessen API Befehle als Root auf dem Load Balancer auszuführen. Sie trägt einen CVSS-Score von 9.8, betrifft jeden LoadMaster-Build bis zum Juni-Patch und verfügt nun über einen öffentlichen Proof-of-Concept-Exploit — das Zeitfenster zwischen "theoretisch" und "wurmt sich durch Netzwerke" schließt sich also rasant. Wenn Sie einen LoadMaster mit aktivierter API betreiben, patchen Sie ihn noch heute.

Hier erfahren Sie, worum es bei dem Fehler geht, welche Versionen exponiert sind, wie der Exploit tatsächlich funktioniert und was zu tun ist, bevor jemand anderes Ihre Appliance findet.

Was ist CVE-2026-8037?

CVE-2026-8037 ist eine Schwachstelle zur Remote-Code-Ausführung vor der Authentifizierung in der LoadMaster-Management-API. Keine Zugangsdaten, keine Sitzung, keine Benutzerinteraktion — ein Angreifer, der den API-Endpunkt der Appliance erreichen kann, führt beliebige Shell-Befehle mit Root-Rechten aus. Da LoadMaster ein Application Delivery Controller ist, der üblicherweise am Netzwerkrand sitzt, TLS terminiert und Datenverkehr an Backend-Server lenkt, kommt eine Root-Shell darauf einem Worst-Case-Standbein sehr nahe.

Die Schwachstelle wurde der Zero Day Initiative von Trend Micro am 15. April 2026 vom Forscher Syed Ibrahim Ahmed gemeldet, und ZDI veröffentlichte sein koordiniertes Advisory am 9. Juni. Progress hatte bereits am 4. Juni einen Fix ausgeliefert. Der Grund, warum es jetzt Schlagzeilen macht: Am 29. Juni veröffentlichte watchTowr Labs eine vollständige technische Analyse mit einem funktionierenden Proof of Concept — und verwandelte damit einen N-Day, den viele Administratoren ignoriert hatten, in etwas, das jeder kompetente Angreifer nun reproduzieren kann.

Welche LoadMaster-Versionen sind betroffen?

Die Schwachstelle trifft beide Release-Kanäle, aber nur, wenn die LoadMaster-API aktiviert ist. Wenn Sie am oder nach dem 4. Juni gepatcht haben, sind Sie geschützt; wenn Sie das Gerät seit dem Frühjahr nicht angefasst haben, sind Sie mit ziemlicher Sicherheit exponiert.

Kanal	Betroffene Versionen	Gepatchte Version	Fix veröffentlicht
GA (General Availability)	v7.2.63.1 und früher	v7.2.63.2	4. Juni 2026
LTSF (Long-Term Support Feature)	v7.2.54.17 und früher	v7.2.54.18	4. Juni 2026

Die einzige mildernde Bedingung ist die API. Die REST-API von LoadMaster ist nicht in jedem Deployment standardmäßig aktiv, und Appliances mit deaktivierter API sind über diesen Fehler nicht erreichbar. Das ist die schnellste Methode, Ihre Exposition zu prüfen: Wenn die API aktiviert und aus dem Internet erreichbar ist, behandeln Sie das Gerät als kompromittiert-bis-gepatcht.

Wie der Exploit funktioniert

Der Fehler steckt in einer Hilfsfunktion namens escape_quotes(), deren einzige Aufgabe es ist, Benutzereingaben abzusichern, bevor sie an einen Shell-Befehl übergeben werden. Sie soll einfache Anführungszeichen escapen, damit ein Angreifer nicht aus einer in Anführungszeichen gesetzten Zeichenkette ausbrechen und eigene Befehle einschleusen kann. Stattdessen führte sie zwei subtile Speicherfehler ein, die diesen Schutz gemeinsam aushebeln.

Erstens allokierte die Funktion ihren Ausgabepuffer mit malloc() statt mit calloc(), sodass der Speicher uninitialisiert zurückkam — voll mit beliebigen Bytes, die vorher dort standen, einschließlich übrig gebliebener Heap-Daten. Zweitens fügte sie nach dem Schreiben der escapten Zeichenkette nie einen Null-Terminator hinzu, um das Ende der Zeichenkette zu markieren. Weiter unten liest __sprintf_chk() über das beabsichtigte Pufferende hinaus in benachbarten Heap-Speicher.

Dieses Über-Lesen ist der gesamte Exploit. Der Endpunkt /accessv2 verarbeitet einen JSON-Body mit den Feldern apiuser und apipass. Ein Angreifer sendet vier einfache Anführungszeichen in apiuser, die sich zu 16 escapten Bytes ausdehnen und Allokator-Metadaten in benachbarten freigegebenen Chunks überschreiben, während zusätzliche JSON-Schlüssel-Wert-Paare Befehls-Payloads über den Heap sprühen. Wenn der nicht terminierte Puffer gelesen wird, läuft er direkt in die gesprühte Payload, und der Befehl wird über den zugrunde liegenden system()-Aufruf ausgeführt — als Root. Der Fix von Progress ist genau das, was man erwartet: Umstellung auf calloc() für genullten Speicher und explizite Null-Terminierung der Zeichenkette.

Wird sie in freier Wildbahn ausgenutzt?

Stand 1. Juli 2026 gibt es keine bestätigte Ausnutzung in freier Wildbahn, und CVE-2026-8037 ist noch nicht im Known-Exploited-Vulnerabilities-Katalog der CISA gelistet. Doch das ist ein schwacher Trost. Die Spanne zwischen einem öffentlichen PoC und Massenscans wird inzwischen routinemäßig in Stunden bis Tagen gemessen, nicht in Wochen — Edge-Appliances werden von internetweiten Scannern fast unmittelbar nach Erscheinen eines Write-ups gefingerprinted. Eine CVSS-9.8-Pre-Auth-Root-RCE auf einem aus dem Internet erreichbaren Load Balancer, bei der bereits funktionierender Exploit-Code kursiert, ist genau das Profil, das Ransomware-Affiliates und Initial-Access-Broker um die Wette waffenfähig zu machen versuchen. Behandeln Sie "noch nicht ausgenutzt" als "noch nicht Ihre Runde".

Was Sie jetzt tun sollten

Die Behebung ist unspektakulär und dringend:

• Sofort patchen auf GA v7.2.63.2 oder LTSF v7.2.54.18 (oder neuer). Das ist der einzige echte Fix.
• Wenn Sie nicht auf der Stelle patchen können, deaktivieren Sie die LoadMaster-API oder beschränken Sie sie auf ein vertrauenswürdiges Management-Netzwerk. Der Fehler ist bei deaktivierter API nicht erreichbar, und sie sollte ohnehin niemals dem öffentlichen Internet ausgesetzt sein.
• Gehen Sie bei jedem Gerät, das ungepatcht und aus dem Internet erreichbar war, von einer Kompromittierung aus. Rotieren Sie die Zugangsdaten und TLS-Schlüssel, die die Appliance verarbeitet hat, und suchen Sie nach unerwarteten Prozessen, Cronjobs oder Konfigurationsänderungen — eine Root-Shell bedeutet, dass ein Angreifer sich hätte einnisten können, bevor Sie gepatcht haben.
• Segmentieren Sie Ihre Management-Ebene. Admin-APIs auf Edge-Appliances gehören hinter ein VPN oder einen Bastion-Host, nicht offen für alle Welt. Das ist dieselbe Lektion, auf die unsere Analyse Zero Trust vs. VPN immer wieder zurückkommt: Vertrauen Sie dem Netzwerkrand niemals standardmäßig.

Warum Edge-Appliances immer wieder die Schwachstelle sind

CVE-2026-8037 ist kein isolierter Ausrutscher — sie ist der jüngste Eintrag in einem Muster, das Unternehmens-Breaches seit drei Jahren prägt. Citrix NetScaler, Ivanti Connect Secure, Fortinet FortiOS, F5 BIG-IP: Die Geräte, die am Perimeter leben, individuelles C sprechen und selten neu gestartet werden, sind jene, die Angreifer am härtesten durchwühlen, weil ein einziger Fehler Pre-Auth-Root genau an dem Engpass liefert, an dem der gesamte Datenverkehr fließt. Load Balancer und Gateways sind uralte Codebasen in einer modernen Web-UI, und Speicherfehler wie dieser Uninitialized-Heap-Ausrutscher sind in diesem C-Unterbau endemisch.

Die defensive Lehre lautet nicht "kauf eine andere Appliance". Sie ist operativ: Inventarisieren Sie jedes Edge-Gerät und seine Firmware-Version, abonnieren Sie den Sicherheits-Feed des Herstellers, um an Tag null statt an Tag 25 von einem Fix zu erfahren, halten Sie Management-Schnittstellen aus dem öffentlichen Internet heraus und patchen Sie Edge-Geräte in einem schnelleren Takt als den Rest Ihrer Flotte. Die Organisationen, die von der npm-Supply-Chain-Krise und von jeder NetScaler-Welle davor kalt erwischt wurden, hatten dieselbe Grundursache — ein Patch existierte, und niemand spielte ihn rechtzeitig ein. LoadMaster reicht Ihnen den Patch drei Wochen früher. Nutzen Sie den Vorsprung.

Häufig gestellte Fragen

Wird CVE-2026-8037 aktiv ausgenutzt?

Stand 1. Juli 2026 wurde keine bestätigte Ausnutzung in freier Wildbahn gemeldet, und sie ist noch nicht im KEV-Katalog der CISA. Doch seit dem 29. Juni existiert ein funktionierender öffentlicher Proof of Concept, weshalb Ausnutzungsversuche gegen exponierte, ungepatchte Appliances als unmittelbar bevorstehend gelten sollten.

Woran erkenne ich, ob mein LoadMaster verwundbar ist?

Prüfen Sie Ihre LMOS-Version und ob die API aktiviert ist. GA-Builds v7.2.63.1 und früher sowie LTSF-Builds v7.2.54.17 und früher sind verwundbar, wenn die API aktiv ist. Ist die API deaktiviert, ist dieser konkrete Fehler nicht erreichbar.

Welche Version behebt sie?

Progress veröffentlichte den Fix am 4. Juni 2026: Aktualisieren Sie auf GA v7.2.63.2 oder LTSF v7.2.54.18 (oder neuer). Der Patch ersetzt die fehlerhafte Speicherallokation und fügt den fehlenden Null-Terminator hinzu.

Was kann ein Angreifer damit anrichten?

Beliebige Befehle als Root auf dem Load Balancer ausführen, ohne sich zu authentifizieren — vollständige Kontrolle über eine Appliance, die typischerweise TLS terminiert und internen Datenverkehr routet. Das macht sie zum Sprungbrett, um Datenverkehr abzufangen, ins interne Netzwerk zu pivotieren und Ransomware auszurollen.

Kann ich ohne Patch mitigieren?

Vorübergehend ja: Deaktivieren Sie die LoadMaster-API oder beschränken Sie sie auf ein vertrauenswürdiges Management-Netzwerk, damit der verwundbare Endpunkt /accessv2 nicht erreichbar ist. Das ist eine Notlösung — spielen Sie den offiziellen Patch so bald wie möglich ein.

Quellen

• watchTowr Labs — Enterprise Tech In, Shell Out (CVE-2026-8037): vollständige technische Analyse, Ursachenanalyse von escape_quotes() und der funktionierende Proof of Concept (29. Juni 2026).
• The Hacker News — Progress-Kemp-LoadMaster-Schwachstelle könnte Angreifern Pre-Auth-Root-Befehle ermöglichen: CVSS-Score, betroffene und gepatchte Versionen, Entdeckungs- und Offenlegungs-Zeitleiste.
• Progress — Advisory zu LoadMaster-Schwachstellen: offizielles Hersteller-Advisory und Anleitung zu behobenen Versionen.