VMware vCenter CVE-2026-59310: Deutschland am stärksten betroffen

VMware vCenter CVE-2026-59310, eine Path-Traversal-Schwachstelle mit einem CVSS-Wert von 9.8, wird aktiv in 47 Ländern ausgenutzt — und Deutschland ist von allen das mit Abstand am stärksten betroffene Land. Die deutsche Incident-Response-Firma QUIRSO deckte die Kampagne live während eines laufenden Einsatzes auf und verfolgte 361 einzelne Opfer-IP-Adressen zurück zu einer Directory-Traversal-Schwachstelle im vCenter-Syslog-Server, die Broadcom am 29. Juli patchte.

Was ist passiert

CVE-2026-59310 ist eine Directory-Traversal-Schwachstelle im Syslog-Server von VMware vCenter, von Broadcom am 29. Juli 2026 offengelegt (VMSA-2026-0006), CVSS v3.1 9.8. Ein Angreifer mit Netzwerkzugriff auf vCenter — ohne vorherige Authentifizierung — kann die Lücke ausnutzen, um Dateien außerhalb des vorgesehenen Verzeichnisses zu schreiben und letztlich beliebigen Code auf dem vCenter-Server auszuführen. Broadcoms Advisory nennt keinen Workaround: einziger Fix ist der Notfall-Patch.

Die Ausnutzung begann etwa am 3. August 2026, rund fünf Tage nach der öffentlichen Offenlegung. QUIRSOs Telemetrie, gesammelt während eines aktiven Incident-Response-Einsatzes, zählte 361 einzelne Opfer-IP-Adressen in 47 Ländern. Deutschland, die USA, die Türkei, der Iran und Frankreich stellen den größten Anteil kompromittierter Hosts — Deutschland steht an der Spitze dieser Liste. Die beobachtete Angriffskette ist über alle Opfer hinweg konsistent: Path-Traversal-Ausnutzung des Syslog-Dienstes, gefolgt vom Einsatz eines bösartigen Cron-Jobs, der reverse_ssh installiert — ein Open-Source-Tool, das einen ausgehenden SSH-Tunnel vom kompromittierten vCenter-Server zu einer vom Angreifer kontrollierten Infrastruktur öffnet. Da die Verbindung vom Opfer-Host ausgehend initiiert wird, übersteht sie rein eingehend ausgerichtete Firewall-Verteidigungen, die davon ausgehen, dass Angreifer von außen eindringen müssen statt selbst herauszutelefonieren. Konsistentes Tooling und wiederverwendete Infrastruktur über alle 361 Opfer hinweg deuten auf einen einzelnen, gut ausgestatteten Akteur hin statt auf opportunistische Trittbrettfahrer.

Warum das wichtig ist

vCenter ist die Verwaltungsebene für die Hypervisor-Schicht unter praktisch jedem anderen produktiven System, das ein mittelständisches Unternehmen betreibt — Fileserver, ERP-Anwendungshosts, VPN-Gateways, Backup-Infrastruktur und zunehmend auch das SIEM- und EDR-Tooling, das genau solche Eindringlinge eigentlich erkennen soll. Ein kompromittierter vCenter-Server exponiert nicht nur eine einzelne Workload, sondern den administrativen Kontrollpunkt für alle gleichzeitig — inklusive der Möglichkeit, virtuelle Festplatten im großen Stil zu klonen, zu exportieren oder zu löschen. Für deutsche Unternehmen unter NIS2 ist eine Hypervisor-Kompromittierung mit bestätigter unautorisierter Remote-Code-Ausführung genau die Vorfallsklasse, für die die 24-Stunden-Frühwarnung und die 72-Stunden-Meldepflicht der Regulierung geschaffen wurden — und Deutschlands Position als das in QUIRSOs eigenem Datensatz am stärksten betroffene Land lässt keine bequeme Annahme zu, dass „das nur ein US-Problem“ sei.

Was Sie jetzt tun sollten

1. Sofort patchen: Broadcoms VMSA-2026-0006-Fix auf jede vCenter-Server-Instanz anwenden — es gibt keinen unterstützten Workaround außer dem Patch.
2. Prüfen: vCenter-Syslog-Dienst-Logs auf Path-Traversal-Muster und unerwartete Cron-Job-Einträge prüfen; ausgehende SSH-Verbindungen vom vCenter-Host gegen bekannte Baselines abgleichen, da die reverse_ssh-Persistenz auf einem ausgehenden Tunnel beruht, den Ihre Egress-Filterung möglicherweise nicht überwacht.
3. Mitigieren als Zwischenlösung: Falls der Patch nicht sofort eingespielt werden kann, Netzwerkzugriff auf die vCenter-Management-Schnittstellen auf einen gehärteten Jump-Host/Bastion-Pfad beschränken und ausgehendes SSH vom vCenter-Host zu allem außerhalb einer strikten Allow-List blockieren.
4. Monitoring: Nach dem von QUIRSO und Shadowserver beschriebenen reverse_ssh-Cron-Persistenzmechanismus suchen und jeden vCenter-Host mit unerklärter ausgehender SSH-Aktivität bis zum Beweis des Gegenteils als kompromittiert behandeln.

Wenn ein Schritt oben heute nicht abgeschlossen werden kann, sagen Sie das Ihrem Team explizit, statt ihn als erledigt zu markieren — eine nur teilweise gepatchte vCenter-Flotte ist genau die Lücke, die eine solche Massen-Scanning-Kampagne sucht.

DIESEC Einschätzung

Dieses Muster sehen wir regelmäßig in Mittelstandsumgebungen: vCenter wird reaktiv für die Schwachstellen gepatcht, die Schlagzeilen machen, aber das eigene ausgehende Netzwerkverhalten des Hosts ist selten Teil derselben Überprüfung — genau die blinde Stelle, die eine Reverse-SSH-Persistenztechnik ausnutzen soll. Hypervisor-Management-Infrastruktur verdient dieselbe Monitoring-Sorgfalt wie ein Domain Controller, nicht die „läuft schon irgendwie“-Behandlung, die sie üblicherweise bekommt.

Nicht sicher, ob Ihre vCenter-Umgebung diese Lücke hat? Kontaktieren Sie DIESEC für eine schnelle Hypervisor-Expositions- und Traffic-Analyse.

Quellen: The Hacker News | BleepingComputer
Veröffentlicht: 2026-08-18 | Kategorie: Tägliche News | ~4 Min. Lesezeit