CVE-2026-59310: Was die globale VMware-vCenter-Kampagne offenlegt

CVE-2026-59310 ist längst nicht mehr nur ein dringendes Patch-Thema. Broadcom veröffentlichte die kritische Schwachstelle im Syslog-Server von VMware vCenter am 29. Juli 2026 und stellte Updates bereit. Bereits ab dem 3. August beobachteten Forscher aktive Ausnutzung – nur fünf Tage später. Die Kampagne umfasste 361 beobachtete IP-Adressen in 47 Ländern. Die Angreifer setzten unter anderem Reverse SSH ein, um den Zugriff aufrechtzuerhalten. Shadowserver stuft Systeme mit diesem Persistenzmechanismus als vollständig kompromittiert ein.

Was CVE-2026-59310 ermöglicht

Broadcom und die National Vulnerability Database (NVD) beschreiben CVE-2026-59310 als Directory-Traversal-Schwachstelle im vCenter-Syslog-Server. Ein Angreifer mit Netzwerkzugriff benötigt keine Authentifizierung, um die Sicherheitslücke auszunutzen und beliebigen Code auf einem betroffenen vCenter-System auszuführen. Mit einem CVSS-Wert von 9,8 fällt die Schwachstelle in die kritische Kategorie.

Praktisch kann ein exponiertes vCenter-System dadurch zum Ausgangspunkt für dauerhaften Zugriff und weitere Angriffe auf die virtuelle Infrastruktur werden. Berichte zur Kampagne beschreiben auch eine Codeausführung im Root-Kontext der Appliance. Die maßgeblichen Angaben von Broadcom und der NVD bestätigen jedoch vor allem das Risiko der Ausführung beliebigen Codes – nicht jedes Detail zu den Rechten in allen einzelnen Eindringvorgängen.

Broadcom stellt behobene Versionen bereit, nennt aber keinen Workaround. Die Installation der in der Sicherheitsmitteilung aufgeführten Updates ist daher die offizielle Abhilfe.

Die entscheidende Zeitlinie: Patch zuerst, Angriff fünf Tage später

Broadcom veröffentlichte die Sicherheitsmitteilung und die Patches am 29. Juli. QUIRSO meldete erste Anzeichen einer aktiven Ausnutzung ab dem 3. August; anschließend weitete sich die Kampagne rasch aus.

Für die Incident Response ist diese Abfolge entscheidend: Ein System, das nach dem 3. August gepatcht wurde, ist nicht automatisch sauber. Unternehmen müssen zwischen der Behebung der Schwachstelle und der Prüfung auf eine bereits erfolgte Kompromittierung unterscheiden. Das Update schließt die Lücke – es entfernt aber nicht zwingend einen schon eingerichteten Zugang.

Die Reichweite der Kampagne

Forscher bringen die Aktivität mit 361 beobachteten Opfer-IP-Adressen in 47 Ländern in Verbindung. Deutschland, die USA, die Türkei, Iran und Frankreich sollen dabei mehr als die Hälfte der beobachteten Systeme ausgemacht haben.

Die Zahl muss jedoch eingeordnet werden: Eine IP-Adresse entspricht nicht zwangsläufig einem einzelnen Unternehmen oder einer einzelnen Einrichtung. „361 Opfer“ bedeutet daher nicht automatisch 361 verschiedene Organisationen. Die verfügbaren Berichte sprechen aber für eine breit angelegte Kampagne gegen aus dem Internet oder über weitreichende Netzwerke erreichbare vCenter-Systeme.

Warum Forscher einen China-Bezug vermuten

QUIRSO bewertet den China-Bezug der Kampagne mit mittlerer Zuversicht. Als Indizien nennt das Unternehmen chinesischsprachige Artefakte, Werkzeuge und öffentlich wiederverwendete Forschung, Aktivitäten während typischer Arbeitszeiten in UTC+08:00 sowie eine Opferauswahl, die offenbar das chinesische Festland ausließ.

