VMware vCenter CVE-2026-59310 unter globaler APT-Ausnutzung

Jeder Plattformverantwortliche, der eine virtualisierte Infrastruktur betreibt, hat einen Albtraum auf der Liste: ein nicht authentifiziertes RCE in der Hypervisor-Managementebene. Dieser Albtraum hat diesen Monat eine CVE-Nummer – und wird bereits in 47 Ländern von einem einzigen mutmaßlichen APT ausgenutzt.

Kurz zusammengefasst: VMware hat CVE-2026-59310 am 29. Juli offengelegt. Bis zum 3. August befand sich ein Bedrohungsakteur bereits in echten Produktionsumgebungen. Am 4. August erreichte die Aktivität ihren Höhepunkt. Und der Angreifer hat eine Persistenz hinterlegt, die den Patch überlebt, den Sie gerade deployen wollten.

Was passiert ist

CVE-2026-59310 ist eine kritische Directory-Traversal-Schwachstelle in VMware vCenter mit einem CVSS-Score von 9,8. Wie Dark Reading berichtete, legte Broadcom-eigene VMware die Schwachstelle am 29. Juli offen und warnte, dass jeder Angreifer mit Netzwerkzugang zu einer vCenter-Instanz beliebigen Code aus der Ferne innerhalb der virtuellen Umgebung des Ziels ausführen kann. Das ist die schlimmste Kategorie von vCenter-Fehlern: nicht authentifiziert, remote und auf die Steuerungsebene der gesamten Hypervisor-Flotte gerichtet.

Fünf Tage später, am 3. August, begann die Ausnutzung. Das deutsche Incident-Response-Unternehmen QUIRSO deckte die Aktivität während eines Kundeneinsatzes auf und veröffentlichte diese Woche seine Erkenntnisse. Das Threat-Research-Team führt die Kampagne auf einen einzigen mutmaßlichen Advanced-Persistent-Threat-Akteur zurück und verfolgte Infrastruktureinschläge in 47 verschiedenen Ländern. Die USA, Frankreich, Iran und die Türkei sind die am stärksten betroffenen Ziele. QUIRSO identifizierte 361 eindeutige IP-Adressen, die mit der Kampagne verbunden sind, obwohl das Unternehmen anmerkte, dass einige zu Cloud- oder Hosting-Anbietern gehören, die Infrastruktur teilen – die Opferzahl ist also keine Eins-zu-eins-Zuordnung.

Die Kampagne erreichte am 4. August ihren Höhepunkt und läuft noch immer. „Wir sehen immer noch neue Opfer, die sich mit der vom Angreifer kontrollierten reverse_ssh-Infrastruktur verbinden, und die Angreifer scheinen nicht zu wissen, dass wir sie beobachten", sagte QUIRSO-COO und Mitgründer Denis Szadkowski gegenüber Dark Reading. Er fügte hinzu, dass neue Opfer weiterhin auftauchen, nur in langsamerem Tempo, da der nicht gepatchte Pool schrumpft. QUIRSO weist auch auf die Möglichkeit hin, dass der Akteur die Schwachstelle vor der öffentlichen Offenlegung kannte, obwohl das Timing sauber mit einem Patch-Diffing nach Veröffentlichung des Advisories übereinstimmt. Den Eintrag können Sie in der CVE-Datenbank nachschlagen, und er gehört auf die CISA KEV-Liste, falls er dort noch nicht steht.

Technische Analyse

Directory Traversal zu RCE auf einer Management-Ebene ist nicht exotisch. Entscheidend ist hier die zweite Stufe. Der Bedrohungsakteur etabliert Post-Exploitation-Persistenz über reverse_ssh, ein Open-Source-Penetrationstest-Tool, das ausgehende Kontrollkanäle von kompromittierten Systemen erstellt. Ausgehend. Das ist der gesamte Trick.

Die meisten vCenter-Deployments, die ich in der Produktion gesehen habe, sind auf der Eingangsseite abgesichert. Management-VLANs, Jump-Hosts, IP-Allowlists auf Port 443. Aber der ausgehende Datenverkehr vom vCenter-Appliance selbst? Meistens weit offen für alles, was das Appliance für Updates, Telemetrie und NTP benötigt. reverse_ssh nutzt diese Asymmetrie aus. Das kompromittierte vCenter stellt eine Verbindung zur Angreifer-Infrastruktur her und hält einen Kontrollkanal offen. Ihre Firewall sieht eine etablierte ausgehende Verbindung, keinen eingehenden Einbruch.

