DevOps 6 Min Lesezeit

VMware vCenter CVE-2026-59310: Ransomware-Gangs greifen zu – Newsflash September 2026

Es ist die Art von Meldung, die kein Administrator lesen will: Am 15. September 2026 bestätigte die US-Cybersecurity-Behörde CISA, dass Ransomware-Gangs begonnen haben, die kritische VMware-vCenter-Lücke CVE-2026-59310 aktiv auszunutzen. Der Bug mit dem maximalen CVSS-Score von 9.8 sitzt im vCenter-Syslog-Server, erfordert keinerlei Authentifizierung und erlaubt Angreifern mit Netzwerkzugriff die Ausführung beliebigen Codes. Wer sein vCenter bis heute nicht gepatcht hat, betreibt damit nicht nur ein Sicherheitsrisiko, sondern ein aktives Einfallstor für Verschlüsselungstrojaner — inklusive der Management-Plane für sämtliche ESXi-Hosts und virtuellen Maschinen.

Der Fall ist deshalb so brisant, weil die Zeit zwischen Patch-Veröffentlichung und Ransomware-Einsatz extrem kurz war: Broadcom lieferte den Fix bereits am 29. Juli 2026. Keine drei Wochen später stand die Lücke im KEV-Katalog von CISA, und seit Mitte September ist bestätigt, dass Babuk-abgeleitete Ransomware-Varianten über genau diesen Weg ESXi-Datastores verschlüsseln. Für Admins, die vSphere in Produktion betreiben, gibt es damit nur eine richtige Reihenfolge: erst patchen, dann alles andere.

Was ist passiert? Der News-Anlass im Detail

Die Ereigniskette begann mit einem Broadcom-Sicherheitsbulletin (VMSA-2026-0006), das am 29. Juli 2026 Fixes für mehrere kritische VMware-Lücken veröffentlichte. Darunter CVE-2026-59310, eine Directory-Traversal-Schwachstelle im Syslog-Server der vCenter Server Appliance (vCSA). Broadcom stufte sie als kritisch ein und empfahl in einem ergänzenden FAQ, die Behebung wie einen Notfall zu behandeln.

Am 18. August 2026 nahm CISA die Lücke in seinen Katalog der aktiv ausgenutzten Schwachstellen (Known Exploited Vulnerabilities Catalog) auf und setzte US-Bundesbehörden eine Frist von nur drei Tagen — bis zum 21. August — zur Absicherung ihrer vCenter-Systeme. Solche KEV-Fristen sind ein starkes Signal: Sie werden nur gesetzt, wenn eine Ausnutzung in freier Wildbahn nachgewiesen oder hochwahrscheinlich ist.

Der endgültige Weckruf kam dann am 15. September 2026: Wie unter anderem BleepingComputer unter Berufung auf CISA berichtete, sind inzwischen Ransomware-Banden zu den Angreifern gestoßen. Laut Analysen von Sicherheitsforschern, etwa im Gurucul-Blog, nutzen die Angreifer die Lücke, um über die Syslog-Komponente einzudringen, Persistenz zu etablieren und schließlich Babuk-abgeleitete Ransomware auf den ESXi-Hypervisoren zu deployen.

Die Lücke im Detail: Warum CVSS 9.8 hier kein Papierwert ist

CVE-2026-59310 ist eine Directory-Traversal-Schwachstelle im Syslog-Server von vCenter. Dieses Service nimmt normalerweise Log-Daten von verbundenen Hosts entgegen und speichert sie — und läuft dabei designbedingt mit erhöhten Privilegien. Die Kombination aus drei Eigenschaften macht die Lücke so gefährlich:

Keine Authentifizierung nötig: Ein Angreifer braucht weder Zugangsdaten noch eine aktive Session. Der Angriff erfolgt rein über das Netzwerk.
Direkte Code-Ausführung: Aus dem Path-Traversal lässt sich Remote Code Execution ableiten — ohne Interaktion eines Benutzers, ohne Phishing, ohne Social Engineering.
Maximale Hebelwirkung: vCenter ist die zentrale Management-Plane der Virtualisierungsumgebung. Wer hier Code ausführt, kontrolliert potenziell jeden verwalteten ESXi-Host und jede VM.

