CVE-2026-59310: VMware vCenter RCE in 47 Laendern ausgenutzt

Diese Woche in unserer InSEKurity of the Week-Reihe: eine Directory-Traversal-Schwachstelle im VMware vCenter Syslog-Server, die es einem unauthentifizierten Angreifer allein über Netzwerkerreichbarkeit erlaubt, beliebigen Code auf der Appliance auszuführen, die die gesamte virtuelle Umgebung einer Organisation verwaltet. Broadcom hat CVE-2026-59310 am 29. Juli 2026 im Rahmen von VMSA-2026-0006 veröffentlicht, bewertet mit CVSS 9.8, versehen mit einem unmissverständlichen Hinweis: es gibt keinen Workaround. Fünf Tage später beobachtete das QUIRSO Threat Research Team die ersten kompromittierten vCenter-Systeme beim Verbindungsaufbau zur Angreifer-Infrastruktur. Bis zum 7. August zählten sie 361 Opfer-IP-Adressen in 47 Ländern — keine Exploit-Versuche, sondern Hosts, die bereits Angreifer-Infrastruktur kontaktierten — wobei ein mutmaßlicher APT-Akteur das Open-Source-Framework reverse_ssh für persistenten, firewall-umgehenden Zugriff einsetzt. Deutschland führt die Opferliste an. Was diesen Wochenbeitrag lesenswert macht, ist nicht der Score. Es ist die Lücke: Zum Redaktionsschluss besagt Broadcoms eigenes Q&A-Dokument weiterhin, es lägen keine Hinweise auf Ausnutzung in freier Wildbahn vor, und die CISA hat die CVE nicht in den KEV-Katalog aufgenommen. Wer auf einen KEV-Eintrag wartet, um einen Notfall-Change zu rechtfertigen, sollte diese Woche damit aufhören.

🚨 Zusammenfassung

CVE-ID: CVE-2026-59310
CVSS 3.1 Score: 9.8 Kritisch (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H), vergeben von VMware als CNA
CWE: CWE-22 (Improper Limitation of a Pathname to a Restricted Directory / ‘Path Traversal’)
Betroffene Software: VMware vCenter 9.1.x (vor 9.1.0.0300), 9.0.x (vor 9.0.2.0100), 8.0 (vor U3k / U2f) — dazu jeder Stack, der vCenter enthält: VMware Cloud Foundation (5.x, 9.0.x, 9.1.x), VMware vSphere Foundation (9.0.x, 9.1.x), VMware Telco Cloud Platform (3.0-5.1.x) und VMware Telco Cloud Infrastructure (3.0). vSphere 7.0 ist ebenfalls betroffen und hat das End of General Support überschritten.
Verwundbare Komponente: der vCenter Syslog-Server — der Log-Collector-Dienst auf der Appliance, nicht der vSphere Client
Angriffsvektor: Netzwerk — Erreichbarkeit des vCenter-Syslog-Listeners
Authentifizierung erforderlich: Keine
Benutzerinteraktion: Keine
Auswirkung: Beliebige Codeausführung auf der vCenter-Appliance; von dort administrative Kontrolle über jeden verwalteten ESX-Host und jede virtuelle Maschine
Patch-Status: ✅ Gepatcht in vCenter 9.1.0.0300, 9.0.2.0100, 8.0 U3k (Build 25600417) und 8.0 U2f. ❌ Kein Workaround vorhanden — Broadcom sagt das ausdrücklich.
Veröffentlicht: Advisory VMSA-2026-0006 am 29. Juli 2026, überarbeitet zu VMSA-2026-0006.1 am 3. August 2026; NVD-Eintrag veröffentlicht am 30. Juli 2026
Exploitation-Status: 🔴 Aktive Ausnutzung durch QUIRSO gemeldet — 361 Opfer-IPs in 47 Ländern (Stand 7. August 2026). Broadcoms Advisory-Q&A gibt weiterhin an, keine Informationen über Ausnutzung in freier Wildbahn zu haben.
CISA KEV: ❌ Nicht gelistet, Stand KEV-Katalogversion 2026.08.17
Gemeldet von: Phil Brass und Matt South von Atredis Partners

🖥️ Was ist VMware vCenter?

VMware vCenter ist der zentrale Management-Server für eine VMware-Virtualisierungsumgebung. Es ist die Appliance, die jeden ESX/ESXi-Host der Umgebung inventarisiert und steuert, die vMotion- und DRS-Platzierungsentscheidungen trifft, die Cluster-Konfiguration und HA-Policy besitzt, die das Berechtigungsmodell hält, das bestimmt, wer was mit welcher virtuellen Maschine tun darf, und die die Credentials für den Zugriff auf die Hypervisoren selbst verwaltet. Administratoren arbeiten über den vSphere Client damit; Automatisierung greift über PowerCLI und die vSphere Automation REST API zu. In der Praxis steuert ein vCenter typischerweise Dutzende bis Tausende virtueller Maschinen.

Diese Konzentration ist der eigentliche Zweck des Produkts — und zugleich der Grund, warum eine vCenter-Schwachstelle sich kategorisch von einer Schwachstelle auf einem einzelnen Server unterscheidet. Codeausführung auf vCenter ist kein Fußabdruck auf einem Host — sie ist administrative Autorität über das Substrat, auf dem alle anderen Hosts laufen. Domain Controller, Backup-Server, Jump Hosts, der SIEM-Collector und der Fileserver sind aus Sicht von vCenter allesamt nur Objekte, die es snapshotten, klonen, umkonfigurieren, ausschalten oder deren virtuelle Festplatten es einhängen kann. Ransomware-Gruppen haben das vor Jahren begriffen, weshalb Hypervisor-Management zu einer der am konsistentesten angegriffenen Schichten in der Unternehmens-IT geworden ist.

Die konkret betroffene Komponente ist enger gefasst und leicht zu übersehen. vCenter betreibt einen Syslog-Server — einen Collector, der Log-Nachrichten von ESX-Hosts und anderer Infrastruktur entgegennimmt, damit vSphere-Logging auf der Appliance zentralisiert werden kann. Er lauscht auf den Standard-Syslog-Ports (UDP/TCP 514 sowie TCP 1514 für TLS), die Broadcom als eingehende Ports der vCenter Server Appliance dokumentiert, und die Appliance-Firewall öffnet sie für den Dienst vmware-syslog. Ein Log-Collector ist genau die Art von Komponente, die einmal konfiguriert, dann vergessen und nie wieder betrachtet wird — während sie per Design unauthentifizierte Eingaben aus dem Netzwerk entgegennimmt.

