VMware ESXi: Drei kritische Lücken machen VM-Escape und Code-Ausführung möglich

Drei kritische Lücken, ein Hypervisor, ein sehr schlechter Tag für alle, die ESXi-Hosts betreiben: Am 29. Juli 2026 haben Sicherheitsmedien über gleich drei VMware-Schwachstellen berichtet, die in Kombination Auth-Bypass, Code-Ausführung und VM-Escape erlauben sollen. Klingt nach Buzzword-Bingo, ist aber ziemlich konkret gemeint: Wer eine dieser Lücken kettet, kann theoretisch aus einer virtuellen Maschine heraus auf den darunterliegenden Host durchgreifen. Genau das ist der Albtraum jedes Virtualisierungs-Admins, denn ESXi verspricht seit jeher eine harte Trennlinie zwischen Gast und Host. Diese Trennlinie ist der eigentliche Verkaufsgrund von Virtualisierung.

Berichtet haben unter anderem The Hacker News und, über Google News aggregiert, Security Affairs über das Risiko für ESXi-Hosts. Konkrete CVE-Nummern für diese Juli-Meldung liegen bislang nur begrenzt vor, das Muster der Angriffskette – lokaler Zugriff in der VM, dann Sprung auf den Host – kennt die ESXi-Historie allerdings bereits sehr gut. Und genau diese Historie lohnt einen zweiten Blick, weil sie zeigt, wie planbar solche Wellen inzwischen geworden sind.

Was VM-Escape eigentlich bedeutet

Der Begriff klingt dramatischer, als er in der Praxis ist – und trotzdem ist er es wert, ernst genommen zu werden. Ein Hypervisor wie ESXi soll dafür sorgen, dass eine virtuelle Maschine strikt von anderen VMs und vom Host getrennt bleibt. Prozesse in der Gast-VM dürfen normalerweise nicht mit dem Host-Kernel oder dem sogenannten VMX-Prozess interagieren, der auf dem Host für jede laufende VM zuständig ist. VM-Escape bricht genau diese Grenze: Ein Angreifer mit Admin-Rechten innerhalb einer VM nutzt einen Programmierfehler in einer Kommunikationsschnittstelle, um Code im Kontext des Hosts auszuführen.

Das Pikante daran: Man braucht dafür keinen Root-Zugriff auf den physischen Server. Es reicht, wenn jemand die Kontrolle über eine einzelne VM erlangt – etwa über eine kompromittierte Anwendung, gestohlene Zugangsdaten oder einen böswilligen Mandanten in einer Multi-Tenant-Umgebung. Von dort aus geht es dann über verwundbare Schnittstellen weiter nach oben in Richtung Host. In Cloud- und Hosting-Umgebungen mit vielen Kunden-VMs auf einem physischen Server ist das besonders unangenehm, weil ein kompromittierter Mandant im schlimmsten Fall alle anderen VMs auf demselben Host mit gefährdet.

Um sich das Ausmaß vorstellbar zu machen, hilft ein rein illustratives Gedankenspiel, das keinen konkreten Vorfall beschreibt, sondern das strukturelle Risiko sichtbar macht: Angenommen, ein Angreifer verschafft sich über eine Phishing-Mail Zugriff auf eine einzelne Testumgebung, die auf einer VM läuft. Diese VM hat, wie es in vielen Unternehmen üblich ist, keine besonders strenge Härtung, weil sie ja „nur“ für interne Tests gedacht ist. Gelingt es dem Angreifer nun, die Admin-Rechte innerhalb dieser einen VM zu erlangen, und existiert zeitgleich eine ungepatchte VM-Escape-Lücke auf dem darunterliegenden Host, dann ist der Sprung vom vermeintlich unwichtigen Testsystem zur produktiven Infrastruktur plötzlich nur noch eine Frage der Ausnutzung einer einzigen weiteren Schwachstelle. Genau diese Verkettung von „eigentlich harmlos“ und „eigentlich kritisch“ macht VM-Escape zu einem derart unterschätzten Risiko in der Praxis.

