vCenter wird aktiv angegriffen: Wer ungepatcht war, muss jetzt auf Kompromittierung prüfen

Fünf Tage nach dem Advisory VMSA-2026-0006 liefen die ersten Kompromittierungen. Deutschland stellt den größten Einzelposten der bekannten Opfer — und ein Plattformwechsel löst das Problem nicht.

Am 29. Juli 2026 hat Broadcom fünf Schwachstellen in VMware vCenter und ESX offengelegt und gepatcht. Fünf Tage später meldeten die ersten kompromittierten Systeme an eine Angreifer-Infrastruktur zurück. Der eigentliche Befund dieses Falls ist aber nicht die Schwachstelle. Es ist die fehlende Nachweisfähigkeit: Viele Organisationen können bis heute nicht belegen, was in diesen Tagen in ihrer Management-Ebene passiert ist. Das ist eine Architektur- und Prozessfrage — keine Herstellerfrage.

Der Anlass: fünf Schwachstellen, ein Advisory

Unter VMSA-2026-0006 hat Broadcom fünf Schwachstellen veröffentlicht und Patches bereitgestellt. Drei davon sind kritisch:

• CVE-2026-59309 (CVSS 9.8): Authentifizierungs-Bypass im VMware Directory Service des vCenter. Netzzugriff genügt, Zugangsdaten sind nicht erforderlich.
• CVE-2026-59310 (CVSS 9.8): Directory Traversal im Syslog-Dienst des vCenter, der zu Codeausführung führt. Ebenfalls unauthentifiziert über das Netz.
• CVE-2026-47876 (CVSS 9.3): Out-of-bounds Write in der Netzwerkkarten-Emulation VMXNET3 von ESX — ein Ausbruch aus der Gast-VM auf den Hypervisor. Voraussetzung sind lokale Administratorrechte im Gastsystem.

Die beiden übrigen Punkte werden in der Diskussion teils überzeichnet. CVE-2026-41703 ist ein Out-of-bounds Read (CVSS 7.6 auf ESX, 2.7 auf Workstation und Fusion). CVE-2026-41709 beschreibt unzureichende Protokollierung auf ESX (CVSS 2.7) und setzt bereits administrative Rechte auf dem Host voraus. Bemerkenswert ist diese Schwachstelle nicht als Einstieg, sondern als Endpunkt: Am Ende einer Angriffskette liegen genau die Rechte vor, die sie verlangt.

Die VMXNET3-Lücke stammt aus dem Wettbewerb Pwn2Own in Berlin. Nguyen Hoang Thach von STARLabs SG führte den Ausbruch dort am 16. Mai 2026 live vor — einschließlich des Zusatzes für Cross-tenant Code Execution, also den Sprung auf eine benachbarte VM desselben Hosts. Ein öffentlicher Exploit ist bislang nicht bekannt.

Workarounds gibt es für keine der fünf Schwachstellen. Broadcom rät ausdrücklich davon ab, VMXNET3 gegen einen anderen virtuellen Netzwerkadapter zu tauschen: Auch nicht-paravirtualisierte Geräte hatten historisch Treiberfehler, und der Tausch kostet spürbar Leistung. Der Weg heißt Update, nicht Umkonfiguration. Am 3. August wurde das Advisory als Revision .1 um Express-Patches für vCenter und ESX 8.0 U2f ergänzt.

Betroffen oder kompromittiert — der Unterschied war Betriebsdisziplin

Die Schwachstellen waren privat gemeldet und vor Beginn der Ausnutzung gepatcht. Die Angreifer folgten also dem Patch, nicht umgekehrt.

Die deutsche Incident-Response-Firma QUIRSO beobachtete am 3. August erste kompromittierte vCenter-Appliances, die eine Angreifer-Infrastruktur kontaktierten — fünf Kalendertage nach dem Advisory. Am 4. August kamen 151 weitere Opfer-IP-Adressen hinzu, am 5. August waren rund 95 Prozent des späteren Gesamtbestands erreicht. Stand 7. August: 361 IP-Adressen in 47 Ländern. Deutschland stellt mit 55 den größten Einzelposten, vor den USA (41), der Türkei (38), Iran (26) und Frankreich (25). Für die Persistenz nutzten die Angreifer reverse_ssh — ein quelloffenes Werkzeug, das ausgehend verbindet und damit an Filtern für eingehenden Verkehr vorbeiläuft. In mindestens einem untersuchten Fall folgte Ransomware.