Typische Einsatzszenarien

Zentrales Cluster-Management: Single-Pane-Administration von ESX-Hosts, Clustern, Ressourcenpools und Datastores über einen oder viele Standorte hinweg.
Workload-Mobilität und Verfügbarkeit: vMotion, Storage vMotion, Distributed Resource Scheduler und High Availability hängen alle von vCenter als entscheidender Instanz ab.
Rollenbasierte Zugriffskontrolle für die virtuelle Umgebung: vCenter besitzt das Berechtigungsmodell, das festlegt, welche Administratoren welche VMs anfassen dürfen.
Lifecycle- und Patch-Management: Der vSphere Lifecycle Manager steuert ESX-Host-Remediation und Image-Compliance aus vCenter heraus.
Automatisierung und Integration: PowerCLI, die vSphere Automation REST API, Terraform-Provider, Backup-Software und Monitoring-Plattformen authentifizieren sich alle gegen vCenter als Einstiegspunkt.
Log-Zentralisierung: Der Syslog-Dienst der Appliance sammelt Log-Nachrichten von ESX-Hosts — die Komponente, in der diese CVE steckt.

🔍 Technische Analyse

Beschreibung der Schwachstelle

Broadcoms Beschreibung ist kurz und präzise: “VMware vCenter contains a directory traversal vulnerability in the Syslog server. A malicious actor with network access to vCenter may exploit this issue to execute arbitrary code.”

Aufgeschlüsselt ist das ein CWE-22-Fehler. Der Syslog-Dienst nimmt Eingaben aus dem Netzwerk entgegen und verwendet irgendwo auf dem Weg von der Nachricht zur Festplatte durch Angreifer beeinflussbare Daten, um einen Dateipfad zu konstruieren, ohne diesen ordentlich auf das vorgesehene Verzeichnis zu beschränken. Traversal-Sequenzen in diesen Daten brechen aus dem Log-Verzeichnis aus, und der Schreibvorgang landet an einer Stelle, die das Dienstkonto kontrolliert — an einer Stelle, die zur Ausführung führt. Der CVSS-Vektor AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H erzählt den Rest: über das Netzwerk erreichbar, geringe Angriffskomplexität, keine Privilegien, keine Benutzerinteraktion und vollständige Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit.

Entscheidend für das Verständnis der Angriffsfläche ist, dass ein Syslog-Collector per Design unauthentifiziert ist. Syslog als Protokoll besitzt in seinen gängigen Deployments keine nennenswerte Authentifizierung; die Aufgabe des Dienstes besteht darin, entgegenzunehmen, was auf Port 514 ankommt, und es aufzuschreiben. Das bedeutet: kein Login, das fehlschlagen könnte, keine Session zum Übernehmen, kein Credential zum Brute-Forcen. Die einzige Kontrolle zwischen Angreifer und verwundbarem Codepfad ist Netzwerkerreichbarkeit — genau deshalb ist Broadcoms “kein Workaround”-Aussage keine Formalie. Es gibt keinen Konfigurationsschalter, der einen Parsing-Fehler behebt, und die einzige verfügbare kompensierende Maßnahme ist eine, die man entweder bereits hat (ein sauber segmentiertes Management-Netz) oder eben nicht.

Es lohnt sich, klar zu benennen, was nicht öffentlich ist. Weder Broadcom noch die meldenden Forscher haben das konkrete Nachrichtenformat, die Traversal-Payload oder die geschriebene Datei veröffentlicht. Es existiert kein öffentlicher Proof-of-Concept-Exploit für CVE-2026-59310. Die von QUIRSO beobachtete Ausnutzung wurde aus Opfer-Telemetrie und Post-Exploitation-Verhalten rekonstruiert, nicht aus einem veröffentlichten Exploit — was bedeutet, dass die Fähigkeit in den Händen einiger weniger, aber noch nicht aller liegt. Diese Unterscheidung verschiebt Ihre Risikorechnung in genau eine Richtung: Der Akteur, der sie heute nutzt, ist selektiver und fähiger als ein Massen-Scanner, nicht weniger.

Root-Cause-Analyse

Unsanitisierte Pfadkonstruktion aus Netzwerkeingaben (CWE-22): Der Syslog-Server leitet einen Dateipfad aus Daten ab, die über das Netzwerk eintreffen, ohne sie zu normalisieren oder das Ergebnis auf das vorgesehene Verzeichnis zu begrenzen. Das ist der älteste Datei-Handling-Fehler überhaupt, und er taucht in Log-Verarbeitungscode gerade deshalb immer wieder auf, weil Log-Daten als inerter Text statt als nicht vertrauenswürdige Eingabe behandelt werden.
Ein unauthentifizierter Listener auf einer Management-Appliance: Syslog-Collection hat keinen Authentifizierungsschritt, der fail-closed greifen könnte. Jedes Paket, das den Port erreicht, erreicht den Parser. Auf einer Appliance, deren gesamter Wert in der privilegierten Kontrolle der Umgebung besteht, ist das ein ungewöhnlich folgenreicher Ort, um anonyme Eingaben anzunehmen.
Write-Primitive an eine Stelle, die Ausführung ermöglicht: Ein Traversal, der lediglich in ein unbedeutendes Verzeichnis schreibt, wäre ein Integritätsproblem. Broadcom bewertet das Ergebnis als beliebige Codeausführung — das erreichbare Schreibziel liegt also an einem Ort, den die Appliance später ausführt oder interpretiert, wodurch aus einem Dateischreibvorgang eine RCE wird.
Die Reichweite des Dienstkontos: Der Code läuft im Kontext eines Dienstes auf der vCenter-Appliance. Auf einem System, dessen Zweck darin besteht, Hypervisor-Credentials zu halten und die Umgebung zu orchestrieren, ist selbst ein Nicht-Root-Dienstkontext eher eine Startrampe als eine Begrenzung.
Keine architektonische Trennung zwischen “Log-Collector” und “Management-Plane”: Der Syslog-Dienst teilt sich eine Appliance mit dem vSphere-Authentifizierungsstack, der Inventardatenbank und den Credentials für jeden verwalteten Host. Ein Fehler in der sicherheitsunkritischsten Komponente der Box erbt den Blast Radius der sicherheitskritischsten.
Keine kundenseitige Behebung außer Patchen: Da der Fehler im Parsing-Code liegt, gibt es keine unterstützte Einstellung zum Deaktivieren, keinen anwendbaren Filter und keinen Hardening-Guide-Eintrag, der ihn entfernt. Broadcoms Q&A beantwortet die Workaround-Frage mit einem einzigen Wort: nein.

