Eine Grafik mit rotem Hintergrund, die eine digitale IT-Struktur in einem abstrakten Design darstellt. Geeignet für technische Themen.
vCenter-Angriffe: CVE-2026-59310 trifft 361 Systeme in 47 Ländern
- von Technischer Support
Eine kritische Schwachstelle im vCenter Syslog Server (CVE-2026-59310, CVSS 9.8) wird seit dem 3. August 2026 aktiv ausgenutzt.
Die Lücke wurde am 29. Juli 2026 offengelegt und Updates wurden bereitgestellt. Fünf Tage später begannen die ersten Angriffe – Stand 7. August 2026 sind 361 gehackte IP-Adressen in 47 Ländern bekannt. Deutschland steht dabei an der Spitze, gefolgt von den USA, der Türkei, dem Iran und Frankreich.
Angreifer nutzen die Lücke ohne Anmeldung aus, führen eigenen Code auf der vCenter-Appliance aus und richten sich anschließend dauerhaft ein: über geplante Aufgaben und über ausgehende SSH-Tunnel mit dem Werkzeug reverse_ssh. Ein Workaround existiert nicht. Da der Zugriff Neustarts übersteht, reicht in bereits betroffenen Umgebungen ein Update allein nicht aus.
Das Wichtigste in Kürze
- CVE-2026-59310 ist eine Directory-Traversal-Lücke im vCenter Syslog Server – CVSS 9.8, ohne Anmeldedaten über das Netzwerk ausnutzbar.
- Broadcom hat die Lücke am 29. Juli 2026 veröffentlicht und im selben Schritt Updates ausgeliefert.
- Ab dem 3. August 2026 – fünf Tage nach der Offenlegung – meldeten sich erste kompromittierte Systeme bei der Angreifer-Infrastruktur.
- Stand 7. August 2026: 361 betroffene IP-Adressen in 47 Ländern, über die Hälfte davon in nur fünf Ländern.
- Die Angreifer sichern ihren Zugang über geplante Aufgaben (cron / systemd) und ausgehende SSH-Tunnel mit reverse_ssh.
- Es gibt keinen Workaround: Nur die Builds 9.1.0.0300, 9.0.2.0100 sowie 8.0 U3k bzw. 8.0 U2f schließen die Lücke.
Was bei CVE-2026-59310 genau passiert
Der vCenter Server sammelt Protokolldaten über einen eigenen Syslog-Dienst.
Genau dort sitzt der Fehler: Der Dienst prüft Pfadangaben aus eingehenden Daten nicht ausreichend.
Über eine sogenannte Directory Traversal – Angreifer hängen Zeichenfolgen wie ../ an einen Pfad an – lässt sich das vorgesehene Verzeichnis verlassen und in beliebige Bereiche des Systems schreiben. Am Ende dieser Kette steht die Ausführung eigenen Programmcodes auf der Appliance.
Besonders unangenehm ist die Kombination aus zwei Eigenschaften: Der Angriff funktioniert ohne Anmeldedaten, und er trifft ein System, das in nahezu jeder virtualisierten Umgebung die zentrale Schaltstelle ist. Wer das vCenter kontrolliert, erreicht die angebundenen ESXi-Hosts, sieht die Verwaltungsstrukturen und kann Rechte weiter ausbauen.
Nach den Auswertungen des deutschen Sicherheitsunternehmens QUIRSO, das die Kampagne aus laufenden Incident-Response-Einsätzen dokumentiert hat, handelt es sich nicht um einen Zero-Day-Angriff. Die zeitliche Nähe zur Veröffentlichung spricht für ein opportunistisches Vorgehen: Ein Akteur hat den Patch analysiert, daraus einen funktionierenden Angriffsweg entwickelt und anschließend breit gescannt. Ein Muster, das sich bei VMware-Lücken wiederholt.
Wer ist von den vCenter-Angriffen betroffen?
Angreifbar ist jede vCenter-Installation der Management-Software VMware, die den Patch vom 29. Juli 2026 noch nicht erhalten hat.
Entscheidend ist dabei nicht die Größe der Umgebung, sondern allein der Build-Stand und die Erreichbarkeit der Verwaltungsschnittstelle.
Betroffen
- vCenter Server 9.1 vor Build 9.1.0.0300
- vCenter Server 9.0 vor Build 9.0.2.0100
- vCenter Server 8.0 vor 8.0 U3k bzw. 8.0 U2f – je nach Update-Zweig
- Appliances, deren Verwaltungsoberfläche aus dem Internet oder aus dem allgemeinen Client-Netz erreichbar ist
- Umgebungen ohne Filterung ausgehender Verbindungen – dort funktioniert der SSH-Rückkanal ungehindert
Nicht betroffen
- vCenter-Installationen, die die Updates vor dem 3. August 2026 erhalten haben
- Einzelne ESXi-Hosts, die ohne vCenter betrieben werden
- Der Syslog-Empfang von Netzwerkgeräten als solcher – verwundbar ist die Verarbeitung im vCenter, nicht das Protokoll
- Gastsysteme innerhalb der virtuellen Maschinen, solange sie nicht über das vCenter weiter angegriffen werden
Wichtig zu wissen: Ein Update räumt eine bereits kompromittierte Appliance nicht auf. Die Angreifer legen zusätzliche geplante Aufgaben und Dienste an, die einen Neustart und ein Update überdauern. Wer die Lücke bis Anfang August offen hatte, sollte deshalb zwei Dinge parallel tun: patchen und forensisch prüfen, ob bereits Spuren vorhanden sind.
Welche vCenter-Versionen sind im Speziellen betroffen?
Alle Builds unterhalb von 9.1.0.0300 sind angreifbar. Broadcom liefert den Patch über die reguläre Update-Verteilung der Appliance aus. Nach dem Update sollte der Build-Stand explizit gegengeprüft werden.
Für den 9.0er-Zweig ist 9.0.2.0100 der abschließende Stand. Ein Zwischenschritt über eine ältere 9.0.2-Version genügt nicht, entscheidend ist die vollständige Build-Nummer.
Umgebungen im Update-3-Zweig benötigen U3k. Dieser Zweig ist in mittelständischen Installationen am häufigsten anzutreffen und sollte zuerst geprüft werden.
Wer aus Kompatibilitätsgründen auf Update 2 bleibt, benötigt U2f. Beide 8.0-Zweige werden parallel versorgt – wichtig ist, den richtigen Patch zum eigenen Zweig zu wählen.
Für Versionen außerhalb des Supports stellt Broadcom keine Korrektur bereit. Hier hilft nur, den Zugriff auf das Verwaltungsnetz sofort stark einzuschränken und den Versionswechsel kurzfristig zu planen. Ein dauerhafter Betrieb ist bei einer Lücke dieser Bewertung nicht vertretbar.
Nein. Broadcom nennt ausdrücklich keine Umgehungslösung. Netzsegmentierung und eine strikte Filterung ausgehender Verbindungen verringern das Risiko und erschweren den Rückkanal der Angreifer, sie schließen die Lücke aber nicht.
Parallel wird eine zweite Schwachstelle beobachtet: CVE-2026-59309, ebenfalls CVSS 9.8, ein Authentifizierungs-Bypass im Verzeichnisdienst vmdir. Aktive Ausnutzung im großen Stil ist bislang nicht dokumentiert, die Scan-Aktivität nimmt jedoch zu. Beide Lücken gehören in dasselbe Wartungsfenster.
Zu prüfende Systeme
Ein gehacktes vCenter ist nie ein isoliertes Problem. Rund um die Appliance hängen Systeme, die entweder selbst Ziel werden oder den Angreifern den nächsten Schritt erleichtern:
vCenter Appliance
Ort der Schwachstelle. Build-Stand, geplante Aufgaben und Dienste prüfen.
ESXi-Hosts
Hängen am vCenter. Wer es kontrolliert, erreicht auch die Hosts und deren Datastores.
Backup-Systeme
Greifen mit weitreichenden Rechten auf das vCenter zu – ein beliebtes Folgeziel.
Syslog- und Monitoring-Kette
Der angegriffene Dienst selbst. Protokolle extern sichern, solange sie unverfälscht sind.
Verzeichnisdienst-Anbindung
AD- oder Entra-Anmeldung am vCenter samt Dienstkonten und deren Kennwörtern.
Ausgehende Verbindungen
Der SSH-Rückkanal braucht einen Weg nach draußen. Ohne Ausgangsfilterung gelingt er lautlos.
Jump-Hosts und Admin-Geräte
Von dort wird verwaltet. Gespeicherte Sitzungen und Token sind attraktive Beute.
Automatisierung und Skripte
API-Token, PowerCLI-Zugänge und Automatisierungskonten mit dauerhaften Rechten.
Die Zeitleiste der vCenter-Angriffe
Zwischen Offenlegung und erster Ausnutzung von CVE-2026-59309 lagen fünf Tage. Die Kurve der betroffenen Systeme zeigt, wie schnell eine solche Kampagne skaliert und wie kurz das Zeitfenster für ein geordnetes Patch-Management tatsächlich ist.
1
29. Juli 2026
Offenlegung und Patch
Broadcom veröffentlicht die Schwachstelle und stellt gleichzeitig korrigierte Builds bereit. Ein Workaround wird ausdrücklich nicht genannt.
2
3. – 7. August 2026
Aktive Ausnutzung
Am 3. August melden sich erste gehackte Systeme bei der Angreifer-Infrastruktur. Am 4. August kommen 151 neue Opfer-IPs hinzu, am 5. August liegt die Summe bei 343, am 7. August bei 361.
3
seit August 2026
Laufende Kampagne
Die Verteilung über 47 Länder mit Schwerpunkt Deutschland deutet auf breites, automatisiertes Scannen. Parallel steigt die Scan-Aktivität gegen CVE-2026-59309.
Die Verteilung der betroffenen Systeme über 47 Länder – mit Deutschland an der Spitze, gefolgt von den USA, der Türkei, dem Iran und Frankreich – ergibt kein politisches Muster, sondern spiegelt vor allem, wo viele eigenbetriebene VMware-Umgebungen stehen. Über die Hälfte aller Treffer verteilt sich auf nur fünf Länder.
Für den eigenen Betrieb heißt das: Die Frage ist nicht, ob man ein interessantes Ziel ist, sondern ob die Appliance im Zeitfenster erreichbar war.
Automatisiertes Scannen unterscheidet nicht nach Branche oder Unternehmensgröße.
Betroffene Versionen und Patch-Stände
Broadcom versorgt drei Produktlinien gleichzeitig. Entscheidend ist, den Patch zum eigenen Update-Zweig zu wählen – ein Sprung in eine andere Linie ist weder nötig noch immer möglich.
| Produktlinie | Status ohne Update | Ziel-Build | Handlungsbedarf |
|---|---|---|---|
| vCenter Server 9.1 | angreifbar | 9.1.0.0300 | sofort einspielen |
| vCenter Server 9.0 | angreifbar | 9.0.2.0100 | sofort einspielen |
| vCenter Server 8.0 U3 | angreifbar | 8.0 U3k | sofort einspielen |
| vCenter Server 8.0 U2 | angreifbar | 8.0 U2f | sofort einspielen |
| Versionen ohne Support | angreifbar | kein Patch verfügbar | Zugriff einschränken, Versionswechsel planen |
Kurz gesagt: Ohne Update bleibt jedes vCenter angreifbar – unabhängig von Firewall-Regeln oder Segmentierung. Und wer erst nach dem 3. August 2026 gepatcht hat, sollte die Appliance zusätzlich auf Spuren prüfen.
So läuft der vCenter-Angriff in der Praxis ab
Die dokumentierte Kette besteht aus zwei klar getrennten Schritten: erst der Einstieg über die Lücke, dann die dauerhafte Einrichtung im System.
Schritt 1 · Erstzugriff
Directory Traversal im Syslog-Dienst
Der Angreifer schickt manipulierte Daten an den Syslog-Dienst der vCenter-Appliance. Weil Pfadangaben nicht ausreichend geprüft werden, landen Dateien außerhalb des vorgesehenen Verzeichnisses. Von dort aus wird eigener Code ausgeführt – ohne Benutzername, ohne Kennwort, ohne Interaktion eines Administrators.
Das erklärt auch die Geschwindigkeit der Kampagne: Der Einstieg lässt sich vollständig automatisieren. Wer im Internet nach erreichbaren vCenter-Instanzen sucht, findet genug Ziele.
Empfehlung
- Verwaltungsschnittstellen des vCenter niemals direkt aus dem Internet erreichbar machen
- Syslog-Zugänge auf die tatsächlich benötigten Quellsysteme einschränken
- Build-Stand nach jedem Update dokumentiert gegenprüfen
Schritt 2 · Persistenz
reverse_ssh und geplante Aufgaben
Im zweiten Schritt setzen die Angreifer auf das frei verfügbare Werkzeug reverse_ssh. Es baut eine SSH-Verbindung von innen nach außen auf – die Appliance ruft also den Server der Angreifer an, nicht umgekehrt. Für eine Firewall sieht das aus wie eine normale ausgehende Verbindung, und genau darin liegt der Vorteil für die Angreifer.
Damit der Kanal Neustarts übersteht, werden zusätzlich geplante Aufgaben angelegt – als cron-Job oder als Dienst über systemd. QUIRSO hat für die Erkennung eine YARA-Regel veröffentlicht. Zu beachten: reverse_ssh wird auch legitim eingesetzt, ein Treffer ist deshalb immer zu bewerten und nicht automatisch ein Vorfall.
Beide Schritte zusammen bedeuten: Der Patch stoppt neue Angriffe, entfernt aber keinen bestehenden Zugang.
Die Folge: In Umgebungen, die zwischen dem 29. Juli und dem Einspielen des Updates erreichbar waren, gehören Patch und forensische Prüfung zusammen – nicht nacheinander.
Sofortmaßnahmen für IT-Verantwortliche
Vier Schritte, in dieser Reihenfolge:
1
Patchstand feststellen
Der erste Schritt ist eine belastbare Inventur: Welche vCenter-Instanzen sind im Einsatz, in welchem Build-Stand, und wann wurden sie zuletzt aktualisiert? Erst danach lässt sich beurteilen, ob überhaupt ein Zeitfenster für einen Angriff bestand.
- Build-Nummer je Instanz erfassen – nicht nur die Hauptversion
- Datum des letzten Updates mit dem 29. Juli 2026 abgleichen
- Testumgebungen und stillgelegte Appliances ausdrücklich mit aufnehmen
2
Auf Spuren prüfen
Bestand ein Zeitfenster, wird geprüft, ob es genutzt wurde. Die dokumentierten Merkmale der Kampagne sind dabei recht konkret und lassen sich mit Bordmitteln der Appliance sichten.
- Geplante Aufgaben und angelegte Dienste auf unbekannte Einträge kontrollieren
- Ausgehende Verbindungen und lauschende Prozesse sichten
- Protokolle ab dem 29. Juli 2026 extern sichern, bevor sie rotieren
- Bei einem Treffer nicht selbst aufräumen, sondern den Vorfallprozess starten
3
Angriffsfläche verkleinern
Unabhängig vom Ergebnis gehört die Erreichbarkeit des vCenter auf den Prüfstand: getrenntes Verwaltungsnetz, Zugriff nur über definierte Administrationswege und eine Filterung ausgehender Verbindungen. Das verhindert die Lücke nicht, nimmt einem Rückkanal aber die Grundlage.
4
Zugangsdaten und Wiederherstellung vorbereiten
Wurde eine Appliance kompromittiert, sind alle dort verwendeten Zugangsdaten als offengelegt zu behandeln – auch die von Backup- und Automatisierungskonten. Prüfen Sie parallel, ob Ihre Backups vom vCenter unabhängig wiederherstellbar sind.
Technische Prüfung und Checkliste
Die folgenden Befehle werden direkt auf der vCenter-Appliance in der Shell ausgeführt. Sie ersetzen keine forensische Untersuchung, zeigen aber schnell, ob offensichtliche Spuren vorhanden sind. Sichern Sie die Ausgaben außerhalb des geprüften Systems.
Shell · Persistenz prüfen
# Geplante Aufgaben und Dienste auf der Appliance sichten crontab -l ls -la /etc/cron.d/ /etc/cron.daily/ /var/spool/cron/ systemctl list-timers --all systemctl list-units --type=service --state=running
Shell · Rückkanal aufspüren
# Ausgehende Verbindungen und verdaechtige Prozesse netstat -tunap | grep ESTABLISHED ps -ef --forest grep -Ei "ssh -R|reverse_ssh" /var/log/messages /var/log/audit/audit.log
Checkliste: Sind Sie vorbereitet?
- Alle vCenter-Instanzen mit vollständiger Build-Nummer erfasst
- Updates 9.1.0.0300, 9.0.2.0100 bzw. 8.0 U3k/U2f eingespielt und gegengeprüft
- Zeitfenster zwischen dem 29. Juli 2026 und dem Update je Instanz dokumentiert
- Geplante Aufgaben, Dienste und ausgehende Verbindungen kontrolliert
- Protokolle ab dem 29. Juli 2026 extern gesichert
- Verwaltungszugriff auf ein getrenntes Netz begrenzt, ausgehende Verbindungen gefiltert
- CVE-2026-59309 im selben Wartungsfenster mit eingeplant
FAQ zu CVE-2026-59310
Wie kritisch ist CVE-2026-59310 wirklich?
Die Bewertung liegt bei CVSS 9.8 von 10. Ausschlaggebend ist die Kombination: Die Lücke lässt sich ohne Anmeldedaten über das Netzwerk ausnutzen, führt zur Ausführung eigenen Codes und trifft die zentrale Verwaltungsinstanz einer Virtualisierungsumgebung. Die dokumentierten 361 betroffenen Systeme in 47 Ländern zeigen, dass sie tatsächlich genutzt wird.
Wir haben gepatcht – sind wir damit sicher?
Gegen neue Angriffe ja. War Ihr vCenter zwischen dem 29. Juli und dem Einspielen des Updates erreichbar, ersetzt der Patch aber keine Prüfung: Die Angreifer legen geplante Aufgaben und ausgehende SSH-Tunnel an, die ein Update überdauern.
Unser vCenter ist nicht aus dem Internet erreichbar. Reicht das?
Das senkt das Risiko erheblich, hebt es aber nicht auf. Der Angriff funktioniert aus jedem Netz, das den Syslog-Dienst erreicht – also auch aus einem kompromittierten Client-Netz. Netzsegmentierung ist eine wichtige zusätzliche Schutzschicht, kein Ersatz für das Update.
Woran erkennen wir einen erfolgreichen vCenter-Angriff?
Typische Merkmale sind unbekannte cron-Jobs oder systemd-Dienste auf der Appliance und ausgehende SSH-Verbindungen zu unbekannten Zielen. QUIRSO hat zur Erkennung von reverse_ssh eine YARA-Regel veröffentlicht. Da das Werkzeug auch legitim genutzt wird, ist jeder Treffer zu bewerten.
Was ist CVE-2026-59309?
Eine zweite Schwachstelle mit CVSS 9.8: ein Authentifizierungs-Bypass im Verzeichnisdienst vmdir. Breite Ausnutzung ist bisher nicht dokumentiert, die Scan-Aktivität steigt jedoch. Planen Sie beide Lücken in einem Wartungsfenster ein.
Fazit
CVE-2026-59310 ist ein Lehrstück in Sachen Zeit: Fünf Tage nach der Offenlegung liefen die ersten Angriffe, nach knapp einer Woche waren 361 Systeme in 47 Ländern betroffen. Wer Updates für zentrale Verwaltungssysteme in einem monatlichen Rhythmus einplant, ist bei einer Lücke dieser Bewertung zu spät. Kritische Komponenten wie das vCenter brauchen kurze Intervalle zum Patchen.
Dass Deutschland an der Spitze der Statistik steht, hat vermutlich einen unspektakulären Grund: Hier stehen viele selbst betriebene Virtualisierungsumgebungen. Genau deshalb lohnt der Blick heute – Build-Stand prüfen, Updates einspielen, Appliance auf Spuren kontrollieren und die Erreichbarkeit des Verwaltungsnetzes einmal grundsätzlich hinterfragen.
Fanden Sie den Blogbeitrag hilfreich und interessant?
Vielen Dank für Ihre Rückmeldung!
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Ut elit tellus, luctus nec ullamcorper mattis, pulvinar dapibus leo.