Am 29. Juli 2026 war die Antwort richtig

In vielen Betrieben ist Ende Juli 2026 dieser Vorgang abgelaufen: VMware veröffentlicht am 29. Juli 2026 ein Sicherheitsadvisory zu mehreren eigenen Produkten. Jemand sieht nach — der Dienstleister, der Kollege mit dem Serverwissen, vielleicht Sie selbst —, gleicht den eigenen Versionsstand mit der Liste ab und findet dort für diese Version nichts. Der Vorgang wird abgehakt. Das war zu diesem Zeitpunkt eine korrekte Auskunft.

Sie ist es nicht geblieben. Das Advisory wurde nachgebessert: Korrekturen für vSphere 8.0 Update 2 kamen später hinzu, und aus VMSA-2026-0006 wurde VMSA-2026-0006.1. Wer am 29. Juli nachgesehen und seitdem nicht wieder hingeschaut hat, arbeitet mit einem Stand, den es so nicht mehr gibt.

Darum geht es in diesem Beitrag. Nicht zuerst um die Lücke — die ist ernst, und dazu kommen wir gleich. Sondern um eine Eigenschaft von Sicherheitsmeldungen, die im Betriebsalltag regelmäßig untergeht: Sie sind keine Nachrichten, die einmal erscheinen und dann feststehen. Sie sind Dokumente, die sich ändern.

Auf einen Blick

  • VMware hat am 29. Juli 2026 das Sicherheitsadvisory VMSA-2026-0006 veröffentlicht. Der Hersteller führt darin fünf Schwachstellen auf, verteilt auf ESX, vCenter Server, Workstation und Fusion.
  • Zwei davon betreffen vCenter Server und sind ohne Anmeldung über das Netz ausnutzbar — eine Umgehung der Anmeldung über den Verzeichnisdienst und eine Codeausführung über den Syslog-Dienst.
  • Einen Workaround nennt der Hersteller nicht. Es hilft nur das Update.
  • Das Advisory liegt in der Fassung VMSA-2026-0006.1 vor (Stand: 13. August 2026). Nachträglich aufgenommen wurden Korrekturen für vSphere 8.0 Update 2.
  • Wer auf diesem Versionsstand läuft und am 29. Juli 2026 nachgesehen hat, fand für seine Version keine Korrektur — und konnte den Vorgang mit gutem Grund für erledigt halten.
  • vCenter Server ist die Verwaltungszentrale einer VMware-Umgebung. Wer sie kontrolliert, kontrolliert alle virtuellen Maschinen eines Betriebs auf einmal.
  • Über die Herstellerangaben hinaus berichten Sicherheitsfirmen von laufenden Angriffen. Woher das stammt und was wir daraus nicht ableiten, steht weiter unten.

Warum ein Advisory kein fertiger Text ist

Ein Sicherheitsadvisory entsteht unter Zeitdruck. Der Hersteller muss veröffentlichen, sobald die Lücke bekannt oder das erste Update fertig ist — nicht erst, wenn er jede unterstützte Version durchgeprüft und für jede ein Paket gebaut hat. Beides zusammen geht selten. Das Ergebnis ist ein Dokument, das am ersten Tag vollständig aussieht und es nicht ist.

Deshalb tragen diese Dokumente eine Fassung. Die angehängte Ziffer in VMSA-2026-0006.1 ist keine Formalie, sondern die Auskunft, dass an dem Text nach der Erstveröffentlichung gearbeitet wurde. Was sich dabei ändert, ist selten die Beschreibung der Schwachstelle. Es sind die Listen daneben: welche Versionen betroffen sind und für welche es eine Korrektur gibt.

Für einen Betrieb ohne eigene IT-Abteilung hat das eine unbequeme Folge. Die Prüfung „sind wir betroffen?" ist keine einmalige Handlung mit einem dauerhaft gültigen Ergebnis. Sie ist eine Momentaufnahme — und ihr Haltbarkeitsdatum steht nirgends darauf.

Was in diesem Advisory steht

VMware führt in VMSA-2026-0006 fünf Schwachstellen auf, verteilt auf ESX, vCenter Server, Workstation und Fusion. Zwei davon betreffen vCenter Server, und diese beiden sind der Grund, warum das Dokument nicht zwischen anderen Meldungen liegen bleiben sollte.