Angriffsvektor

Die exakte Anfrage ist nicht öffentlich. Das folgende Diagramm zeigt die Form des Angriffs, rekonstruiert aus der Herstellerbeschreibung und dem beobachteten Post-Exploitation-Verhalten, damit Verteidiger einordnen können, wo ihre Kontrollen greifen. Es enthält keine Payload und ist kein Exploit.

# Illustratives Angriffsdiagramm -- KEIN funktionsfaehiger Exploit.
# Es werden keine Traversal-Payload, kein Nachrichtenformat und kein Zielpfad
# wiedergegeben; keines dieser Details ist oeffentlich. Nur die Form.

Externer Angreifer (kein Account, keine Credentials)
      |
      | (1) Den vCenter-Syslog-Listener erreichen. Standard-Syslog-Ports sind
      |     UDP/TCP 514 und TCP 1514 (TLS). Auf diesem Pfad existiert kein
      |     Authentifizierungsschritt -- Syslog nimmt an, was ankommt.
      v
vCenter Syslog-Server (vmware-syslog)
      |
      | (2) CVE-2026-59310: Durch den Angreifer beeinflussbare Daten werden
      |     zum Aufbau eines Dateipfads genutzt. Traversal-Sequenzen brechen
      |     aus dem vorgesehenen Log-Verzeichnis aus (CWE-22).
      v
Schreibvorgang ausserhalb des Log-Verzeichnisses, an eine vom Dienst
kontrollierte Stelle
      |
      | (3) Diese Stelle fuehrt zur Ausfuehrung. Broadcom: "may exploit this
      |     issue to execute arbitrary code."
      v
Codeausfuehrung auf der vCenter-Appliance
      |
      | (4) In freier Wildbahn beobachtet (QUIRSO): Ein Cron-Job wird zur
      |     Persistenz eingerichtet und startet den Open-Source-Client
      |     reverse_ssh, der AUSGEHEND zur Angreifer-Infrastruktur waehlt --
      |     eine eingehende Firewall-Regel ist also nicht noetig.
      v
Persistentes C2 auf der Management-Plane
      |
      | (5) Konsequenz, kein separater Exploit: vCenter ist die Autoritaet
      |     ueber jeden verwalteten ESX-Host und jede inventarisierte VM.
      v
Administrative Reichweite ueber die gesamte virtuelle Umgebung

Zwei Eigenschaften von Schritt (4) verdienen Betonung, weil sie die Detektion prägen. Erstens baut reverse_ssh eine ausgehende Verbindung auf. Ein Perimeter, der eingehenden Verkehr zu vCenter blockiert, richtet gegen einen von innen initiierten Kanal nichts aus. Zweitens ist reverse_ssh ein legitimes Open-Source-Penetrationstest-Werkzeug, keine maßgeschneiderte Malware. QUIRSO sagt das in den Metadaten der eigenen Detection-Rule direkt: “This is a dual-use tool signature. A match identifies reverse_ssh code; maliciousness must be established from deployment context and telemetry.” Auf einer vCenter-Appliance ist der Fund trotzdem nicht mehrdeutig — es gibt keinen legitimen Grund, warum ein Reverse-Shell-Framework auf einer vCenter Server Appliance liegen sollte.

Ausnutzung in freier Wildbahn

Die Chronologie ist ungewöhnlich eng getaktet, und die Uneinigkeit zwischen den Quellen ist selbst Teil der Geschichte.

Die Veröffentlichung war der Startschuss. Broadcom publizierte VMSA-2026-0006 am 29. Juli 2026. QUIRSO beobachtete die ersten kompromittierten Systeme im Kontakt mit angreiferkontrollierter Infrastruktur am 3. August 2026 — fünf Tage später. Ihre Einschätzung ist unmissverständlich: “the strong correlation between the time of disclosure and exploitation suggests the disclosure as the initial starting point for the campaign.”
Die Kurve verlief nahezu senkrecht. Der 4. August brachte 151 neue Opfer-IPs an einem einzigen Tag. Bis zum 5. August waren bereits rund 95 % aller identifizierten Opfer (343 von 361) aufgetaucht. Bis zum 7. August stand die Gesamtzahl bei 361 Opfer-IP-Adressen in 47 Ländern. Das ist eine Kampagne, die ihre Zielliste in etwa 72 Stunden gesättigt hat.
Es handelt sich um Kompromittierungen, nicht um Scans. Die Zahl 361 zählt Hosts, die beim Kommunizieren mit Angreifer-Infrastruktur beobachtet wurden — erfolgreiche Einbrüche, keine Exploit-Versuche gegen einen Honeypot.
Deutschland führt die Liste der betroffenen Länder an. Die Top fünf — Deutschland, USA, Türkei, Iran und Frankreich — machen 185 der 361 Opfer-IPs aus, mehr als die Hälfte der Gesamtzahl.
Der Persistenzmechanismus ist Dual-Use-Tooling. Angreifer richten einen bösartigen Cron-Job ein, der reverse_ssh startet, ein Open-Source-Reverse-Shell-Framework auf SSH-Basis, das ihnen einen ausgehenden Kommandokanal verschafft, der Neustarts übersteht und eingehende Firewall-Policies umgeht.
Die Attribution ist ungeklärt. QUIRSO geht von einem mutmaßlichen APT-Akteur aus, hat aber keinen benannt. Bemerkenswert: Als Grund für das Zurückhalten der granularen Indikatoren nennen sie die Abstimmung mit Strafverfolgungspartnern — der öffentliche IoC-Satz ist also bewusst dünn.
Hersteller und Forscher sind sich nicht einig. Broadcoms Q&A-Dokument zu VMSA-2026-0006 hält fest: “Broadcom has no information to suggest that exploitation of these issues has occurred in the wild.” Dieses Dokument ist die Hersteller-Ergänzung zum Advisory und wurde nicht um QUIRSOs Erkenntnisse aktualisiert. Ebenso hat die CISA CVE-2026-59310 nicht in den KEV-Katalog aufgenommen — wir haben das gegen KEV-Katalogversion 2026.08.17 (1.666 Einträge) geprüft. Behandeln Sie das Fehlen eines KEV-Eintrags als Lücke in einer Meldekette, nicht als Beleg für Sicherheit.