Genau diese Kombination — keine Credentials nötig, nur Netzwerkzugriff, Code-Ausführung mit hohen Rechten — ist das Muster, das aus einer Schwachstelle eine Ransomware-Lieferkette macht. Ein einzelner ungepatchter vCenter-Server kann Angreifern den Weg in hunderte virtuelle Maschinen gleichzeitig öffnen. Hinzu kommt ein Companion-Bug: CVE-2026-59309 betrifft dasselbe Syslog-Subsystem und wurde im selben Advisory behandelt.

Timeline: Vom Patch zur Ransomware-Welle

Datum	Ereignis
29. Juli 2026	Broadcom veröffentlicht Fixes (VMSA-2026-0006); vCenter-Builds 9.1.0.0300, 9.0.2.0100 und 8.0 U3k/U2f beheben die Lücke
30. Juli 2026	Öffentliche Berichterstattung über drei kritische VMware-Lücken
18. August 2026	CISA nimmt CVE-2026-59310 in den KEV-Katalog auf — Ausnutzung in freier Wildbahn bestätigt
21. August 2026	Remediation-Frist für US-Bundesbehörden (nur 3 Tage)
15. September 2026	CISA bestätigt: Ransomware-Gangs nutzen die Lücke aktiv aus

Bemerkenswert: Zwischen Patch und bestätigter Ransomware-Ausnutzung liegen nur rund sieben Wochen. Das ist deutlich schneller als bei früheren vCenter-Kampagnen und zeigt, wie professionell Angreifergruppen inzwischen Patch-Diffs auswerten und Exploits industrialisieren.

Betroffene Versionen und Fix-Builds

Betroffen sind alle gängigen vCenter-Versionslinien. Die folgende Tabelle fasst den Stand laut Broadcom-Advisory zusammen:

Produkt / Version	Status	Fix-Version
VMware vCenter 9.1.x.x	Betroffen	9.1.0.0300
VMware vCenter 9.0.x.x (inkl. Cloud Foundation / vSphere Foundation)	Betroffen	9.0.2.0100
VMware vCenter 8.0	Betroffen	8.0 U3k oder 8.0 U2f
VMware vCenter 7.0	Betroffen (nur Extended Support)	Nur über Broadcom-Support
VMware Cloud Foundation 5.x	Betroffen	Async-Patch auf 8.0 U3k

Wichtig: Laut Broadcom existiert kein Workaround. Patchen ist die einzige vollständige Behebung. Wer noch auf der 7.0-Linie unterwegs ist, kann nicht selbst patchen und muss sich direkt an den Broadcom-Support wenden — ein weiteres Argument, veraltete vSphere-Installationen zeitnah zu migrieren.

So gehen die Angreifer vor: Die Exploitation-Chain

Die dokumentierten Angriffe folgen einer mehrstufigen Kette, die exemplarisch zeigt, wie aus einer einzelnen Lücke ein vollständiger Ransomware-Vorfall wird:

Initial Access: Der Angreifer erreicht den Syslog-Service des vCenter über das Netzwerk und nutzt das Path-Traversal für Code-Ausführung — ohne Anmeldung.
Persistenz: Über die Komponente vmware-vpxd-stats-* wird ein SSH-Public-Key des Angreifers hinterlegt. Damit verschafft er sich dauerhaften Root-Zugriff, der auch Reboots übersteht.
Credential-Diebstahl: Aus der vCenter-Datenbank werden SSO- und Administrations-Credentials ausgelesen — der Angreifer kann sich damit legitim im gesamten vSphere-Umfeld bewegen.
Lateral Movement: Von vCenter aus werden die verwalteten ESXi-Hosts angegriffen und übernommen.
Verschlüsselung: Eine Babuk-abgeleitete Ransomware-Binary samt Hilfsskript (run.sh) fährt laufende VMs herunter, verschlüsselt VM-Disk-Dateien mit der Endung .babyk und deaktiviert den VMware-HA-Agent, um die Wiederherstellung zu erschweren.

