Veröffentlicht am 13.08.2026
Fünf Tage. So lange dauerte es, bis Angreifer nach der öffentlichen Bekanntgabe einer kritischen VMware-Lücke die ersten verwundbaren Systeme kompromittierten. Am 29. Juli 2026 veröffentlichte Broadcom das Sicherheitsadvisory zu CVE-2026-59310 – am 3. August beobachteten Sicherheitsforscher bereits die ersten Kontakte kompromittierter Systeme mit der Infrastruktur der Angreifer. Inzwischen sind bis zu 361 betroffene IP-Adressen in 47 Ländern dokumentiert, und Deutschland gehört zu den fünf am stärksten betroffenen Ländern.
Wenn Ihr Unternehmen VMware vCenter einsetzt – selbst betrieben oder über einen Dienstleister – dann ist dieser Artikel für Sie hochrelevant. Die Lücke erlaubt es Angreifern, ohne vorherige Anmeldung beliebigen Code auf einer der zentralsten Komponenten Ihrer IT-Infrastruktur auszuführen. Und sie wird bereits aktiv missbraucht.
Broadcom, seit der VMware-Übernahme Eigentümer der VMware-Produkte, hat mit dem Advisory VMSA-2026-0006 (am 3. August aktualisiert auf VMSA-2026-0006.1) eine kritische Schwachstelle im vCenter Server offengelegt. VMware vCenter ist die zentrale Verwaltungsebene für vSphere-Umgebungen – also die Software, mit der Administratoren ihre gesamte virtualisierte Server- und Rechenzentrums-Infrastruktur steuern.
Die Lücke trägt die Kennung CVE-2026-59310 und einen CVSS-Wert von 9,8 von 10 – das ist nahezu das Maximum und steht für „kritisch". Konkret handelt es sich um eine sogenannte Directory-Traversal-Schwachstelle (Fachbegriff CWE-22), also einen Fehler bei der Begrenzung von Dateipfaden. Diese sitzt im Syslog-Server von vCenter, der eigentlich nur Protokolldaten entgegennehmen soll.
Das Entscheidende: Broadcom formuliert unmissverständlich, was ein Angreifer damit anstellen kann:
„A malicious actor with network access to vCenter may exploit this issue to execute arbitrary code."
– Broadcom VMware, VMSA-2026-0006.1
Übersetzt: Ein Angreifer mit Netzwerkzugriff auf den vCenter-Server kann beliebigen Code ausführen. Laut dem CVSS-Vektor (AV:N/AC:L/PR:N/UI:N) ist dafür keine vorherige Anmeldung erforderlich, der Angriff ist über das Netzwerk möglich, technisch wenig komplex und benötigt keine Interaktion des Opfers. Das ist die denkbar gefährlichste Kombination.
Das Threat-Research-Team QUIRSO hat nach einer Incident-Response-Untersuchung eine aktive Kampagne gegen aus dem Internet erreichbare vCenter-Systeme dokumentiert. Der Ablauf sieht demnach so aus:
Der Trick mit dem „ausgehenden" Zugang ist perfide: Viele Firewalls blockieren eingehende Verbindungen streng, lassen ausgehende Verbindungen aber großzügig zu. So bleibt der Angreifer verbunden, ohne dass ein klassischer Alarm anschlägt. Wichtig zur Einordnung: reverse_ssh ist ein legitimes Open-Source-Tool. QUIRSO warnt ausdrücklich davor, seine bloße Anwesenheit als Beweis zu werten:
„The presence of reverse_ssh should not, by itself, be treated as proof of malicious activity."
– QUIRSO Threat Research
Ein Fund muss also mit weiteren Indikatoren – unautorisierter Installation, unerwarteten ausgehenden Verbindungen, Ausführung auf einer verwundbaren vCenter-Appliance – korreliert werden.
Die aktive Ausnutzung ist von mehreren unabhängigen Stellen bestätigt. Das NHS England National CSOC (das Cyber-Sicherheitszentrum des britischen Gesundheitssystems) eskalierte seine Warnung am 12. August 2026 auf hohe Schwere und meldete beobachtete Ausnutzung mit Reverse-SSH-Persistenz. Die Einschätzung ist eindeutig:
„The NHS England National CSOC assesses further exploitation as likely."
– NHS England National CSOC
QUIRSO weist zudem auf ein alarmierendes Muster hin – die enge zeitliche Kopplung von Offenlegung und Angriff:
„The strong correlation between the time of disclosure and exploitation suggests the disclosure as the initial starting point for the campaign."
– QUIRSO Threat Research
Mit anderen Worten: Die Angreifer haben die Veröffentlichung des Advisories offenbar als Startsignal genutzt und binnen weniger Tage massenhaft zugeschlagen. Bereits am 5. August waren rund 95 Prozent der insgesamt 361 später identifizierten Opfer-IP-Adressen erschienen.
Wichtige Einordnung zu den Zahlen: Die 361 IP-Adressen sind ausdrücklich keine Zahl betroffener Unternehmen und erst recht keine Zahl betroffener Datensätze. IP-Adressen können Hosting-, Cloud- oder geteilte Infrastruktur repräsentieren. Von den 361 Adressen lagen 185 in den fünf am stärksten betroffenen Ländern: Deutschland, USA, Türkei, Iran und Frankreich. Eine exakte deutsche Zahl wurde nicht veröffentlicht – klar ist aber, dass Deutschland zur Spitzengruppe zählt.
Ein Hinweis noch: Zum Abruf am 12. August 2026 war CVE-2026-59310 nicht im offiziellen CISA-KEV-Katalog (dem US-Verzeichnis bekannter ausgenutzter Schwachstellen) gelistet. Das ist aber kein Gegenbeweis – die von QUIRSO und NHS England dokumentierten Beobachtungen bleiben davon unberührt. Ein öffentliches Proof-of-Concept (also fertiger Beispiel-Exploit-Code) war in den geprüften Quellen ebenfalls nicht bestätigt.
Betroffen sind nicht nur eigenständige vCenter-Installationen, sondern auch vCenter als Komponente folgender Produkte:
Für deutsche KMU ist die Lücke unmittelbar relevant, wenn sie vCenter selbst betreiben oder über einen Dienstleister für ihre Website-, Shop-, Server- oder sonstige Unternehmensinfrastruktur einsetzen. Eine gewöhnliche Website ohne vCenter ist durch diese spezielle CVE nicht direkt verwundbar. Aber Achtung: Ihre Website-Verfügbarkeit und die verarbeiteten Daten können mittelbar gefährdet sein, wenn die zugrundeliegende virtuelle Infrastruktur über ein ungepatchtes vCenter verwaltet wird. Fragen Sie deshalb aktiv bei Ihrem Hoster oder Managed Service Provider nach.
vpxd -v auf der Appliance oder die Übersichtsseite der Management-Oberfläche unter https://<VC_FQDN>:5480. Verlassen Sie sich nicht nur auf die Versionsanzeige im vSphere-Client – diese kann laut Broadcom vom tatsächlichen Server-Build abweichen.Broadcom nennt für CVE-2026-59310 keinen Workaround. Das Einspielen der Updates ist die einzige wirksame Abhilfe. Die Patches sind seit dem 29. Juli 2026 verfügbar und kumulativ.
Die Schwachstelle allein löst keine DSGVO-Meldepflicht aus. Ergibt Ihre Untersuchung jedoch eine Verletzung des Schutzes personenbezogener Daten – etwa durch unbefugten Zugriff, Offenlegung, Veränderung oder Verlust –, müssen Sie als Verantwortlicher das Risiko für die Rechte und Freiheiten betroffener Personen bewerten.
Besteht voraussichtlich ein Risiko, ist die zuständige Aufsichtsbehörde nach Art. 33 Abs. 1 DSGVO unverzüglich und möglichst binnen 72 Stunden ab Kenntnis zu informieren; eine spätere Meldung ist zu begründen. Bei voraussichtlich hohem Risiko sind nach Art. 34 DSGVO grundsätzlich auch die Betroffenen zu benachrichtigen. Jede Datenschutzverletzung ist nach Art. 33 Abs. 5 DSGVO zu dokumentieren.
Art. 32 DSGVO verlangt risikogerechte technische und organisatorische Maßnahmen – dazu gehört zeitnahes Patchen. Bei Verstößen sieht Art. 83 Abs. 4 DSGVO Geldbußen von bis zu 10 Mio. Euro oder 2 Prozent des weltweiten Jahresumsatzes vor, je nachdem, welcher Betrag höher ist. Zur Einordnung: Der BfDI verhängte 2019 gegen 1&1 Telecom 9,55 Mio. Euro wegen aus seiner Sicht unzureichender Sicherheitsmaßnahmen. Dieser Fall betrifft keine VMware-Lücke und erlaubt keine Bußgeldprognose – er zeigt aber, dass Aufsichtsbehörden mangelnde technische Vorsorge ernst nehmen.
Dies ist keine Rechtsberatung für den Einzelfall. Ob und welche Pflichten bestehen, hängt von den tatsächlichen Verarbeitungsvorgängen und der konkreten Risikobewertung ab.
CVE-2026-59310 ist der Ernstfall, den Sicherheitsverantwortliche fürchten: eine kritische Lücke (CVSS 9,8) in einer zentralen Infrastrukturkomponente, ohne Anmeldung über das Netzwerk ausnutzbar, mit bestätigter aktiver Ausnutzung binnen Tagen nach Bekanntgabe – und Deutschland mittendrin. Die Angreifer richten sich mit Cronjob und reverse_ssh gezielt auf dauerhaften Zugang ein.
Wenn Sie vCenter betreiben oder betreiben lassen, gilt: Patchen Sie sofort auf die passende Fixed Version, beschränken Sie den Managementzugang und führen Sie zusätzlich eine Kompromittierungsprüfung durch – denn ein Patch allein beseitigt keinen bereits erfolgten Einbruch. Nutzen Sie keine eigene vCenter-Verwaltung, klären Sie unverzüglich mit Ihrem Dienstleister, ob und wann gepatcht wurde. Die fünf Tage bis zum ersten Angriff zeigen: Bei dieser Lücke zählt jeder Tag.