Die Anatomie der aktuellen Meldung

Laut den Berichten vom 29. Juli 2026 kombinieren die drei gemeldeten Schwachstellen unterschiedliche Angriffsstufen: eine Lücke erlaubt einen Auth-Bypass, also den Zugriff ohne gültige Anmeldedaten, eine weitere ermöglicht Code-Ausführung, die dritte trägt das VM-Escape-Risiko. Diese Dreiteilung ist kein Zufall, sie folgt einem inzwischen vertrauten Muster: Erst rein, dann Rechte ausweiten, dann die Isolationsschicht durchbrechen. Genau diese Kettenlogik macht ESXi-Lücken für Angreifer so attraktiv, weil ein einzelner Exploit selten ausreicht, aber die Kombination aus mehreren mittelschweren Fehlern am Ende zu vollständiger Host-Kontrolle führen kann.

Wer jetzt auf eine vollständige technische Aufschlüsselung mit CVE-Nummern für diese konkrete Juli-Meldung wartet: Die öffentlich verfügbaren Details sind zum Zeitpunkt dieses Artikels noch dünn. Was sich aber sagen lässt, ohne zu spekulieren: Das Risiko-Profil – Auth-Bypass plus Code-Ausführung plus VM-Escape – deckt sich fast eins zu eins mit den beiden großen VMware-Sicherheitswellen aus dem Vorjahr. Und die lohnt sich anzuschauen, weil sie zeigt, wie solche Lücken in der Praxis aussehen und wie schnell sie ausgenutzt werden. Bemerkenswert ist außerdem, dass sich das Muster nicht nur bei VMware zeigt: Ähnlich gelagerte Kettenangriffe, bei denen eine anfängliche Schwachstelle in Kombination mit einer zweiten Lücke plötzlich zu einer viel größeren Bedrohung wird, lassen sich derzeit auch bei Linux-Distributionen beobachten, wo eine einzelne übersehene Prüfung ausreichte, um ganze Update-Prozesse zu gefährden.

Déjà-vu: Die Vorgängerwelle aus 2025

Im Frühjahr 2025 veröffentlichte Broadcom, der heutige Eigentümer von VMware, das Advisory VMSA-2025-0004 mit drei zusammenhängenden Lücken. CVE-2025-22224, ein Heap-Overflow in der Virtual Machine Communication Interface (VMCI), wurde mit einem CVSS-Wert von 9,3 als kritisch eingestuft und erlaubte Angreifern mit Admin-Rechten in einer VM, Code in den VMX-Prozess des Hosts einzuschleusen. CVE-2025-22225 war ein Arbitrary-Write-Fehler im VMX-Kontext mit CVSS 8,2, der zu einem klassischen Sandbox-Escape führte. CVE-2025-22226 schließlich, eine Out-of-Bounds-Read-Lücke im Host-Guest-Filesystem (HGFS) mit CVSS 7,1, erlaubte das Auslesen von Speicherinhalten aus dem VMX-Prozess. Alle drei Lücken wurden laut Berichten bereits aktiv ausgenutzt, bevor die Patches breit ausgerollt waren.

Nur wenige Monate später folgte VMSA-2025-0013, erneut mit drei kritischen VM-Escape-fähigen Lücken: CVE-2025-41236 in VMXNET3, dem Standard-Netzwerkadapter in vielen ESXi-VMs, ein Integer-Overflow mit CVSS 9,3. CVE-2025-41237 traf wieder die VMCI, dieses Mal ein Integer-Underflow, ebenfalls CVSS 9,3. Und CVE-2025-41238 war ein Heap-Overflow im paravirtualisierten SCSI-Controller PVSCSI, erneut CVSS 9,3. Der Clou an dieser zweiten Welle: VMXNET3 und PVSCSI sind keine exotischen Sonderkonfigurationen, sondern in unzähligen Produktionsumgebungen der Standard. Wer eine ESXi-VM mit Standardeinstellungen aufsetzt, landet fast automatisch bei genau diesen Komponenten.