Der letzte Punkt ist besonders perfide: Das Abschalten des HA-Agents verhindert, dass VMs automatisch auf andere Hosts migriert oder neu gestartet werden. Die Angreifer wollen nicht nur verschlüsseln, sondern die Wiederanlaufzeit maximieren — klassisches Ransomware-Playbook.

Was Admins jetzt tun müssen: Konkrete Handlungsempfehlungen

Wer vSphere betreibt, sollte die folgenden Schritte in dieser Reihenfolge abarbeiten:

1. Patch-Status prüfen und sofort patchen

Ermittle zunächst den installierten Build deines vCenter:

vpxd -v

Vergleiche das Ergebnis mit den Fix-Versionen aus der Tabelle oben. Falls dein Build älter ist: Patch ohne Rücksicht auf Wartungsfenster einspielen. Broadcom selbst hat die Behebung als Notfall eingestuft — bei bestätigter Ransomware-Ausnutzung gibt es keinen Grund zu warten.

2. Netzwerkzugriff auf das Management-Interface radikal einschränken

Solange ein Patch noch nicht eingespielt ist (oder als Defense-in-Depth-Maßnahme danach): Das vCenter-Management-Interface darf nur von einer minimalen Menge administrativer Hosts erreichbar sein. Ein vCenter, das aus einem allgemeinen VLAN oder gar aus dem Internet erreichbar ist, gilt als Notfall. Firewall-Regeln, Jump-Hosts und VPN-Zugang sind hier Pflicht, nicht Kür.

3. Auf Kompromittierungsindikatoren prüfen

Durchsuche die Syslog-Logs des vCenter nach verdächtigen Pfad- und Prozessmustern:

grep -Ei "\.\./|/etc/|/bin/sh|reverse" /var/log/vmware/vpxd-syslog/*.log

Prüfe außerdem die SSH-Authorized-Keys auf unbekannte Einträge, insbesondere im Kontext der Komponente vmware-vpxd-stats-*. Achte auf unerwartete Prozesse, neue Cron-Jobs und ungewöhnliche ausgehende Verbindungen.

4. Bei Verdacht: isolieren und Credentials rotieren

Bei einem Treffer gilt: vCenter sofort vom allgemeinen Netzsegment isolieren, forensische Sicherung erstellen und alle Credentials mit administrativem Zugriff rotieren — SSO-Administratoren, ESXi-Root-Accounts, Service-Accounts. Ein Angreifer mit Code-Ausführung im vCenter kann gespeicherte Credentials aus der internen Datenbank auslesen; wer nur das Passwort des einen sichtbaren Accounts ändert, hat nichts gewonnen.

5. Backups unabhängig prüfen

Da die Angreifer gezielt ESXi-Datastores verschlüsseln, ist die entscheidende Frage: Existieren aktuelle, offline oder unveränderlich (immutable) gespeicherte Backups, die nicht über vCenter-Credentials erreichbar sind? Wer seine Backup-Infrastruktur mit denselben administrativen Zugangsdaten betreibt wie vCenter, verliert im Ernstfall beides gleichzeitig. Prüfe auch, ob Backup-Jobs tatsächlich durchlaufen — und ob Restores getestet wurden.

Weitere Sicherheits-News im September 2026

Die vCenter-Welle ist nicht das einzige Ereignis, das Admins in diesem Monat auf dem Schirm haben sollten. Zwei weitere Entwicklungen verdienen Aufmerksamkeit:

Massenscanning auf exponierte Vite-Dev-Server

F5 Labs dokumentierte im August eine massive Scan-Kampagne gegen öffentlich erreichbare Vite-Entwicklungsserver (CVE-2026-39364, CVSS 7.5). Die Honeypots der Forscher registrierten rund 32.000 Scan-Events in 807 Angriffssessions — gegenüber nur 1.732 Events in den drei Monaten zuvor. Die Angreifer suchen gezielt nach .env-Dateien, AWS-Credentials, Azure-Tokens und Terraform-State-Files. Die Lektion: Entwicklungsserver gehören niemals ins offene Netz. Wer Vite mit --host oder falschen Docker-Port-Mappings exponiert, riskiert den Abfluss seiner Cloud-Zugangsdaten. Details finden sich im F5-Labs-Report.

Rekord-Patch-Tuesday mit 972 CVEs

Microsofts September-Patchday war der größte aller Zeiten: 972 CVEs, mehr als doppelt so viele wie im August (415), darunter 113 kritische Schwachstellen und zwei bereits aktiv ausgenutzte Zero-Days (CVE-2026-81963 im Windows Update Stack und CVE-2026-85880 im ALPC-Subsystem). Besonders kritisch für Server-Admins: unauthentifizierbare RCE-Lücken in Windows DNS Server (CVE-2026-69730, CVSS 9.8), DHCP Server (CVE-2026-69845 und CVE-2026-72979, beide 9.8) und Netlogon (CVE-2026-72982, 9.8). Die vollständige Analyse liefert CrowdStrike. Wer Windows-Server betreibt, sollte diesen Patchzyklus nicht auf die lange Bank schieben.

FAQ

Bin ich betroffen, wenn mein vCenter nicht aus dem Internet erreichbar ist?

Das reduziert das Risiko, eliminiert es aber nicht. Die dokumentierten Angriffe nutzen Netzwerkzugriff auf den Syslog-Service — dieser kann auch aus angrenzenden internen Netzen, kompromittierten Workstations oder über laterale Bewegung erreicht werden. Zudem zeigt die Erfahrung, dass exponierte Management-Interfaces oft durch Fehlkonfigurationen, VPN-Lücken oder vorgelagerte Systeme doch erreichbar sind. Die Empfehlung bleibt: patchen, unabhängig von der Netzwerktopologie.

Gibt es einen Workaround, wenn ich nicht sofort patchen kann?

Broadcom gibt in seinem Advisory explizit an, dass kein Workaround existiert. Als Übergangsmaßnahme kannst du den Netzwerkzugriff auf das vCenter-Management-Interface auf eine minimale Menge administrativer Hosts beschränken und den Syslog-Dienst beobachten. Das ist aber nur eine Risikoreduktion, keine Behebung — der Patch muss so schnell wie möglich folgen.

Woran erkenne ich, ob mein vCenter bereits kompromittiert ist?

Achte auf diese Indikatoren: unbekannte SSH-Keys (insbesondere im Umfeld von vmware-vpxd-stats-*), unerwartete Prozesse oder Cron-Jobs, auffällige Einträge in den Syslog-Logs (Pfad-Traversal-Muster wie ../), ungewöhnliche ausgehende Verbindungen sowie Dateien mit der Endung .babyk auf ESXi-Datastores. Bei einem Treffer: isolieren, forensisch sichern, Credentials rotieren und aus sauberen Backups wiederherstellen.

Müssen auch die ESXi-Hosts gepatcht werden?

Die Lücke selbst sitzt im vCenter, nicht im ESXi-Hypervisor. Allerdings ist vCenter der Schlüssel zu den Hosts: Wer vCenter kontrolliert, kann die verwalteten ESXi-Systeme angreifen und Ransomware darauf deployen. Deshalb gilt: vCenter patchen ist der erste Schritt, aber prüfe zusätzlich, ob deine ESXi-Hosts auf aktuellen Builds laufen und ob der SSH-Zugang zu den Hosts streng kontrolliert ist. Ein kompromittiertes vCenter mit schwachen Host-Credentials ist die perfekte Angriffskette.

Warum ist vCenter ein so beliebtes Ziel für Ransomware-Gangs?

Weil ein einziger erfolgreicher Angriff maximale Wirkung entfaltet. vCenter verwaltet potenziell hunderte VMs und alle ESXi-Hosts einer Umgebung. Wer hier eindringt, kann mit wenigen Befehlen die komplette Produktionslandschaft lahmlegen — und genau das ist das Geschäftsmodell von Ransomware: maximaler Schaden pro Kompromittierung. Die Historie zeigt das Muster: Bereits 2024 und 2025 gab es vCenter- und ESXi-Lücken (etwa CVE-2024-37079 oder die ESXi-Flaws CVE-2025-22225/22226), die in Ransomware-Kampagnen mündeten. vCenter bleibt damit dauerhaft eines der kritischsten Systeme im Rechenzentrum — und verdient einen Patch-Prozess, der schneller ist als der der Angreifer.