Post-Exploitation-Auswirkungen

Vollständige Kontrolle über die vCenter-Appliance: Die Credentials, die vCenter für verwaltete ESX-Hosts hält, seine Inventardatenbank, seine Zertifikate und seine Identity-Source-Konfiguration müssen alle als kompromittiert gelten.
Administrative Autorität über jede verwaltete virtuelle Maschine: Snapshot, Klon, Umkonfiguration, Power-Cycle oder Einhängen der virtuellen Festplatten jeder VM im Inventar — einschließlich Domain Controller, Backup-Server und Sicherheitswerkzeuge.
Datastore-Zugriff auf VM-Festplatten: Das Einhängen einer VMDK umgeht jede Kontrolle innerhalb des Gastsystems. Verschlüsselung ruhender Daten auf dem Datastore hilft nicht, wenn die Anfrage von der Plattform kommt, die die Schlüssel hält.
Persistenz, die das Patchen überlebt: Der Cron-Job und die reverse_ssh-Binary liegen im Dateisystem der Appliance. Die Installation von 9.1.0.0300 schließt die Tür; sie wirft niemanden hinaus, der bereits drinnen ist.
Ein Pivot in die Gast-Umgebung: Von Hypervisor-Zugriff aus erreicht ein Angreifer Gastsysteme, die von seiner ursprünglichen Position aus nie netzwerkerreichbar waren.
Zerstörung des Wiederherstellungspfads: Ein Akteur mit vCenter-Autorität kann Snapshots löschen, VMs deregistrieren und Backup-Infrastruktur angreifen — genau das Ransomware-Playbook für virtualisierte Umgebungen.
Manipulation von Logging und Sichtbarkeit: Die Kompromittierung des Log-Collectors gibt einem Angreifer eine naheliegende Möglichkeit, zu beeinflussen, was die Umgebung über ihn aufzeichnet.

⚠️ Impact-Bewertung

Unmittelbare Auswirkungen

Unauthentifizierte Remote Code Execution auf der Management-Plane der virtuellen Umgebung, ohne Benutzerinteraktion.
Kein Workaround. Broadcom ist eindeutig. Netzwerkbeschränkung reduziert die Exposition; nur der Patch behebt.
Eine laufende Kampagne mit einer 72-Stunden-Sättigungskurve, konzentriert auf Deutschland, die USA, die Türkei, den Iran und Frankreich.
Die Alarmierung, auf die Sie sich verlassen, greift möglicherweise nicht. Kein KEV-Eintrag und ein Hersteller-Q&A, das weiterhin von keiner bekannten Ausnutzung spricht. Priorisierungsprozesse, die an diesen Signalen hängen, bewerten diese CVE zu niedrig.
Patchen ist notwendig, aber nicht hinreichend. Wenn Ihr vCenter zwischen dem 29. Juli und dem Tag Ihres Patches aus dem Internet erreichbar und ungepatcht war, schulden Sie sich selbst eine Compromise Assessment.

Betroffene Versionen

Produkt / Branch	Status	Behobene Version
VMware vCenter 9.1.x	Verwundbar vor Fix	9.1.0.0300
VMware vCenter 9.0.x	Verwundbar vor Fix	9.0.2.0100
VMware vCenter 8.0 (U3-Linie)	Verwundbar vor Fix	8.0 U3k (Build 25600417, veröffentlicht 2026-07-29)
VMware vCenter 8.0 (U2-Linie)	Verwundbar vor Fix	8.0 U2f (ergänzt in VMSA-2026-0006.1)
VMware vSphere / vCenter 7.0	Betroffen — nach End of General Support (2025-10-02)	Extended-Support-Vertrag erforderlich; Broadcom drängt auf Upgrade
VMware Cloud Foundation 5.x, 9.0.x, 9.1.x	Verwundbar vor Fix	Siehe VMSA für das VCF-spezifische Bundle
VMware vSphere Foundation 9.0.x, 9.1.x	Verwundbar vor Fix	9.0.2.0100 / 9.1.0.0300
VMware Telco Cloud Platform 3.0-5.1.x, Telco Cloud Infrastructure 3.0	Verwundbar vor Fix	Den im VMSA verlinkten Anweisungen folgen

Broadcom weist darauf hin, dass Patches kumulativ sind — jede Version, die neuer ist als die aufgeführten, behebt das Problem ebenfalls, und es muss kein vorheriger Patch installiert werden. Zwei betriebliche Einschränkungen aus den Release Notes: Diese Updates sind nicht für vCenter Quick Patch geeignet, und ein Upgrade von vCenter 8.0 U3k auf vCenter 9.1.0 (oder einen auf 9.1.0 basierenden Patch) wird zum Release-Zeitpunkt nicht unterstützt — eine “Back-in-Time”-Einschränkung, die einzuplanen ist, falls 9.1 auf Ihrer Roadmap steht. Prüfen Sie stets gegen das offizielle VMSA, das Broadcom als Source of Truth bezeichnet.

Weitere CVEs im selben Advisory — VMSA-2026-0006 ist ein Bündel aus fünf Problemen, und das Patchen für CVE-2026-59310 erledigt auch den Rest der vCenter-Seite:

CVE	Komponente	CVSS 3.1	Zusammenfassung
CVE-2026-59309	VMware Directory Service (vCenter)	9.8	Unauthentifizierter Authentication Bypass
CVE-2026-59310	vCenter Syslog-Server	9.8	Directory Traversal zu beliebiger Codeausführung
CVE-2026-47876	ESX VMXNET3-Adapter	9.3	Out-of-Bounds Write — ein echter VM-Escape von Gast-Admin zum Host
CVE-2026-41703	ESX / Workstation / Fusion	2.7-7.6	Out-of-Bounds Read: Informationsabfluss oder DoS im Host-Prozess
CVE-2026-41709	ESX	2.7	Unzureichendes Logging — Administratoraktionen werden nicht aufgezeichnet

Betroffene Umgebungen

Jedes vCenter, das aus einem für Angreifer erreichbaren Netz erreichbar ist. Aus dem Internet exponierte Management-Interfaces sind der akute Fall, aber ein flaches internes Netz, in dem jede Workstation zu vCenter routen kann, ist dasselbe Problem mit längerer Zündschnur.
Umgebungen, in denen der Syslog-Collector aktiviert und erreichbar ist — oft einmal beim Deployment konfiguriert und nie wieder angefasst.
Service Provider und mandantenfähige Umgebungen: Ein vCenter, das die Workloads vieler Kunden steuert, konzentriert den Blast Radius enorm.
Telco-Umgebungen: Telco Cloud Platform und Telco Cloud Infrastructure enthalten beide vCenter und sind beide betroffen.
Organisationen, die noch vSphere 7.0 einsetzen — betroffen, seit dem 2. Oktober 2025 außerhalb des General Support und auf einen Extended-Support-Vertrag angewiesen, um überhaupt einen Fix zu erhalten.
Umgebungen mit langsamer Change-Control-Kadenz für Management-Infrastruktur: vCenter-Patching erfordert oft ein Wartungsfenster, das mit allem anderen konkurriert. Dieses hier unterbricht laufende Workloads nicht (siehe unten), womit die übliche Ausrede entfällt.

Angreiferprofile

Staatlich gesponserte Akteure: QUIRSOs Einschätzung deutet auf einen APT hin. Hypervisor-Management ist ideales Terrain für langlebige Spionage — es gewährt Zugriff auf alles und liegt zugleich unterhalb der Endpoint-Werkzeuge, die es normalerweise sehen würden.
Ransomware-Betreiber: Verschlüsselung auf Hypervisor-Ebene ist der effizienteste verfügbare Angriff gegen eine virtualisierte Umgebung, und vCenter ist der kürzeste Weg dorthin. Das persistenzorientierte Verhalten der aktuellen Kampagne passt sowohl zu Spionage als auch zu Vorbereitung späterer Monetarisierung.
Initial Access Broker: Administrativer vCenter-Zugriff ist erstklassige, weiterverkäufliche Ware.
Opportunistische Akteure, später: Heute existiert kein öffentlicher PoC. Wenn einer auftaucht — und bei einem so wertvollen Bug tut er das irgendwann — reduziert sich die Ausnutzung auf einen skriptgesteuerten Scan gegen jeden erreichbaren Syslog-Port im Internet.

🛡️ Gegenmaßnahmen

Sofortmaßnahmen (Priorität 1) ⚡

Ermitteln Sie Ihre exakte vCenter-Version und den Build. Broadcom dokumentiert zwei Methoden. Im vSphere Client steht der Build auf dem Reiter Summary. Über PowerCLI verbinden Sie sich und lesen die Eigenschaften des Verbindungsobjekts:

# Von Broadcom dokumentierte PowerCLI-Methode (VMSA-2026-0006 Q&A, Frage 25).
Connect-VIServer -Server vcenter.example.com

# Versionsstring, z. B. 8.0.3
$global:DefaultVIServer.Version

# Build-Nummer, z. B. 25600417 fuer vCenter 8.0 U3k
$global:DefaultVIServer.Build

# Solange Sie verbunden sind: ESX ist von drei weiteren CVEs desselben
# Advisories betroffen. Von Broadcom dokumentierte Host-Pruefung (Frage 26):
Get-VMHost | Select-Object Name,Version,Build

Dieselbe Information liefert die vSphere Automation REST API, was praktisch ist, wenn Sie viele vCenter inventarisieren:

# 1) API-Session anlegen. Fragt nach dem Passwort; liefert eine Session-ID.
#    -s still, -k ueberspringt die Zertifikatspruefung (ohne -k, sobald Sie
#    dem Zertifikat vertrauen), -u setzt den Benutzernamen, -X POST die Methode.
curl -sk -u 'administrator@vsphere.local' -X POST \
  https://vcenter.example.com/api/session

# 2) Appliance-Version mit dieser Session-ID auslesen.
#    Liefert JSON mit "version" und "build".
curl -sk -H 'vmware-api-session-id: <session-id-aus-schritt-1>' \
  https://vcenter.example.com/api/appliance/system/version

Vergleichen Sie das Ergebnis mit der Versionstabelle oben.

Patchen. Es gibt keine Alternative. Installieren Sie je nach Branch 9.1.0.0300, 9.0.2.0100, 8.0 U3k oder 8.0 U2f — über die VAMI oder Ihren üblichen vSphere-Update-Mechanismus. Zwei Fakten machen das gegenüber dem Change Management leichter zu vertreten als die meisten Notfall-Patches:
- Ein vCenter-Update unterbricht laufende Workloads nicht. Broadcom sagt das klar: Sie verlieren den vSphere Client und andere Management-Schnittstellen kurzzeitig, virtuelle Maschinen und Container laufen weiter.
- Patches sind kumulativ. Sie müssen keine Zwischen-Patches zuerst installieren; ein Update bringt Sie auf den aktuellen Stand.
Beachten Sie, dass diese Updates nicht für vCenter Quick Patch geeignet sind — planen Sie den konventionellen Update-Pfad ein.

Klären Sie, ob der Syslog-Listener läuft und wer ihn erreichen kann. Auf der Appliance dokumentiert Broadcom service-control für den Dienststatus:

# Auf der Shell der vCenter Server Appliance (SSH als root).
# 'service-control' ist das dokumentierte VCSA-Werkzeug zur Dienstverwaltung.
service-control --status vmware-syslog

# Vollstaendiges Bild dessen, was auf der Appliance laeuft.
service-control --status --all

Prüfen Sie anschließend die Erreichbarkeit von außerhalb Ihres Management-Netzes — entscheidend ist nicht, was die Appliance denkt, sondern was ein Angreifer anfassen kann:

# Von einem Host AUSSERHALB des vorgesehenen Management-Netzes.
# -Pn ueberspringt die Host-Discovery, -sU scannt UDP, -p 514 prueft den
# Syslog-Port. (UDP-Scans sind langsam; --reason erklaert den Portstatus.)
sudo nmap -Pn -sU -p 514 --reason <vcenter-ip>

# TCP-Syslog- und TLS-Syslog-Ports.
nmap -Pn -p 514,1514 --reason <vcenter-ip>

# Und gleich noch das Management-Interface selbst.
nmap -Pn -p 443 --reason <vcenter-ip>

Alles außer filtered/closed aus einem nicht vertrauenswürdigen Netz ist unabhängig von dieser CVE ein Befund.

War die Appliance nach dem 29. Juli erreichbar und ungepatcht, jagen Sie, bevor Sie Entwarnung geben. Die beobachtete Persistenz besteht aus einem Cron-Job plus einer reverse_ssh-Binary. Auf der Appliance-Shell:

# Alle folgenden Befehle laufen auf der Appliance-Shell als root
# (crontab -u erfordert Privilegien; ohne root ein sudo voranstellen).

# Crontab von root -- der beobachtete Persistenzmechanismus.
crontab -l -u root

# Systemweite Cron-Orte auf der Photon-OS-basierten Appliance.
ls -la /etc/cron.d/ /etc/cron.hourly/ /etc/cron.daily/ /var/spool/cron/

# Nach den ueblichen Download-and-Run-Mustern in Cron-Definitionen suchen.
# -R rekursiv, -n zeigt Zeilennummern, -I ueberspringt Binaerdateien,
# -E aktiviert erweiterte regulaere Ausdruecke.
grep -R -n -I -E '(curl|wget|/tmp/|base64|nc |ssh -R)' \
  /etc/cron.d /etc/cron.daily /etc/cron.hourly /var/spool/cron 2>/dev/null

# Kuerzlich hinzugefuegte oder geaenderte systemd-Units -- ein alternativer
# Persistenzort. -l lange Auflistung, -t sortiert nach mtime (neueste zuerst).
ls -lt /etc/systemd/system/

# Dateien, die seit dem Advisory-Datum auf die Appliance geschrieben wurden.
# -newermt erwartet eine Datumsangabe; -type f begrenzt auf regulaere Dateien.
find /tmp /var/tmp /usr/local /opt -xdev -type f -newermt '2026-07-29' \
  -printf '%T+ %p\n' 2>/dev/null | sort

Suchen Sie den ausgehenden Kanal. reverse_ssh wählt nach außen, also zeigt sich das in der Egress-Telemetrie:
```
# Aufgebaute ausgehende TCP-Verbindungen der Appliance.
# -t nur TCP, -n numerisch (kein DNS), -p zeigt den besitzenden Prozess.
ss -tnp state established

# Alles, was lauscht und nicht von Ihnen stammt.
ss -tlnp
```
Eine vCenter-Appliance hat ein kleines, vorhersagbares Egress-Profil: Ihre ESX-Hosts, Ihr Identity Provider, Ihre NTP- und DNS-Server, Broadcom-Update-Endpunkte. Alles andere ist erklärungsbedürftig.
Gehen Sie bei einem Fund von kompromittierten Credentials aus. vCenter hält Credentials für verwaltete ESX-Hosts, Dienstkonten und Identity-Source-Integrationen. Eine bestätigte Kompromittierung bedeutet, all diese zu rotieren, Appliance-Zertifikate zu ersetzen und die vCenter-Berechtigungen auf Konten zu prüfen, die Sie nicht angelegt haben.

Detektionsmaßnahmen 🔍

QUIRSO hat eine YARA-Regel für den reverse_ssh-Client in ihrem QTRDetectionContent-Repository veröffentlicht. Führen Sie sie gegen eine Kopie des Appliance-Dateisystems aus — einen auf einem Analyse-Host eingehängten Snapshot — statt Scan-Werkzeuge auf einem produktiven vCenter zu installieren:

# Auf einem Analyse-Host, gegen eine eingehaengte Kopie/Snapshot der Appliance.
# -r rekursiv in Verzeichnisse, -s gibt die Treffer-Strings zur Triage aus.
yara -r -s 2026-08-10_reverse_ssh_generic.yar /mnt/vcsa-snapshot

Die Regel setzt an Go-Build-Metadaten sowie an stabilen github.com/NHAS/reverse_ssh-Paketpfaden und Client-Strings an. QUIRSOs eigener Vorbehalt ist wichtig und wiederholenswert: Es handelt sich um eine Dual-Use-Tool-Signatur, ein Treffer identifiziert also reverse_ssh-Code, nicht automatisch bösartige Aktivität. Auf einer vCenter-Appliance gibt es allerdings keine gutartige Erklärung.

Eine portable Sigma-Regel für das Persistenzverhalten, falls Sie Appliance-Telemetrie an ein SIEM weiterleiten:

title: Suspicious Cron or Reverse Shell Persistence on VMware vCenter Appliance
status: experimental
description: >
  Erkennt Persistenzmuster, die zur von QUIRSO gemeldeten CVE-2026-59310-Kampagne
  passen: ein auf der vCenter Server Appliance eingerichteter Cron-Job, der den
  Open-Source-Client reverse_ssh fuer ausgehendes C2 startet.
references:
  - https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/38017
  - https://github.com/QUIRSO/QTRDetectionContent
logsource:
  product: linux
  service: syslog
detection:
  keywords_cron:
    - 'CRON'
    - 'crontab'
  keywords_tooling:
    - 'reverse_ssh'
    - 'ssh -R'
    - '/tmp/'
  condition: keywords_cron and keywords_tooling
falsepositives:
  - Legitime, von Administratoren angelegte Cron-Jobs auf der Appliance (sollte es nicht geben)
  - Autorisierte Penetrationstests unter Einsatz von reverse_ssh
level: high

Weitere Hunting-Ansätze:

Prüfen Sie Appliance-Logs ab dem 29. Juli. vCenter-Logs liegen unter /var/log/vmware/; listen Sie sie nach Änderungszeit auf (ls -lt /var/log/vmware/) und achten Sie besonders auf das Verzeichnis des Syslog-Dienstes sowie auf alles, was unerwartet stoppt oder neu startet.
Retrospektive Netflow-Analyse. Durchsuchen Sie Ihre Flow-Daten nach ausgehenden Verbindungen von vCenter-Management-IPs zu Zielen außerhalb Ihres Known-Good-Sets, spätestens zurück bis zum 3. August 2026 — QUIRSOs erstem beobachteten Opferkontakt.
Prüfen Sie eingehende Flows auf die Ports 514 und 1514 auf vCenter von jeder Quelle außerhalb Ihrer ESX-Umgebung. Ihre Hosts sollten die Einzigen sein, die Syslog an vCenter senden.
Auditieren Sie vCenter-Konten und -Berechtigungen auf Ergänzungen oder Rollenänderungen, die Sie keinem Change-Ticket zuordnen können.
Vergleichen Sie die ESX-Host-Konfiguration mit einer bekannten Baseline. Beachten Sie: CVE-2026-41709 aus demselben Advisory ist eine Insufficient-Logging-Schwachstelle — Administratoraktionen auf ESX, die nicht aufgezeichnet wurden. Gehen Sie nicht davon aus, dass ESX-Audit-Logs für diesen Zeitraum vollständig sind.
Behandeln Sie ungepatchte, aus dem Internet erreichbare vCenter als kompromittiert, bis das Gegenteil bewiesen ist. Das ist die Empfehlung der Forscher, nicht unsere — und angesichts einer 72-Stunden-Sättigungskurve die richtige Voreinstellung.

Langfristige Sicherheitsverbesserungen

Legen Sie die Hypervisor-Management-Plane in ein isoliertes Netz. vCenter, ESX-Management-Interfaces und der Syslog-Collector gehören in ein dediziertes Out-of-Band-Administrationsnetz, das nur über einen gehärteten Jump Host erreichbar ist. Diese CVE hat keinen Workaround — aber ein Angreifer, der keine Pakete zu Port 514 routen kann, kann sie auch nicht ausnutzen.
Inventarisieren Sie unauthentifizierte Listener auf Ihren Appliances. Jede Management-Appliance in Ihrer Umgebung betreibt Dienste, die Sie nicht bewusst aktiviert haben. Erfassen Sie sie (ss -tlnp und die Dienstwerkzeuge des Herstellers), entscheiden Sie, welche von wo erreichbar sein müssen, und filtern Sie den Rest auf Netzwerkebene.
Behandeln Sie Log-Collectors als Angriffsfläche. Ein Syslog-Server ist ein Parser, der mit nicht vertrauenswürdigen Eingaben aus dem Netz gefüttert wird. Er verdient dieselbe Aufmerksamkeit wie jeder andere exponierte Parser — und sollte sich möglichst keine Appliance mit den Credentials Ihrer gesamten Umgebung teilen.
Geben Sie Management-Infrastruktur die schnellste Patch-SLA, die Sie haben. Die Branchengewohnheit lautet: Workload patchen, Manager verschieben. Diese Kampagne war 72 Stunden nach ihrem Start gesättigt — fünf Tage nach Disclosure. Ein monatliches Wartungsfenster ist dagegen keine Verteidigung.
Bauen Sie Ihre Priorisierung auf mehr als KEV auf. CVE-2026-59310 wird weltweit ausgenutzt und steht nicht im KEV. KEV ist ein wertvolles und zugleich nachlaufendes Signal; eine unauthentifizierte CVSS-9.8-RCE auf Ihrem Hypervisor-Manager rechtfertigt Notfallbehandlung schon aus der Sache heraus.
Verabschieden Sie sich von Versionen außerhalb des Supports. vSphere 7.0 ist betroffen und außerhalb des General Support. “Wir haben einen Extended-Support-Vertrag” ist ein Plan; “wir sind noch auf 7.0 und hoffen das Beste” nicht.
Üben Sie Hypervisor-Kompromittierung in Tabletop-Exercises. Stellen Sie die unangenehme Frage ausdrücklich: Wenn vCenter nicht mehr vertrauenswürdig ist, wie stellen wir wieder her? Wo liegen die Backups, sind sie von vCenter aus erreichbar, und können wir ohne vCenter neu aufbauen? Die meisten Organisationen erfahren die Antwort während des Vorfalls.
Überwachen Sie den Egress von Management-Appliances. Ausgehendes C2 von einem vCenter ist eine der signalstärksten und rauschärmsten verfügbaren Detektionen — gerade weil eine gesunde Appliance mit so wenigen Zielen spricht.

🎯 Warum ist das kritisch?

Unauthentifizierte Codeausführung auf dem System, das alles andere steuert. Eine vCenter-Kompromittierung ist keine Lateral Movement — sie ist die Ankunft am Ziel.
Es gibt keinen Workaround. Broadcom sagt das in einem Wort. Segmentierung hilft; nur der Patch behebt.
Es wird gerade jetzt in großem Maßstab ausgenutzt. 361 kompromittierte Hosts in 47 Ländern, davon 95 % innerhalb eines einzigen 72-Stunden-Fensters.
Deutschland führt die Liste der betroffenen Länder an. Für unsere Kunden und Leser ist das keine ferne Statistik.
Die Ausnutzung begann fünf Tage nach dem Patch. Das Fenster zwischen “Advisory veröffentlicht” und “Kampagne läuft” war kürzer als eine Woche — kürzer als der Change-Genehmigungsprozess vieler Organisationen.
Die offiziellen Signale bewerten es zu niedrig. Kein CISA-KEV-Eintrag und ein Hersteller-Q&A, in dem weiterhin “no information to suggest exploitation in the wild” steht. Eine Priorisierungskette, die auf diesen Eingaben beruht, reiht diese CVE hinter Dinge ein, die weniger wichtig sind.
Persistenz überlebt den Patch. Ein Cron-Job und eine reverse_ssh-Binary interessiert Ihr Upgrade nicht. Patchen ohne Hunting lässt den Angreifer an Ort und Stelle — auf einer frisch gehärteten Appliance.
Das Advisory enthält außerdem einen VM-Escape. CVE-2026-47876 aus demselben VMSA erlaubt einem Administrator innerhalb eines Gastsystems, Code auf dem ESX-Host auszuführen. Wer das hier als “nur die vCenter-Sache” abhandelt, lässt die Hypervisor-Hälfte des Problems ungepatcht.