Dazu gehören zwei Einordnungen. Erstens: 361 IP-Adressen sind nicht 361 Organisationen — Hosting- und Cloud-Adressen sind enthalten. Zweitens: Die Zuordnung zu einem chinesischsprachigen Akteur geben die Autoren selbst mit moderater Konfidenz an. Als Dringlichkeitsindiz ist das belastbar, als Statistik nicht. Dass Deutschland vorne liegt, ist trotzdem plausibel: Die VMware-Dichte im deutschen Mittelstand ist hoch.

Damit verschiebt sich die Frage. Sie lautet nicht, ob eine Umgebung betroffen war — betroffen war jeder entsprechende Versionsstand. Sie lautet: Wer konnte die Management-Ebene über das Netz erreichen? Wie schnell lag der Patch? Wäre ein Zugriff aufgefallen? Und ließe sich im Nachhinein belegen, was geschehen ist? Der Unterschied zwischen „betroffen" und „kompromittiert" war Betriebsdisziplin. Nicht die Herstellerwahl.

CVSS beschreibt Schwere, nicht Dringlichkeit

Wer Eskalation an einen Katalogeintrag knüpft, hätte diesen Fall zu spät erfasst: Im KEV-Katalog der US-Behörde CISA stand mit Katalogstand 17. August 2026 keine der fünf CVEs — auch die aktiv ausgenutzte nicht. Das ist keine Kritik an Behörden, sondern eine Aussage über Prozessdesign.

Getragen hat in diesem Fall die Hersteller-Quelle. Ein belastbarer Schwachstellenprozess ist mehrspurig: Hersteller-Advisories je eingesetztem Produkt als Primärquelle, Ausnutzungsindikatoren aus der Incident-Response-Community als eigene Spur, kuratierte Kataloge als Kontext. Auslöser für Notfallhandeln war hier nicht der Score, sondern die aktive Ausnutzung — und die bildet kein CVSS-Wert ab.

Praktisch nutzbar: Die Shadowserver Foundation meldet seit dem 30. Juli täglich verwundbare vCenter-Instanzen und verteilt seit dem 13. August zusätzlich einen Sonderbericht mit den als kompromittiert erkannten Adressen. Beides lässt sich für die eigenen Netzbereiche kostenfrei beziehen — eine Auskunft von außerhalb der betroffenen Systeme.

Was Erreichbarkeit leistet — und was ausdrücklich nicht

Beide 9.8er brauchen nichts weiter als Netzzugriff auf die vCenter-Appliance. Erreichbarkeit ist damit der einzige Hebel, der sich ohne Wartungsfenster bewegen lässt. Wer Weiterleitungen aus dem WAN auf die Appliance entfernt, Nutzer- und Produktivnetze vom Management-Segment trennt und Administration nur über einen gehärteten Sprungserver mit Mehrfaktor-Authentifizierung zulässt, senkt das Risiko erheblich — auch das aus jeder künftigen Schwachstelle derselben Angriffsfläche. Häufig übersehen: Der Syslog-Empfang der Appliance liegt nicht auf den Web-Ports. Wer nur diese einschränkt, lässt den Weg offen.

Was Segmentierung nicht leistet: Gegen die VMXNET3-Schwachstelle wirkt sie nicht. Der Angreifer sitzt bereits im Gastsystem, die verletzte Grenze ist die Geräte-Emulation, und zwischen Gast und Hypervisor liegt keine Firewall. Die Aussage „wir sind segmentiert, also gegen VM-Escape geschützt" ist fachlich falsch.

Ein Plattformwechsel ist keine Sicherheitsmaßnahme

Das muss deutlich stehen: Gegen diese fünf CVEs hilft ein Plattformwechsel nicht. Eine bestehende Umgebung muss so oder so gepatcht werden. Ein Wechsel dauert Monate, ein Patch ein Wartungsfenster.

Die Fehlerklasse ist zudem nicht herstellerspezifisch. Am 6. August 2026 wurde unter dem Namen Zapscape (CVE-2026-64561) eine Use-after-free-Schwachstelle in der Shadow-MMU von KVM/x86 veröffentlicht, die einen Ausbruch aus dem Gastsystem mit Root-Rechten auf dem Host erlaubt. Sie setzt geschachtelte Virtualisierung und Rootrechte im Gast voraus und ist im Upstream-Kernel behoben — KVM wiederum ist die Basis mehrerer verbreiteter VMware-Alternativen.