Hier ist das operativ unangenehme Detail: Das Patchen von CVE-2026-59310 vertreibt den Angreifer nicht. Szadkowski war eindeutig: Wenn reverse_ssh vor dem Patchen installiert wurde, „bleibt der Zugang des Angreifers auch nach der Aktualisierung der Software auf eine gepatchte Version bestehen." Der Tunnel lebt außerhalb des verwundbaren Code-Pfads. Sobald man einen Fuß in der Tür und ausgehende Erreichbarkeit hat, braucht man die Schwachstelle nicht mehr.

Szadkowski entkräftet auch die Annahme, dass nur VMware-Spezialisten das in fünf Tagen hätten bewerkstelligen können. „Fähige Schwachstellenforscher und fortgeschrittene Akteure führen nach der Offenlegung häufig Patch-Diffing durch. Wir halten es für realistisch, dass ein ausreichend fähiger Forscher den Patch analysieren und innerhalb der fünf Tage zwischen dem Advisory und dem von uns untersuchten Einbruch einen Exploit entwickeln könnte." Übersetzt: In dem Moment, in dem Broadcom den Fix auslieferte, begann der Countdown. QUIRSO hat eine YARA-Regel zur Identifizierung von reverse_ssh-Builds veröffentlicht, die sich sauber auf MITRE ATT&CK-Techniken für Remote-Access-Tools und Command-and-Control-Kanäle abbildet.

Meine Einschätzung: Die Branche behandelt „N-Day" weiterhin so, als ob es Wochen bedeuten würde. Fünf Tage ist das neue N-Day für alles mit einem CVSS von 9,8 und einem Broadcom-Logo.

Wer betroffen ist

vCenter ist das Kronjuwel der meisten Enterprise-Virtualisierungsinfrastrukturen. Bei Produktionsvorfällen, die ich bei Fintech- und iGaming-Betreibern gesehen habe, ist ein einziges kompromittiertes vCenter nicht ein Server – es ist die Kontrolle über jede VM, jeden Datastore und jede Netzwerkrichtlinie, die vCenter verwaltet. Matt Snyder, Principal Engineer und Detection-and-Response-Lead bei Aviatrix, brachte es auf den Punkt: „Wenn ein böser Akteur vCenter angreift, ist der Schadensradius eines einzigen nicht authentifizierten RCE nicht eine Anwendung – es ist die gesamte Infrastruktur."

Die Teams, die jetzt am stärksten exponiert sind, sind diejenigen mit dem größten Wartungsfenster-Problem. Regulierte Branchen, iGaming-Plattformen mitten in einem Turnier, Zahlungsabwickler in Hochvolumenphasen, jeder Betrieb, bei dem Ausfallzeitverhandlungen Wochen dauern. Snyders Diagnose, warum Organisationen beim Patchen hinterherhinken, ist unangenehm treffend: „weil das Wartungsfenster ein Gespräch ist, das niemand führen möchte." Fünf Tage von der Offenlegung bis zur Ausnutzung haben im Wesentlichen keinem Betrieb in diesen Kategorien Zeit gegeben, seinen normalen Change-Prozess durchzuführen.

Die unbequeme Erkenntnis: Wenn Ihr vCenter am 29. Juli mit dem Internet verbunden oder von einem kompromittierten Jump-Host aus erreichbar war und Sie beispielsweise am 6. August gepatcht haben, sind Sie nicht unbedingt sicher. Sie sind möglicherweise gepatcht und kompromittiert. Das ist eine sehr andere Tabletop-Übung. Eine forensische Triage der vCenter-Appliances selbst – nicht nur die Bestätigung des Versions-Strings – ist der einzige Weg, es zu wissen.