Warum ESXi ein Wiederholungstäter ist

Wenig überraschend taucht ESXi in der Sicherheitsberichterstattung immer wieder auf. Das liegt nicht daran, dass VMware besonders schlampig programmiert, sondern daran, dass Hypervisor-Software eine extrem komplexe Angriffsfläche bietet: Netzwerkadapter-Emulation, Speicherverwaltung, Dateisystem-Bridging zwischen Gast und Host, Interprozesskommunikation – jede dieser Schichten ist ein potenzielles Einfallstor. Und ESXi ist in Unternehmensrechenzentren so verbreitet, dass jede neue Lücke sofort eine enorme Angriffsfläche eröffnet.

Die Geschichte kennt bereits ein Beispiel, das zeigt, wie teuer Zögern werden kann. CVE-2021-21974, eine Heap-Overflow-Lücke im OpenSLP-Dienst von ESXi, wurde bereits im Februar 2021 gepatcht. Trotzdem warnte das BSI 2023 vor einer weltweit massiven Ausnutzung dieser längst bekannten Schwachstelle, die unter anderem für die ESXiArgs-Ransomware-Kampagne missbraucht wurde. Zwischen Patch-Verfügbarkeit und tatsächlicher Ausnutzung lagen also über zwei Jahre – nicht weil es keinen Fix gab, sondern weil zu viele Hosts einfach nie aktualisiert wurden. Das ist die eigentliche Lektion aus der ESXi-Historie: Die Lücke ist selten das Problem, das Patch-Management ist es.

Broadcom, Lizenzpolitik und die Frage nach der Update-Disziplin

Ein Aspekt, der in der reinen CVE-Betrachtung gerne untergeht, aber für die Praxis durchaus relevant ist: Seit der Übernahme von VMware durch Broadcom hat sich für viele Kunden nicht nur die Lizenzstruktur verändert, sondern auch die Art, wie Support-Verträge und Update-Zugänge organisiert sind. Wer als Unternehmen den Wechsel auf neue Lizenzmodelle noch nicht vollzogen hat oder sich in einer Übergangsphase befindet, läuft Gefahr, dass Patch-Zugänge nicht mehr so reibungslos funktionieren wie früher unter dem klassischen VMware-Supportmodell. Das ist kein Vorwurf an eine bestimmte Sicherheitslücke, sondern ein struktureller Hinweis: Genau in solchen Übergangsphasen – neue Verträge, neue Ansprechpartner, neue Download-Portale – passiert es überdurchschnittlich häufig, dass kritische Patches liegen bleiben, weil administrative Hürden den eigentlich einfachen technischen Schritt verzögern.

Wer also aktuell mit der Frage konfrontiert ist, ob der eigene Broadcom-Vertrag den Zugriff auf die neuesten ESXi-Builds überhaupt noch unkompliziert erlaubt, sollte diese Frage nicht erst dann klären, wenn das nächste kritische Advisory veröffentlicht wird. Die Erfahrung aus den vergangenen zwei Jahren zeigt, dass genau diese organisatorische Reibung – nicht die technische Komplexität des Patchens selbst – der größte Zeitfresser ist, wenn es darum geht, Hosts zügig auf einen sicheren Stand zu bringen.

Wer jetzt besonders genau hinschauen sollte

Betroffen von den 2025er Wellen waren neben ESXi 7.0 und 8.0 auch VMware Workstation 17.x, Fusion 13.x und VMware Tools – die Advisories richteten sich also nicht nur an Rechenzentrumsbetreiber, sondern auch an alle, die VMware Workstation Pro oder Fusion Pro lokal für Entwicklung und Tests nutzen. Für ESXi nannte Broadcom konkrete Patch-Builds: Gegen die VMSA-2025-0004-Lücken half ein Update auf mindestens ESXi 8.0U3d-24585383, 8.0U2d-24585300 beziehungsweise 7.0U3s-24585291. Für die zweite Welle, VMSA-2025-0013, waren Builds unterhalb von ESXi70U3w-24784741, ESXi80U2e-24789317 und ESXi80U3f-24784735 verwundbar.