Wer die Plattform tauscht, tauscht das Risikoprofil; er entfernt es nicht. Plattformentscheidungen folgen Lizenzökonomie, Betriebsfähigkeit und Support-Terminen, ihr Horizont sind Jahre. Die Härtung der Management-Ebene gehört auf Tage bis Monate — und ist unabhängig von jeder Plattformentscheidung werthaltig.

Der eigentliche Verlust: Nachweisfähigkeit

Die Ausnutzung der Syslog-Schwachstelle liefert nicht-interaktive Codeausführung mit Root-Rechten: kein Anmeldevorgang, keine Shell-Sitzung, kein Aufgaben-Ereignis im vCenter. Wer ausschließlich auf Authentifizierungs- und Audit-Ereignisse korreliert, sieht nichts.

Beim Authentifizierungs-Bypass ist es umgekehrt — und aufschlussreicher. In der untersuchten Umgebung wurde ein neues administratives Konto angelegt, ohne dass für das ausführende Konto ein Anmeldevorgang protokolliert war. Administrative Aktion vorhanden, zugehöriger Login fehlt: Diese Diskrepanz ist die brauchbarste Erkennungsregel des Falls.

Dazu kommt die Vertrauensgrenze. Nach einer Codeausführung mit Root-Rechten liegt jedes Protokoll, das auf der Appliance entsteht, im Zugriff desjenigen, der es zu verbergen hätte. Die Integrität von Telemetrie ist eine Frage des Standorts des Kollektors, nicht der Menge der Quellen. Ein fehlender Befund in Host-Protokollen ist deshalb kein Negativbefund. Wer sauber geprüft hat, sagt: „Wir haben keine Hinweise gefunden, ein Restrisiko besteht." Nicht: „Es ist nichts passiert."

Warum das eine Governance-Frage ist

Die folgende Einordnung ist fachlich und ersetzt keine Rechtsberatung; für den Einzelfall gehören Justiziar und Datenschutzbeauftragter an den Tisch.

Die DSGVO lässt eine Meldung an die Aufsichtsbehörde nur dann entfallen, wenn die Verletzung des Schutzes personenbezogener Daten voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt (Art. 33 Abs. 1). Belegen muss das der Verantwortliche. Fehlende Nachweisbarkeit entlastet also nicht — sie nimmt einem die Ausnahme.

Das NIS-2-Umsetzungsgesetz ist in Deutschland seit dem 6. Dezember 2025 in Kraft, und zwar ohne Übergangsfrist. Seine Meldefristen — Erstmeldung binnen 24 Stunden, Meldung binnen 72 Stunden — laufen ab Kenntnis eines erheblichen Sicherheitsvorfalls, nicht ab dem Datum eines Advisories. Wer einen Vorfall nie bemerkt, hat kein Fristproblem, sondern ein Erkennungsproblem. Die Anforderungen der ISO-27001-Familie an Protokollierung und die Bausteine des BSI-IT-Grundschutzes zur Virtualisierung zeigen in dieselbe Richtung.

Vier Fragen, die für jede Plattform gelten

1. Erreichbarkeit: Wer erreicht die Management-Ebene über das Netz — auch über VPN-Portale und Reverse Proxies?
2. Patch-Latenz: Wie viele Stunden liegen zwischen Hersteller-Advisory und interner Erfassung? Wie viele bis zur Umsetzung?
3. Nachweisfähigkeit: Welche Telemetrie über diese Ebene entsteht außerhalb dieser Ebene — und wie lange wird sie aufbewahrt?
4. Wiederherstellbarkeit: Ließe sich aus einem Sicherungspunkt vor dem Kompromittierungsfenster wiederherstellen — und wurde das getestet?

Für den konkreten Anlass gilt zusätzlich eine Reihenfolge-Regel. Bei einer seit Wochen ausgenutzten Lücke ist Patchen nicht der erste Schritt: Exposition kappen, Beweise sichern, auf Kompromittierung prüfen, patchen, Zugangsdaten rotieren. Ein Patch schließt die Lücke — aber keinen Zugang, der vorher eingerichtet wurde.

In eigener Sache

enthus betreut VMware-Umgebungen und ist zugleich für Alternativen wie Nutanix AHV zertifiziert. Genau deshalb steht hier keine Herstellerschelte: Fünf privat gemeldete und gepatchte Schwachstellen sind funktionierende Herstellerarbeit. Das Muster hinter diesem Fall ist architektur- und marktanteilsgetrieben — und es trifft die nächste Plattform genauso.

Sprechen Sie uns für weitere Details, eine Beratung oder ein Expertengespräch gerne auch direkt an oder wenden Sie sich formlos an hallo@enthus.de.