Der erste Punkt ist eine Umgehung der Anmeldung über den Verzeichnisdienst. Vereinfacht gesagt: Ein Angreifer verschafft sich Zugang, ohne gültige Zugangsdaten zu besitzen. Der zweite ist eine Codeausführung über den Syslog-Dienst — also über die Komponente, die Protokolleinträge entgegennimmt. Wer sie erfolgreich anspricht, bringt eigenen Programmcode auf dem Server zur Ausführung.

Beide sind nach Herstellerangabe ohne Anmeldung über das Netz ausnutzbar. Das ist die unangenehmste Kombination, die es gibt: Es braucht kein gestohlenes Kennwort, keinen Klick eines Mitarbeiters, keine Vorstufe. Es genügt, dass ein Angreifer den Dienst erreicht.

Und es gibt keinen Zwischenweg. Einen Workaround — eine Einstellung, die das Problem vorübergehend entschärft — nennt der Hersteller nicht. Es hilft das Update oder nichts.

Warum ausgerechnet dieser Server

vCenter Server ist nicht irgendeine Anwendung. Es ist die Verwaltungszentrale einer VMware-Umgebung: die Oberfläche, über die virtuelle Maschinen angelegt, gestartet, verschoben und gesichert werden.

In einem Betrieb mit fünf bis fünfzig Beschäftigten hängt daran in aller Regel alles, was im Technikraum steht — der Dateiserver, die Warenwirtschaft, der Server der Branchensoftware, oft auch das Ziel der Datensicherung. Wer die Verwaltungszentrale übernimmt, hat nicht einen Rechner. Er hat den Maschinenraum.

Dazu kommt eine zweite Eigenheit, die die Sache im Alltag verdeckt. Ein Angreifer, der sich dauerhaft einrichtet, statt zu verschlüsseln, richtet keinen sichtbaren Schaden an. Nichts fällt aus, nichts wird langsamer, niemand ruft an. Genau das ist der Zweck: Ein Zugang, den niemand bemerkt, bleibt nutzbar. Bei einer Verschlüsselung wissen Sie am nächsten Morgen, woran Sie sind. Hier ist das Ausbleiben von Symptomen kein Entwarnungssignal.

Was nachträglich dazugekommen ist

Der Punkt, der diesen Beitrag ausgelöst hat: Das Advisory führt in der Fassung VMSA-2026-0006.1 Korrekturen für vSphere 8.0 Update 2 auf, die am ersten Tag nicht darin standen.

Das trifft eine bestimmte Gruppe, und es trifft sie leise. Wer auf diesem Versionsstand läuft und am 29. Juli 2026 pflichtbewusst nachgesehen hat, fand für seine Version keine Korrektur. Aus dieser Beobachtung folgt kein Verdacht, sondern eine Ablage: nichts zu tun, weiterarbeiten. Und es gibt nichts, was diese Person von selbst zurückholt — keinen Anruf, keine zweite Meldung, keine Störung im Betrieb.

Wer erst nach der Überarbeitung nachgesehen hat, findet die Korrektur und spielt sie ein. Der Unterschied zwischen beiden liegt nicht in der Sorgfalt. Er liegt im Tag der Prüfung.

Was Dritte berichten

Über die Herstellerangaben hinaus berichten mehrere Sicherheitsfirmen, dass diese Schwachstelle angegriffen wird. Genannt wird der 3. August 2026 als Tag der ersten beobachteten Übernahmen, also wenige Tage nach Veröffentlichung des Advisories.

Diese Berichte haben wir nicht aus erster Hand geprüft, und wir geben sie deshalb als das wieder, was sie sind: Auswertungen einzelner Anbieter auf Basis ihrer eigenen Messdaten. Die dabei kursierenden Opferzahlen lassen wir bewusst weg. Sie beschreiben, was ein einzelnes Unternehmen sehen kann, nicht, wie viele Systeme weltweit betroffen sind — und für Ihre Entscheidung ändern sie nichts. Ob hundert oder tausend Systeme übernommen wurden, hat auf die Frage, ob Ihr vCenter aktuell ist, keinen Einfluss.

Was belegt bleibt, steht im Advisory selbst: ohne Anmeldung über das Netz ausnutzbar, kein Workaround.

