Kritische vCenter-Lücke CVE-2026-59310 wird aktiv ausgenutzt

Veröffentlicht am 17.08.2026

Fünf Kalendertage. So lange dauerte es, bis nach der Veröffentlichung eines VMware-Sicherheitsupdates die ersten kompromittierten Server Kontakt zu ihren Angreifern aufnahmen. Broadcom stellte am 29. Juli 2026 einen Patch für eine kritische Lücke im vCenter-Server bereit – am 3. August 2026 begannen bereits die ersten übernommenen Systeme, ausgehende Verbindungen zur Angreiferinfrastruktur aufzubauen. Inzwischen dokumentieren Sicherheitsforscher eine aktive Angriffskampagne mit Hunderten betroffenen IP-Adressen weltweit, und Deutschland gehört zu den fünf am stärksten betroffenen Ländern.

Wenn Sie selbst VMware vCenter betreiben oder Ihr Hosting- oder IT-Dienstleister diese Software für Ihre Systeme einsetzt, sollten Sie jetzt handeln. In diesem Artikel erklären wir verständlich, was passiert ist, wie Sie prüfen, ob Sie betroffen sind, und was Sie konkret tun müssen.

Was ist passiert?

Die Schwachstelle trägt die Kennung CVE-2026-59310 (CVE steht für „Common Vulnerabilities and Exposures“ – ein weltweit eindeutiges Kennzeichen für Sicherheitslücken). Sie steckt im sogenannten Syslog-Server von VMware vCenter. vCenter ist die zentrale Verwaltungssoftware, mit der Unternehmen ihre virtuellen Server und Rechenzentren steuern – gewissermaßen die Kommandozentrale einer VMware-Umgebung.

Broadcom, der Hersteller von VMware, stuft die Lücke als kritisch ein und bewertet sie mit einem CVSS-Wert von 9,8 von 10 möglichen Punkten. CVSS („Common Vulnerability Scoring System“) ist ein standardisiertes Bewertungssystem für die Schwere von Schwachstellen; Werte ab 9,0 gelten als kritisch. Der offizielle Bewertungsvektor beschreibt einen Angriff, der über das Netzwerk erfolgt, technisch einfach durchzuführen ist und weder eine vorherige Anmeldung noch eine Benutzerinteraktion voraussetzt.

Broadcom fasst die Gefahr in der Sicherheitsberatung VMSA-2026-0006.1 klar zusammen:

„A malicious actor with network access to vCenter may exploit this issue to execute arbitrary code.“ – Broadcom, VMSA-2026-0006.1

Übersetzt: Ein Angreifer mit Netzwerkzugriff auf vCenter kann die Lücke ausnutzen, um beliebigen Programmcode auszuführen. Das bedeutet im schlimmsten Fall die vollständige Übernahme der Verwaltungsebene – und damit potenziell Kontrolle über die gesamte virtualisierte Umgebung.

Der technische Hintergrund – verständlich erklärt

Bei CVE-2026-59310 handelt es sich um eine sogenannte Directory-Traversal-Schwachstelle. Directory Traversal (deutsch etwa „Verzeichnis-Durchquerung“) bedeutet, dass eine Lücke es erlaubt, unzulässig durch Dateipfade und Verzeichnisse zu navigieren – also an Stellen zu gelangen, die eigentlich gesperrt sein sollten. Im konkreten Fall liegt dieses Problem laut Broadcom im vCenter-Syslog-Server, der eigentlich nur Protokolldaten verarbeiten soll.

Wichtig ist die Unterscheidung: „Netzwerkzugriff“ ist nicht automatisch dasselbe wie „Internetzugriff“. Öffentlich aus dem Internet erreichbare vCenter-Systeme vergrößern jedoch die Angriffsfläche erheblich – und genau gegen solche Systeme richtet sich die beobachtete Kampagne.

Die beobachtete Angriffskette

Das Sicherheitsforschungsteam QUIRSO dokumentierte aus einem konkreten Incident-Response-Fall (also der Reaktion auf einen realen Sicherheitsvorfall) den Ablauf eines Angriffs. Es handelt sich dabei nicht nur um harmlose Scans: Die Forscher fanden Pfad-Traversal-Aktivität, gefolgt von der Installation von reverse_ssh.

reverse_ssh ist ein quelloffenes Werkzeug, das eine sogenannte Reverse Shell über SSH aufbaut – vereinfacht gesagt einen ausgehenden Fernzugangskanal. Damit stellen die Angreifer eine Verbindung von der gekaperten Maschine nach draußen zu ihrer eigenen Infrastruktur her und sichern sich so dauerhaften Zugriff (Persistenz). Das Werkzeug wird auch legitim bei Sicherheitstests eingesetzt – ein einzelner Fund ist also kein alleiniger Beweis. QUIRSO ordnet ein:

„The presence of reverse_ssh should not, by itself, be treated as proof of malicious activity. In combination with unauthorized installation, unexpected outbound connections or execution on a vulnerable vCenter appliance, however, it is a high-priority indicator requiring investigation.“ – QUIRSO Threat Research Team

Die Shadowserver Foundation, eine gemeinnützige Sicherheitsorganisation, geht bei den in ihrem Sonderbericht gelisteten Systemen jedoch von einer vollständigen Kompromittierung aus:

„the reverse_ssh persistence mechanism has been deployed by the attackers on all victims reported, and they should be considered fully compromised.“ – The Shadowserver Foundation

Zur Einordnung der Bedrohungslage: Bei der Analyse durch Rapid7 am 30. Juli 2026 gab es noch keinen bekannten öffentlichen Proof-of-Concept (einen frei verfügbaren Beispielcode, der die Ausnutzung demonstriert). Diese Aussage war jedoch zeitlich begrenzt – wenige Tage später war die aktive Ausnutzung real. Für die Verteidigung zählt ohnehin nicht die Existenz eines PoCs, sondern die bestätigte reale Kompromittierung.

Wer ist betroffen?

QUIRSO erfasste 361 eindeutige Opfer-IP-Adressen in 47 Ländern. Wichtig ist die korrekte Deutung dieser Zahl. QUIRSO stellt ausdrücklich klar:

„The exact number of victim organizations cannot be inferred from these IP addresses, as an IP address does not necessarily correspond to a unique company or physical system.“ – QUIRSO Threat Research Team

361 IP-Adressen bedeuten also nicht 361 Unternehmen oder 361 physische Server. Die Zahl darf nicht verkürzt werden. Klar ist aber: 185 dieser IP-Adressen – etwas mehr als die Hälfte – entfielen zusammen auf Deutschland, die USA, die Türkei, den Iran und Frankreich. Deutschland gehört damit zu den am stärksten betroffenen Ländern. Eine separate, belastbare Deutschlandzahl wurde in der geprüften Quelle allerdings nicht veröffentlicht.

Die Dynamik der Kampagne war hoch: Am 4. August 2026 kamen an einem einzigen Tag 151 neue Opfer-IP-Adressen hinzu. Bis zum 5. August waren bereits 343 der 361 IP-Adressen – rund 95 Prozent – sichtbar. Das BSI (Bundesamt für Sicherheit in der Informationstechnik) ergänzte seinen Warnhinweis WID-SEC-W-2026-2569 am 10. August um den Vermerk „Aktive Ausnutzung gemeldet“.

Was bedeutet das für kleine und mittlere Unternehmen?

Für Sie ist die Lücke nur dann unmittelbar relevant, wenn Sie selbst VMware vCenter betreiben oder Ihr Hosting-, Managed-Service- oder Cloud-Anbieter (IaaS – „Infrastructure as a Service“) diese Komponente für die Bereitstellung Ihrer Website oder der dahinterliegenden Systeme nutzt.

Betreiben Sie eine gewöhnliche Website ohne eigenen vCenter-Betrieb, sind Sie durch diese spezielle CVE nicht unmittelbar betroffen. Sie tragen jedoch ein Lieferketten- und Verfügbarkeitsrisiko, falls Ihr Dienstleister vCenter einsetzt. Deshalb lohnt in diesem Fall eine gezielte Nachfrage beim Anbieter.

So prüfen Sie, ob Sie betroffen sind