Geografische Konzentration ist ebenfalls relevant. Teams in den USA, Frankreich, Iran und der Türkei sind laut QUIRSO-Telemetrie die Hauptziele. Wenn Ihre Infrastruktur in einem dieser Länder liegt und Sie vCenter mit externer Management-Erreichbarkeit betreiben, eskalieren Sie dies über ein routinemäßiges Ticket hinaus. Dies ist ein vorstandsrelevantes Vorfallsrisiko, kein Dienstags-Patch.

Maßnahmenplan für Sicherheitsteams

Tun Sie diese Dinge diese Woche. Nicht in diesem Sprint, diese Woche.

• Patchen Sie vCenter jetzt auf die gepatchte Version. Wenn Sie den Fix aus dem Advisory vom 29. Juli noch nicht eingespielt haben, ist das der erste Schritt. Laut QUIRSO schrumpft der ungepatchte Pool täglich, was bedeutet, dass späte Patcher zunehmend die Ausnahme sind.
• Gehen Sie nicht davon aus, dass gepatcht auch sauber bedeutet. Führen Sie QUIRSOs veröffentlichte YARA-Regel für reverse_ssh-Builds gegen Ihre vCenter-Appliances und alle angrenzenden Hosts aus. Tun Sie es, bevor Sie das Change-Ticket schließen.
• Sperren Sie den ausgehenden Datenverkehr von vCenter. Snyders Punkt: „Diese operative Verzögerung ist der Grund, warum Verteidigungsstrategien die Netzwerkeindämmung als primäre Verteidigungslinie in den Mittelpunkt stellen müssen." vCenter-Appliances sollten keinen allgemeinen Internetzugang haben. Erlauben Sie nur die genauen Update- und Telemetrie-Endpunkte, die Broadcom benötigt, und blockieren Sie alles andere.
• Suchen Sie nach ausgehendem SSH-artigem Datenverkehr von vCenter- und ESXi-Management-Interfaces zu unbekannten Zielen. Das gesamte Design von reverse_ssh ist es, wie eine normale ausgehende Verbindung auszusehen – schauen Sie daher auf Ziel-Reputation und Verbindungsdauer, nicht nur auf das Protokoll.
• Rotieren Sie Zugangsdaten, die das Appliance berührt haben. Wenn Persistenz etabliert wurde, sollten alle Geheimnisse, die innerhalb des Ausnutzungsfensters in vCenter gespeichert, gecacht oder eingegeben wurden, als kompromittiert betrachtet werden.
• Vereinbaren Sie jetzt das forensische Gespräch. Wie Szadkowski sagte: „Es ist im Wesentlichen ein Wettlauf zwischen Ausnutzung und Patchen. Wir empfehlen daher eine forensische Untersuchung potenziell betroffener Systeme, um eine bestehende Kompromittierung auszuschließen." Wenn Sie das nicht intern erledigen können, engagieren Sie einen IR-Retainer, bevor Ihr Incident-Response-Budget zu einem Notfallkauf wird.

Fazit: Patchen, Egress einschränken, nach Persistenz suchen, Zugangsdaten rotieren. In dieser Reihenfolge. Alles andere ist Optimismus, der als Strategie verkleidet ist.

Wichtigste Erkenntnisse

• CVE-2026-59310 ist eine Directory-Traversal-Schwachstelle mit CVSS 9,8 in VMware vCenter, offengelegt am 29. Juli und seit dem 3. August, fünf Tage später, aktiv ausgenutzt.
• Ein einziger mutmaßlicher APT führt die Kampagne in 47 Ländern durch, mit 361 beobachteten eindeutigen IPs und den USA, Frankreich, Iran und der Türkei als Hauptzielen.
• reverse_ssh-Persistenz bedeutet, dass Patchen den Angreifer nicht vertreibt. Eine forensische Überprüfung der vCenter-Appliances ist erforderlich, nicht optional.
• Fünf Tage von der Offenlegung bis zur Ausnutzung ist die neue Baseline für Schwachstellen mit hohem CVSS in weit verbreiteter Enterprise-Software. Change-Management-Fenster, die in Wochen gemessen werden, sind keine Verteidigung mehr.
• Egress-Beschränkungen auf Management-Plane-Appliances sind die Eindämmungsmaßnahme, die diese Kampagne abgeschwächt hätte. Wenn Ihr vCenter das offene Internet erreichen kann, beheben Sie das in diesem Quartal.