🚀 Zeitleiste und Disclosure

2025-10-02 — VMware vSphere 7.0 erreicht das End of General Support und legt damit den Kontext dafür, warum 7.0-Anwender einen Extended-Support-Vertrag benötigen, um einen Fix zu erhalten.
2026-07-29 — Broadcom veröffentlicht VMSA-2026-0006 mit fünf CVEs, darunter CVE-2026-59310 (CVSS 9.8) und CVE-2026-59309 (CVSS 9.8). vCenter 8.0 U3k (Build 25600417), 9.0.2.0100 und 9.1.0.0300 erscheinen. Für keine der fünf Schwachstellen existiert ein Workaround. Die Anerkennung für beide vCenter-Probleme geht an Phil Brass und Matt South von Atredis Partners.
2026-07-30 — Der NVD-Eintrag zu CVE-2026-59310 wird veröffentlicht, mit CVSS 3.1 9.8 und CWE-22.
2026-08-03 — VMSA-2026-0006.1 erscheint und ergänzt vSphere-8.0-Update-2-Patches (8.0 U2f). Am selben Tag beobachtet QUIRSO die ersten kompromittierten Systeme im Kontakt mit Angreifer-Infrastruktur — fünf Tage nach Disclosure.
2026-08-04 — 151 neue Opfer-IPs tauchen an einem einzigen Tag auf.
2026-08-05 — 343 der letztlich 361 Opfer-IPs (~95 %) sind beobachtet. Die Kampagne ist faktisch gesättigt.
2026-08-07 — Die Opferzahl erreicht 361 IPs in 47 Ländern, wobei Deutschland, die USA, die Türkei, der Iran und Frankreich 185 davon ausmachen.
2026-08-10 — QUIRSO veröffentlicht eine generische YARA-Regel für den NHAS-reverse_ssh-Client in ihrem öffentlichen Detection-Content-Repository.
2026-08-12 — QUIRSO veröffentlicht die Kampagnenanalyse. Die Berichterstattung folgt bei BleepingComputer, The Hacker News, SecurityWeek, Dark Reading und Infosecurity Magazine.
2026-08-14 — Der NVD-Eintrag wird zuletzt geändert.
2026-08-17 — CVE-2026-59310 fehlt weiterhin im CISA-KEV-Katalog (geprüft gegen Katalogversion 2026.08.17, 1.666 Einträge), und Broadcoms Advisory-Q&A gibt weiterhin an, keine Ausnutzung in freier Wildbahn zu kennen.

🔗 Ressourcen und Referenzen

CVE: CVE-2026-59310
NVD: NVD — CVE-2026-59310
Hersteller-Advisory: VMSA-2026-0006.1 — Broadcom Support
Hersteller-Q&A-Ergänzung: VMSA-2026-0006 Questions & Answers — vmware/vcf-security-and-compliance-guidelines
CWE: CWE-22: Improper Limitation of a Pathname to a Restricted Directory
CISA-KEV-Katalog: Known Exploited Vulnerabilities — nicht gelistet, Stand Katalogversion 2026.08.17
Detection Content: QUIRSO QTRDetectionContent — reverse_ssh YARA-Regel
Verwandt: CVE-2026-59309 (vCenter Authentication Bypass, CVSS 9.8) und CVE-2026-47876 (ESX VMXNET3 VM-Escape, CVSS 9.3) — dasselbe Advisory

💼 SEKurity Unterstützt Sie

CVE-2026-59310 ist eine saubere Illustration eines Musters, das wir in Assessments immer wieder sehen: Die gefährlichste Exposition in einer Umgebung ist selten die Anwendung, um die sich alle sorgen. Es ist der vergessene Dienst auf der Management-Appliance — ein Log-Collector, ein Agent-Listener, eine Alt-API — der unauthentifizierte Eingaben aus einem Netzsegment entgegennimmt, das seit Jahren niemand auditiert hat. Niemand rollt einen Syslog-Collector aus und denkt dabei an Angriffsfläche, und doch sitzt er genau hier, auf der Appliance, die die Schlüssel zu jeder virtuellen Maschine der Umgebung hält. Die Kampagne rund um diese CVE zeigt außerdem, wie stark sich die Zeitachsen verdichtet haben: fünf Tage vom Hersteller-Advisory bis zur aktiven Ausnutzung und 72 Stunden von dort bis zur weltweiten Sättigung. Das ist schneller, als die meisten Organisationen ein Change Advisory Board einberufen können. Wir helfen Kunden, genau diese Lücke zu schließen — indem wir kartieren, welche Management-Planes tatsächlich und aus welchen Netzen erreichbar sind, die unauthentifizierten Listener auf Infrastruktur-Appliances erfassen, die Inventarwerkzeuge routinemäßig übersehen, in der Praxis testen, ob sich ein Fußabdruck auf der Virtualisierungsschicht in umgebungsweite Kontrolle umwandeln lässt, und validieren, ob ausgehendes C2 von einer Management-Appliance tatsächlich einen Alarm auslöst statt einer Logzeile, die niemand liest. Unsere Perimeter- und Infrastruktur-Penetrationstests behandeln Hypervisor-Management als primäres Ziel — denn genau so behandeln es reale Angreifer.

Unsere Leistungen

Penetration Testing: Webanwendungen, mobile Apps (Android & iOS), SAP-Systeme, Active Directory
Groß angelegte Angriffe: Perimeter-Tests, IT-Infrastruktur-Tests, Red-Team-Engagements
Security Awareness: Phishing-Kampagnen, Hacking-Demonstrationen

Handeln Sie jetzt — bevor es Angreifer tun.

Kontakt:

🌐 Website: www.sekurity.de

📧 Anfragen: www.sekurity.de/kontakt

📱 LinkedIn: SEKurity GmbH

Ihr SEKurity Team — Your Trusted Adversaries

Die Sicherheit Ihrer Virtualisierungsinfrastruktur ist unser Antrieb.

InSEKurity of the Week (KW33/2026): VMware vCenter Syslog Directory Traversal (CVE-2026-59310)