Diese Hinweise stützen eine regionale oder sprachliche Einschätzung. Sie identifizieren jedoch keine konkrete chinesische Staatsgruppe und belegen auch keine staatliche Steuerung. Zuschreibungen anhand von Malware-Artefakten, Zeitmustern und Zielauswahl können sich zudem ändern, wenn weitere Belege hinzukommen. Die vorsichtigste Beschreibung lautet deshalb: ein mutmaßlicher Akteur mit China-Bezug – keine bestätigte staatlich gesteuerte Operation.

Die mutmaßliche Angriffskette

Nach bisherigem Kenntnisstand nutzte die Kampagne CVE-2026-59310 für den Erstzugriff und installierte anschließend mehrere Ebenen für Persistenz und Fernzugriff:

1. Directory Traversal: Manipulierte Anfragen an den Syslog-Dienst sollten den vorgesehenen Pfad verlassen und von den Angreifern kontrollierte Inhalte schreiben.
2. Persistenz über Cron: Die Angreifer legten Berichten zufolge fehlerhafte Cron-Einträge an, über die nachgelagerte Befehle gestartet werden konnten.
3. Auslieferung einer Backdoor: Über curl oder wget wurde laut den Berichten eine per WebSocket kommunizierende und XOR-verschleierte linuxFile-Backdoor nachgeladen.
4. Reverse SSH: Reverse-SSH-Werkzeuge stellten eine ausgehende Verbindung zur Infrastruktur der Angreifer her. Laut Shadowserver wurde dieser Persistenzmechanismus bei allen Opfern seines Sonderberichts beobachtet.
5. Missbrauch von Konten und Zugangsdaten: Ermittler meldeten unbefugt angelegte vCenter- und ESXi-Administratorkonten sowie den Missbrauch von Zugangsdaten des VMware Directory Service.
6. Einsatz von Ransomware: Mindestens einige Berichte bringen die Aktivität mit einer von Babuk abgeleiteten Ransomware-Variante in Verbindung, die Dateien mit der Endung .babyk versieht.

Der Befund zu Reverse SSH ist besonders relevant. Shadowserver empfiehlt, Systeme mit diesem Mechanismus als vollständig kompromittiert zu behandeln. Das Löschen einer einzelnen Binärdatei oder eines Cron-Jobs reicht nicht aus, wenn das Vertrauen in die Appliance und die privilegierten Zugangsdaten nicht grundsätzlich wiederhergestellt wird.

Ransomware möglicherweise als Ablenkungsmanöver

Die gemeldete .babyk-Aktivität muss nicht zwangsläufig eine klassische Ransomware-Kampagne gewesen sein, deren Hauptziel die großflächige Verschlüsselung und anschließende Erpressung war. Analysten vermuten, dass die selektive Verschlüsselung von ESXi-Logs vor allem Ermittlungen erschweren und Beweise verbergen sollte.

Diese Erklärung ist eine Schlussfolgerung der Analysten und keine bestätigte Aussage der Angreifer. Verteidiger sollten deshalb beide Szenarien prüfen: Auswirkungen auf virtuelle Maschinen ebenso wie eine gezielte Manipulation von Logs zur Verschleierung des Eindringens.

GitHub als Tarnung für wiederverwendete Werkzeuge

Berichte verknüpfen die Operation außerdem mit einem GitHub-Repository, in dem Reverse-SSH-Binärdateien als Linux-Werkzeug zum Bereinigen temporärer Dateien dargestellt wurden. Ein Persistenzwerkzeug als Administrations- oder Bereinigungsprogramm zu tarnen, kann die Verteilung erleichtern und es bei Routineprüfungen weniger auffällig machen. Die verfügbaren Belege klären jedoch nicht unabhängig, wer das Repository betrieben hat. Seine Existenz ist daher kein Beweis für die Zuordnung zu einem bestimmten Akteur.

Folgen für Broadcom und VMware