1. Bestandsaufnahme: Erstellen Sie eine Liste aller vCenter-Instanzen sowie der betreibenden Teams und Dienstleister. Prüfen Sie, ob vCenter eigenständig betrieben wird oder als Teil von VMware Cloud Foundation, vSphere Foundation, Telco Cloud Platform oder Telco Cloud Infrastructure läuft.
2. Version ermitteln: Melden Sie sich ausschließlich über den regulären Administrationsweg an. Build und Version zeigt laut Broadcom der Reiter „Summary“ im vSphere Client. Alternativ kann ein autorisierter Administrator in PowerCLI nach Connect-VIServer die Variablen $global:DefaultVIServer.Build und $global:DefaultVIServer.Version prüfen.
3. Mit der Fix-Matrix abgleichen: Die abgesicherten Stände sind 9.1.0.0300 für 9.1.x, 9.0.2.0100 für 9.0.x sowie 8.0 U3k oder 8.0 U2f für den jeweiligen vCenter-8.0-Zweig. Jeder ältere Stand im betreffenden Branch gilt als betroffen. Bei Unklarheit empfiehlt Broadcom, von Betroffenheit auszugehen und unverzüglich zu handeln.
4. Erreichbarkeit prüfen: Kontrollieren Sie anhand Ihrer Firewall-, NAT-, VPN- und Asset-Inventardaten, ob die vCenter-Managementoberfläche aus dem Internet erreichbar ist. Führen Sie keine Scans fremder Systeme durch. Eine öffentliche Freigabe der eigenen Umgebung ist unverzüglich zu entfernen oder auf einen streng kontrollierten Zugang zu begrenzen.
5. Nach Kompromittierungsindikatoren suchen: Durchsuchen Sie die vCenter-Appliance und die zentralen Sicherheits- und Netzwerkprotokolle nach nicht autorisierter reverse_ssh-Installation, unerwarteten ausgehenden Verbindungen, ungewöhnlicher Ausführung und Pfad-Traversal-Indikatoren. QUIRSO stellt eine generische YARA-Regel (ein Erkennungsmuster für Schadsoftware) für reverse_ssh bereit; ein Treffer ist stets mit weiteren Kontextdaten zu korrelieren.
6. Bei Funden: Vorfall annehmen: Werden reverse_ssh oder passende Indikatoren gefunden, behandeln Sie die Instanz nicht als bloß „gepatcht“, sondern als möglichen Sicherheitsvorfall. Veranlassen Sie eine qualifizierte forensische Untersuchung und ziehen Sie bei Bedarf Incident-Response-Unterstützung hinzu.

Das müssen Sie jetzt tun

1. Notfall-Update einspielen: Veranlassen Sie eine Notfalländerung und installieren Sie unverzüglich den passenden Broadcom-Fix. Broadcom ordnet die Lage ausdrücklich als ITIL-Notfalländerung ein, weil kein Workaround verfügbar ist. Die Patches sind kumulativ – ein einzelnes Update enthält alle für den jeweiligen Produktzweig verfügbaren Aktualisierungen. Das Update läuft über die Standardverfahren, etwa das vCenter-VAMI. Der vSphere Client ist während des Updates kurz nicht verfügbar; laufende virtuelle Maschinen und Container-Workloads laufen laut Hersteller jedoch weiter.
2. Angriffsfläche verkleinern: Unterbinden Sie bis zur vollständigen Aktualisierung die öffentliche Erreichbarkeit der vCenter-Verwaltung und nutzen Sie nur einen abgegrenzten Managementzugang. Broadcom weist darauf hin, dass Firewalls lediglich kompensierende Kontrollen sein können – sie ersetzen das Update nicht.
3. Kompatibilität prüfen: Kontrollieren Sie vor dem Update die Kompatibilität von vCenter, ESX und gegebenenfalls vSAN in der Broadcom-Interoperabilitätsmatrix. Für VMware Cloud Foundation 5.x ist der dokumentierte asynchrone Patchprozess zu verwenden. Bei zertifizierten Drittanbietersystemen wie VxRail oder HPE SimpliVity gelten ausschließlich deren freigegebene Patchverfahren.
4. Überwachen und untersuchen: Achten Sie besonders auf nicht autorisierte reverse_ssh-Builds, unerwartete ausgehende Fernzugangsverbindungen und ungewöhnliche Ausführung auf der vCenter-Appliance – stets im Zusammenhang, weil reverse_ssh auch legitim genutzt werden kann.
5. Bei Verdacht: Vorfall-Prozess starten: Begrenzen Sie den Zugriff nach Ihrem Incident-Response-Verfahren, sichern Sie die für die Analyse nötigen Protokolle und Beweise, lassen Sie Umfang und Auswirkungen untersuchen und dokumentieren Sie die Entscheidungen. Denken Sie daran: Patching allein entfernt keinen bereits eingerichteten Fernzugang.
6. Dienstleister in die Pflicht nehmen: Betreibt ein IT-Dienstleister vCenter für Ihre Website oder Backend-Systeme, fordern Sie schriftlich den eingesetzten Produktzweig, die Patchversion, die Bestätigung fehlender öffentlicher Erreichbarkeit, die Prüfung auf Kompromittierungsindikatoren und die Einbindung in den Datenschutzvorfallprozess an.

DSGVO-Einordnung: Wann wird ein Vorfall meldepflichtig?