Für die aktuelle Juli-2026-Meldung gilt sinngemäß dasselbe Prinzip, auch wenn konkrete Build-Nummern noch nicht flächendeckend kommuniziert sind: Wer seine ESXi-Version nicht kennt, sondern nur weiß „läuft ESXi 8, irgendeine Version“, hat bereits ein Problem. Die Build-Nummer, nicht die grobe Hauptversion, entscheidet darüber, ob ein Host verwundbar ist. Ein ESXi 8.0, das seit anderthalb Jahren nicht aktualisiert wurde, ist ein anderes Sicherheitsrisiko als ein ESXi 8.0 mit aktuellem Patch-Level, auch wenn beide sich nach außen identisch nennen.

Konkrete Schritte für Admins

Erste Maßnahme, wenig überraschend: Build-Nummer prüfen und mit den Angaben in den aktuellen Broadcom-Advisories abgleichen, sobald diese vollständig veröffentlicht sind. Wer produktive ESXi-Hosts betreibt, sollte das nicht auf die lange Bank schieben, denn die Erfahrung aus den 2025er Wellen zeigt, dass Exploit-Code für solche VM-Escape-Ketten erfahrungsgemäß zügig kursiert, sobald technische Details öffentlich werden.

Zweite Maßnahme: Prüfen, welche virtuellen Netzwerkadapter und Storage-Controller in den eigenen VMs tatsächlich genutzt werden. VMXNET3 und PVSCSI sind komfortabel und schnell, aber eben auch die Komponenten, die in der Vorgängerwelle im Zentrum standen. Das heißt nicht, dass man sofort auf Legacy-Adapter zurückgreifen sollte – das wäre Overengineering für ein Problem, das ein Patch löst. Es bedeutet, dass diese Komponenten priorisiert überwacht werden sollten, bis der Patch-Stand sauber ist.

Dritte Maßnahme, die oft vergessen wird: Segmentierung und Zugriffskontrolle innerhalb der VM-Landschaft. Wenn ein Angreifer ohnehin Admin-Rechte in einer VM braucht, dann ist jede Maßnahme, die diesen ersten Zugriff erschwert – Multi-Faktor-Authentifizierung, restriktive Berechtigungen, Monitoring auf ungewöhnliche Aktivität innerhalb der Gäste – eine zusätzliche Hürde vor der eigentlichen VM-Escape-Kette. Wer sich ausschließlich auf den Hypervisor-Patch verlässt und die VM-Ebene ignoriert, baut sich eine einzige Verteidigungslinie, wo eigentlich mehrere nötig wären.

Eine vierte, oft unterschätzte Maßnahme betrifft die Priorisierung innerhalb der eigenen Infrastruktur. Nicht jeder ESXi-Host verdient dieselbe Dringlichkeit: Hosts, auf denen VMs mit direktem Internetzugang, mit Kundendaten oder mit Zugriff auf sensible interne Systeme laufen, sollten zuerst bearbeitet werden. Ein internes Test-Cluster ohne Anbindung an Produktionssysteme kann in der Reihenfolge weiter hinten stehen, sollte aber trotzdem nicht dauerhaft ungepatcht bleiben, weil sich Testumgebungen in der Praxis erfahrungsgemäß gerne verselbstständigen und irgendwann doch produktive Daten enthalten. Eine ehrliche Inventarisierung, welcher Host welche Rolle spielt, ist damit fast wichtiger als die reine Patch-Geschwindigkeit.

Die Rolle von Cloud- und Telco-Umgebungen