Die Broadcom-Aktie verlor am 14. August rund 5 bis 6 Prozent, nachdem Berichte über die aktive Ausnutzung der VMware-Schwachstelle Anleger erreicht hatten. Ein Bericht nannte einen Rückgang von 417,82 auf 392,99 US-Dollar innerhalb der Handelssitzung.

Die Sicherheitsberichte waren ein Faktor für den Kursrückgang, aber wahrscheinlich nicht der einzige. Zeitgleich wurden auch breitere Sorgen des Marktes genannt, darunter die Verschuldung im Zusammenhang mit künstlicher Intelligenz. Deshalb lässt sich weder der gesamte Kursverlust noch ein exakter Betrag des verlorenen Börsenwerts allein CVE-2026-59310 zuschreiben.

Für einen messbaren Rückgang der VMware-Umsätze gibt es in den verfügbaren Berichten bislang keine ausreichenden Belege. Plausible kurzfristige Folgen sind Kosten für die Kundenbehebung, das Risiko betrieblicher Störungen und zusätzlicher Reputationsdruck. Ein längerfristiger Umsatzeffekt ließe sich erst durch Unternehmensangaben oder weitere Finanzdaten belastbar beurteilen.

Was vCenter-Administratoren jetzt tun sollten

Patching ist der erste Schritt – nicht der letzte. Unternehmen sollten:

1. Die von Broadcom bereitgestellten behobenen Versionen sofort installieren: Das gilt für jede betroffene vCenter-Instanz, mit Priorität für aus dem Internet erreichbare Systeme und Appliances, die aus großen internen Netzbereichen zugänglich sind. Broadcom nennt keinen Workaround.
2. Bei vorhandenen Indikatoren von einer Kompromittierung ausgehen: Dazu zählen unerwartete Cron-Änderungen, Reverse-SSH-Artefakte, linuxFile, nicht erklärte Downloads über curl oder wget, unbekannte vCenter- oder ESXi-Administratoren und auffällige Aktivitäten des VMware Directory Service.
3. Verdächtige Appliances isolieren: Wo es der Betrieb zulässt, sollten vor einem Neuaufbau Datenträgerabbilder, Logs und flüchtige Daten gesichert werden.
4. Privilegierte Zugangsdaten rotieren: Dazu gehören vCenter-SSO-, VMware-Directory-Service-, ESXi- beziehungsweise Root-, API-, Dienstkonto- und verbundene Administratorkonten. Aktive Sitzungen sollten ungültig gemacht und Föderationspfade überprüft werden.
5. Betroffene Systeme neu aufbauen statt nur bereinigen: Bei bestätigter Persistenz sollten unbefugte Konten, Cron-Jobs, Binärdateien, SSH-Schlüssel und Tunnel im Rahmen eines dokumentierten Incident-Response-Prozesses entfernt werden.
6. Die gesamte virtuelle Infrastruktur durchsuchen: Zu prüfen sind .babyk-Aktivitäten, unerwartete ausgehende SSH- oder WebSocket-Verbindungen, fremde Konten und Hinweise auf manipulierte ESXi-Logs.
7. Vertrauenswürdige Daten und Telemetrie wiederherstellen: Wurden Logs oder Konfigurationen verändert, sollten bekannte gute und unveränderliche Backups verwendet werden.
8. Die künftige Angriffsfläche verkleinern: Der Zugriff auf die vCenter-Verwaltung sollte auf segmentierte Administrationsnetze beschränkt werden. Ausgehende Verbindungen von vCenter und ESXi-Systemen sollten überwacht werden.

Die operative Schlussfolgerung ist eindeutig: Jede verwundbare vCenter-Instanz muss aktualisiert werden. Ein erfolgreich eingespieltes Update darf jedoch nicht mit einer sauberen Umgebung gleichgesetzt werden. Die schnelle Ausnutzung, dauerhafte Reverse-SSH-Zugänge und der gemeldete Missbrauch privilegierter Konten machen exponierte Appliances zu möglichen vollständigen Kompromittierungen.