Eine ausnutzbare Lücke allein löst noch keine Meldepflicht aus – entscheidend ist der konkrete Vorfall, nicht der CVSS-Wert oder der Patchstand. Das Unabhängige Landeszentrum für Datenschutz Schleswig-Holstein (ULD) definiert eine Datenschutzverletzung als Vernichtung, Verlust, Veränderung, unbefugte Offenlegung oder unbefugten Zugang zu personenbezogenen Daten. Cyberangriffe führen regelmäßig dazu, wenn Angreifer unbefugten Zugang erlangen.

Bei einer erfolgreichen vCenter-Kompromittierung muss daher geprüft werden, ob personenbezogene Daten in der Appliance, auf verwalteten Systemen oder in erreichbaren Speichern betroffen sein könnten. Der Verantwortliche muss den Vorfall und die Risikobewertung dokumentieren. Nach Art. 33 DSGVO ist bei einem Risiko für die Rechte und Freiheiten natürlicher Personen die zuständige Aufsichtsbehörde grundsätzlich unverzüglich und möglichst binnen 72 Stunden nach Kenntnis zu informieren; eine verspätete Meldung braucht eine Begründung. Liegt voraussichtlich kein Risiko vor, entfällt die Meldung – die Dokumentationspflicht bleibt jedoch bestehen.

Bei hohem Risiko ist zusätzlich nach Art. 34 DSGVO eine unverzügliche Benachrichtigung der betroffenen Personen erforderlich. Auftragsverarbeiter – etwa Ihr Hosting-Dienstleister – müssen den Verantwortlichen unverzüglich informieren. Art. 32 DSGVO verlangt zudem risikoadäquate technische und organisatorische Maßnahmen sowie ausdrücklich einen Prozess zum regelmäßigen Testen und Bewerten ihrer Wirksamkeit.

Dass Sicherheitsmängel und die Qualität der Reaktion aufsichtsrechtlich relevant sind, zeigen dokumentierte Vergleichsfälle: Der LfDI Baden-Württemberg verhängte 2018 nach einem Hackerangriff mit rund 330.000 betroffenen Nutzerkonten wegen Klartextspeicherung von Passwörtern ein Bußgeld von 20.000 Euro. Der britische ICO verhängte 2020 gegen British Airways nach einem Angriff wegen unzureichender Datensicherheit ein Bußgeld von 20 Millionen Pfund. Diese Entscheidungen sind keine Bußgeldprognose für einen vCenter-Vorfall, sie verdeutlichen aber die Tragweite. Die konkrete Bewertung eines Vorfalls gehört in die Hände des Verantwortlichen, des Datenschutzbeauftragten und gegebenenfalls einer spezialisierten Rechtsberatung. Dies ist eine allgemeine Einordnung, keine Einzelfallberatung.

Risiko-Einschätzung

Für eine ungepatchte, aus dem Internet erreichbare vCenter-Instanz ist das Risiko akut und kritisch: Die Lücke erlaubt Codeausführung über das Netzwerk ohne vorherige Anmeldung, und reale Kompromittierungen samt Persistenzmechanismus sind dokumentiert. Für eine nur intern erreichbare, aber ungepatchte Instanz bleibt das Risiko hoch – ein Angreifer kann nach einem anderen ersten Zugriff im Firmennetz die nötige Reichweite erlangen. Für reine Website-Betreiber ohne vCenter-Betrieb besteht kein unmittelbares CVE-Risiko, wohl aber ein Lieferkettenrisiko über den Dienstleister.

Fazit

CVE-2026-59310 ist ein Lehrstück in Sachen Reaktionsgeschwindigkeit: Nur fünf Tage nach dem Patch begannen die ersten Angriffe, und die Kampagne skalierte innerhalb weniger Tage auf Hunderte betroffene IP-Adressen weltweit – mit Deutschland unter den fünf am stärksten betroffenen Ländern. Ein Workaround existiert nicht; die einzige wirksame Abhilfe ist das Update auf einen der Fixstände 9.1.0.0300, 9.0.2.0100, 8.0 U3k oder 8.0 U2f.

Wenn Sie vCenter betreiben: Behandeln Sie das Einspielen als Notfall, entfernen Sie jede öffentliche Erreichbarkeit der Verwaltungsoberfläche und prüfen Sie Ihre Systeme auf Spuren von reverse_ssh. Denken Sie daran, dass ein Patch die Lücke schließt, einen bereits eingerichteten Fernzugang aber nicht beseitigt – hier hilft nur eine forensische Prüfung. Und wenn ein Dienstleister vCenter für Sie betreibt: Fragen Sie noch heute schriftlich nach Patchstand, Erreichbarkeit und Kompromittierungsprüfung. Diese eine E-Mail kann den Unterschied machen.