Besonders unangenehm wird VM-Escape in Umgebungen, in denen ein physischer Host mehrere voneinander unabhängige Kunden bedient – klassisches Hosting, Cloud Foundation, Telco-Infrastruktur. Dort ist die Grenze zwischen Gast und Host nicht nur eine technische Feinheit, sondern die einzige Sicherheitsgarantie, die ein Anbieter seinen Kunden gegenüber überhaupt geben kann. Bricht diese Grenze, kann im schlimmsten Fall ein einzelner kompromittierter Mandant Zugriff auf die Infrastruktur aller anderen Mandanten auf demselben Host erhalten. Das ist der Grund, warum Broadcom in den Advisories explizit auch Cloud- und Telco-Produktlinien nennt: Diese Betreiber tragen ein strukturell höheres Risiko, weil sie kaum Kontrolle darüber haben, was Kunden in ihren eigenen VMs tun.

Wer als IT-Verantwortlicher selbst keine Hosting-Plattform betreibt, sondern nur intern ESXi für die eigene Serverlandschaft nutzt, ist tendenziell etwas besser dran – aber eben nur tendenziell. Auch interne Umgebungen haben Abteilungen, Dienstleister und Testsysteme, die nicht alle gleich vertrauenswürdig sind. Die Grundannahme „in unserem Netzwerk sind eh nur eigene Leute“ hält selten dem ersten Incident-Response-Bericht stand.

Ein Wort zur Verhältnismäßigkeit

Bei aller berechtigten Dringlichkeit lohnt sich an dieser Stelle auch ein nüchterner Gegenblick: Nicht jede Umgebung ist gleich stark gefährdet, und Panik ist selten ein guter Ratgeber für IT-Sicherheit. Für ein kleines Unternehmen mit einem einzelnen ESXi-Host, klar abgegrenztem Netzwerksegment und ohne Fremdzugriff durch externe Kunden ist das tatsächliche Risiko einer VM-Escape-Kette deutlich geringer als für einen Hosting-Anbieter mit hunderten Mandanten auf gemeinsam genutzten Hosts. Wer die verwundbare Komponente gar nicht einsetzt – etwa weil ausschließlich Legacy-Netzwerkadapter statt VMXNET3 verwendet werden –, ist von einer bestimmten Lücke unter Umständen überhaupt nicht betroffen.

Das entlastet niemanden von der grundsätzlichen Pflicht, Patches zeitnah einzuspielen. Es bedeutet aber auch, dass eine Bestandsaufnahme der eigenen Konfiguration sinnvoller ist als blinder Aktionismus. Wer weiß, welche Adapter, welche Controller und welche Zugriffsmodelle im eigenen ESXi-Cluster tatsächlich zum Einsatz kommen, kann das reale Risiko realistisch einschätzen, statt jede Schlagzeile über eine „kritische VMware-Lücke“ reflexhaft als unmittelbare Bedrohung für das eigene Setup zu werten. Diese Art der Einordnung erfordert aber eben genau die Inventarisierung, die im Alltag oft als lästige Pflichtübung gilt und deshalb gerne aufgeschoben wird – bis eine Woche wie diese sie plötzlich unverzichtbar macht.

Was bleibt?

Drei kritische Lücken in wenigen Tagen Berichterstattung, zwei fast identische Wellen im Jahr davor – der Befund ist ziemlich eindeutig: Hypervisor-Sicherheit ist kein einmal erledigtes Projekt, sondern eine Dauerbaustelle. Die eigentlich brisante Frage ist nicht, ob VMware wieder eine kritische Lücke findet, sondern ob die eigene Infrastruktur beim nächsten Advisory innerhalb von Tagen oder erst nach Monaten reagiert. Angesichts der ESXiArgs-Geschichte, bei der ein längst gepatchter Fehler noch Jahre später Schäden anrichtete, sollte diese Frage nicht rhetorisch bleiben. Wie lange würde es in Ihrer Umgebung dauern, bis der nächste kritische ESXi-Patch tatsächlich auf jedem betroffenen Host läuft?