Neun Tage vom Patch bis zu 361 Opfern

Broadcom veröffentlichte am 29. Juli 2026 das Advisory VMSA-2026-0006 und legte darin CVE-2026-59310 zusammen mit einer begleitenden Authentifizierungs-Bypass-Lücke, CVE-2026-59309, in VMware vCenter Server 8.0, 9.0 und 9.1 offen. Gepatchte Versionen standen noch am selben Tag bereit: vCenter 9.1.0.0300, vCenter 9.0.2.0100 sowie vCenter 8.0 U3k oder U2f, je nach eingesetztem Update-Zweig.

QUIRSO GmbH, ein deutsches Unternehmen für digitale Forensik und Incident Response, berichtet, dass angreiferkontrollierte Infrastruktur am 3. August 2026 die ersten eingehenden Verbindungen von ausgenutzten vCenter-Systemen registrierte - nur fünf Tage nach Erscheinen des Patches. Bis zum 7. August zählte das Unternehmen 361 unterschiedliche Opfer-IP-Adressen in 47 Ländern, mit Schwerpunkten in Deutschland, den USA, der Türkei, dem Iran und Frankreich. QUIRSO veröffentlichte zu seinen Erkenntnissen eine YARA-Erkennungsregel, hielt aber einige Kompromittierungsindikatoren während der Abstimmung mit Strafverfolgungsbehörden zurück.

Eine Syslog-Funktion, die den gesamten Server preisgibt

CVE-2026-59310 liegt in der Verzeichnisverarbeitung der Syslog-Server-Komponente von vCenter. Broadcoms eigenes Advisory stellt unmissverständlich fest, dass ein böswilliger Akteur mit Netzwerkzugriff auf vCenter die Lücke ausnutzen kann, um beliebigen Code auszuführen - und entscheidend: ohne vorherige Authentifizierung. Genau diese Kombination aus fehlender Authentifizierung und Codeausführung auf Systemebene brachte der Lücke ihren Schweregrad von 9,8 von 10 ein und macht jede aus dem Internet erreichbare vCenter-Instanz zu einem unmittelbaren statt einem theoretischen Ziel.

vCenter ist kein Randwerkzeug. Es ist die Verwaltungsebene für die gesamte Virtualisierungslandschaft einer Organisation, die Konsole, die jede virtuelle Maschine eines Unternehmens bereitstellt, migriert und steuert. Ein Herstellerhinweis für genau dieses Produkt sollte niemals in derselben Warteschlange landen wie ein routinemäßiger Anwendungspatch.

Warum reverse_ssh die vorhandene Firewall-Regel aushebelt

Statt einen lauschenden Port auf dem kompromittierten vCenter-Server zu öffnen, den die meisten Netzwerküberwachungen erkennen würden, installieren die Angreifer hinter dieser Kampagne reverse_ssh, ein quelloffenes Go-Tool, das die kompromittierte Maschine eine ausgehende SSH-Verbindung zur Angreifer-Infrastruktur aufbauen lässt. Weil die Verbindung ausgehend ist, kann sie an Firewall- und Netzwerkrichtlinien vorbeischlüpfen, die unaufgeforderten eingehenden Datenverkehr blockieren, gewöhnlich aussehende ausgehende Sitzungen aber durchlassen - das verschafft dem Angreifer einen dauerhaften, interaktiven Zugang, der eine einfache Netzwerksegmentierungsprüfung übersteht.

Für ein Gerät, das ohnehin im Zentrum der Virtualisierungslandschaft einer Organisation steht, macht dieser Persistenzmechanismus aus einem einzigen ungepatchten vCenter-Server einen langlebigen Brückenkopf statt eines einmaligen Zugriffs.

Originalthese: Die KEV-Lücke ist hier die eigentliche Geschichte

Die meisten Schwachstellenberichte bemessen Dringlichkeit daran, ob eine Lücke im Known-Exploited-Vulnerabilities-Katalog der CISA gelandet ist, und viele Patch-Programme sind formell oder informell genau um diesen Auslöser herum gebaut. CVE-2026-59310 bricht mit dieser Annahme. Unabhängige Telemetriedaten von QUIRSO und dem Sicherheitsunternehmen Rapid7 dokumentierten innerhalb der ersten anderthalb Wochen nach Offenlegung Hunderte reale Kompromittierungen in 47 Ländern - dennoch war die CVE zum Zeitpunkt dieses Artikels weiterhin nicht im CISA-Katalog gelistet. Ein Patch-Workflow, der die KEV-Aufnahme als Signal für den Notfallstatus eines vCenter-Advisorys behandelt, lag damit per Definition bereits Wochen hinter den Angreifern zurück, die diese Lücke gefunden und bewaffnet hatten.

Die Lehre reicht über diese eine CVE hinaus. Bei Infrastruktursoftware wie einer Hypervisor-Verwaltungskonsole sollten die Telemetriedaten eines unabhängigen DFIR-Unternehmens oder der Schweregrad des Herstellers selbst ausreichen, um sofortiges Patchen auszulösen - ohne auf einen staatlichen Katalogeintrag zu warten, der diesmal einfach nicht fristgerecht erschien.

Was vCenter-Betreiber jetzt tun sollten

Jede Organisation, die vCenter 8.0, 9.0 oder 9.1 betreibt und die Fixes vom 29. Juli noch nicht eingespielt hat, sollte dies als Notfalländerung behandeln, nicht als geplante Wartung, und zudem prüfen, dass die Verwaltungsoberfläche nicht direkt aus dem öffentlichen Internet erreichbar ist - was ohnehin nie der Fall sein sollte. Angesichts des hier dokumentierten ausgehenden Persistenzmechanismus gehört die Überwachung ausgehender SSH-Verbindungen von Infrastruktur-Servern, nicht nur der eingehende Zugriff auf sie, nun zu einer vollständigen Erkennungsstrategie für genau diese Kampagne.

Für wesentliche und wichtige Einrichtungen in der EU nach NIS2, die während des Ausnutzungszeitraums aus dem Internet erreichbare oder anderweitig exponierte vCenter-Instanzen betrieben, fällt dieser Vorfall genau in die Kategorien, für die die Richtlinie geschrieben wurde: unauthentifizierte Remotecodeausführung auf Infrastruktur mit bestätigter aktiver Ausnutzung und einer realen Gefährdung von Vertraulichkeit, Integrität oder Verfügbarkeit der gesamten Virtualisierungslandschaft.

Weiterlesen: Zwei API-Aufrufe verschafften 295 Angreifern Root-Zugriff  |  CVSS 9.6: Schwachstelle traf Load Balancer 792 Mal