Was Sie jetzt tun sollten

  • Zuerst klären, ob überhaupt ein vCenter Server im Haus steht. Kleine Umgebungen mit einem einzigen Virtualisierungs-Host kommen oft ohne aus; dann sind die beiden hier beschriebenen Punkte nicht Ihr Thema. Diese Frage ist in wenigen Minuten beantwortet und beendet den Vorgang für einen Teil der Leserinnen und Leser.
  • Den Versionsstand gegen die aktuelle Fassung des Advisories abgleichen, nicht gegen eine Notiz aus dem Juli. Wenn im Juli 2026 jemand geprüft hat, ist das kein Ersatz für die zweite Prüfung, sondern ihr Anlass. Das gilt besonders, wenn bei Ihnen vSphere 8.0 Update 2 läuft.
  • Festhalten, welche Fassung Sie gesehen haben. Kennung und Datum genügen. Wer notiert „geprüft gegen VMSA-2026-0006, Stand 29. Juli 2026", kann später erkennen, dass sich etwas geändert hat. Wer nur „geprüft, nicht betroffen" notiert, kann das nicht.
  • Ein Wartungsfenster einplanen, statt auf eine Zwischenlösung zu warten. Es gibt keine. Ein vCenter-Update ist ein planbarer Vorgang, aber keiner für den laufenden Betrieb am Dienstagvormittag.
  • Prüfen, wer die Verwaltungsoberfläche überhaupt erreichen kann. Sie gehört nicht ins offene Internet und in aller Regel auch nicht in dasselbe Netz wie die Arbeitsplätze. Das ist Grundhygiene und verkleinert die Angriffsfläche. Es ersetzt das Update ausdrücklich nicht — der Hersteller nennt keinen Workaround, und diese Maßnahme ist auch keiner.
  • Die zweite Prüfung zur Gewohnheit machen. Bei einem Advisory ohne Workaround lohnt sich ein Wiedervorlagetermin ein bis zwei Wochen später. Das ist unsere Empfehlung aus der Praxis und keine Herstellervorgabe — aber es ist genau der Termin, der in diesem Fall den Unterschied gemacht hätte.

Eine praktische Anmerkung dazu: VMware veröffentlicht seine Sicherheitsadvisories nicht nur im Support-Portal, sondern zusätzlich in einem öffentlich zugänglichen Repository auf GitHub. Wenn der Zugang zum Portal hakt, ist das der zweite Weg zum selben Text — inklusive der Fassungsangabe, auf die es hier ankommt.

Und wenn Sie ohnehin über die Plattform nachdenken

Viele Betriebe beschäftigen sich seit der Lizenzumstellung mit der Frage, ob VMware auf Dauer die richtige Grundlage bleibt. Dazu finden Sie in unserem Blog den Beitrag „VMware-Alternativen 2026: Proxmox & Co. für den Mittelstand".

Für die nächsten Tage ändert diese Überlegung nichts. Ein Plattformwechsel ist ein Vorhaben von Wochen bis Monaten; das Update ist eines für das nächste Wartungsfenster. Die beiden Fragen gehören nacheinander beantwortet, nicht gegeneinander.

Fazit

Die Lücke in vCenter Server ist ein ernster Fall, aber kein ungewöhnlicher. Ungewöhnlich ist, wie leicht man sie mit der besten Absicht verpassen konnte: Man hat nachgesehen, man hat nichts gefunden, und man hatte recht. Der Fehler lag nicht in der Prüfung. Er lag in der Annahme, dass ihr Ergebnis hält.

Sicherheitsadvisories werden nachgebessert. Betroffene Versionen kommen dazu, Korrekturen erscheinen später, Fassungen ändern sich — meistens, ohne dass jemand darüber berichtet. Wer das weiß, prüft ein zweites Mal und notiert, wogegen er geprüft hat. Das kostet wenige Minuten, und es ist der Teil dieses Themas, der über den konkreten Fall hinaus etwas bringt.

Wenn Sie nicht sicher sind, ob bei Ihnen ein vCenter läuft, auf welchem Stand es ist und wer es über das Netz erreichen kann, sehen wir uns das gemeinsam an. Wir gleichen Ihre Versionen gegen die aktuelle Fassung des Advisories ab, planen das Update so, dass Ihr Betrieb dabei weiterläuft, und richten die Wiedervorlage ein, damit die nächste Nachbesserung nicht an Ihnen vorbeigeht.