ESXi-Lücke mit niedriger Bewertung steht im KEV-Katalog der CISA

Wenn ein Administrator auf ESX bestimmte Aktionen ausführen kann, ohne dass sie im Log erscheinen, fehlt Ihrer Forensik ein Stück Beweiskette. Genau das beschreibt CVE-2026-41709: Broadcom stuft die Lücke als „Low“ mit CVSS 2,7 ein, sie ist seit Juli gepatcht, steht aber seit dem 28. Oktober im KEV-Katalog der US-Behörde CISA. Ein Workaround existiert nicht, der Fix kommt über die Updates. Die Frist bis zum 11. November gilt nur für US-Bundesbehörden.

Das ist kein Einbruchsweg, sondern eine Lücke in der Nachvollziehbarkeit. Betroffen sind alle, die ESXi betreiben und sich auf lokale Protokolle verlassen. Weitere Details zur Ausnutzung nennt die CISA nicht.

Eine Lücke in der Nachvollziehbarkeit statt eines Einbruchswegs

Broadcom beschreibt CVE-2026-41709 im Advisory VMSA-2026-0006 als „insufficient logging vulnerability“ in VMware ESX. Auf Deutsch: Das System protokolliert nicht ausreichend. Als bekannten Angriffsweg nennt der Hersteller wörtlich: „A malicious administrator could exploit this issue to perform certain operations without them being logged.“ Welche Operationen gemeint sind, steht weder im Advisory noch bei der CISA. Wer mehr behauptet, spekuliert.

Die Bewertung fällt niedrig aus. Broadcom ordnet die Lücke laut Advisory in den Bereich „Low“ ein, mit einem maximalen CVSSv3-Basiswert von 2,7. Der Vektor erklärt das: Die Lücke ist über das Netz erreichbar, setzt aber hohe Rechte voraus (PR:H) und wirkt sich nur geringfügig auf die Integrität aus. Vertraulichkeit und Verfügbarkeit bleiben unberührt. Als Schwäche führt die CISA im KEV-Eintrag CWE-778, also „Insufficient Logging“.

Entdeckt hat das Problem laut Broadcom Ian Barton von CrowdStrike. Das Advisory bündelt insgesamt fünf CVEs. Deren Gesamtschweregrad ist „Critical“, die Einzelwerte reichen von 2,7 bis 9,8. Wer das Advisory nur überfliegt, sollte also nicht den Gesamtwert auf diese eine Lücke übertragen: CVE-2026-41709 ist der leichteste Fall des Pakets.

Wichtig ist die Unterscheidung dreier Dinge. Die Schwachstelle ist von Broadcom dokumentiert und seit dem 29. Juli bekannt. Der theoretische Angriff setzt Administratorrechte voraus; wer sie hat, kann damit laut Hersteller Aktionen am Log vorbei ausführen. Die nachgewiesene Ausnutzung ergibt sich allein aus der KEV-Aufnahme. Wer sie ausgenutzt hat, wie und gegen wen, sagt die CISA nicht.

Für die Praxis heißt das: Die Lücke öffnet keine Tür, sie verwischt Spuren. Für Incident Response ist das trotzdem unangenehm. Ein Log ohne Eintrag sieht aus wie ein Zeitraum ohne Ereignis. Ein Workaround ist laut Broadcom-Matrix nicht vorgesehen („None“). Bleibt der Patch, und bis dieser eingespielt ist, die Frage, wie belastbar Ihre lokalen Protokolle für den betroffenen Zeitraum sind. Schwerere ESXi-Fehler gab es zuletzt mit drei kritischen ESXi-Lücken, die einen Ausbruch aus der virtuellen Maschine ermöglichen; sie gehören nicht zu dieser CVE, zeigen aber, wie breit das Spektrum der Funde ist.

Der von Broadcom angegebene Vektor CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N lässt sich für Verteidiger so lesen: Der Zugriff erfolgt über das Netzwerk, die Komplexität ist niedrig, es ist keine Nutzerinteraktion nötig. Entscheidend ist PR:H, denn es sind hohe Rechte erforderlich. Betroffen ist allein die Integrität (I:L), und zwar nur in geringem Umfang;

Als dm-Einordnung folgt daraus: Der niedrige Score von 2,7 beschreibt die Eintrittshürde, nicht den Wert einer fehlenden Spur. Relevant wird die Lücke dort, wo ein Administratorkonto missbraucht wird, etwa durch einen Insider oder durch übernommene Zugangsdaten. Dann entscheidet die Protokollierung darüber, ob sich Handlungen später rekonstruieren lassen.

Welche ESXi-Builds den Fix enthalten

Broadcom nennt je Produktlinie einen Fix-Stand für CVE-2026-41709. Das Advisory wurde am 29. Juli veröffentlicht und am 19. August aktualisiert (Version .2). Laut Broadcom sind die Patches kumulativ; ein späterer Build enthält also die früheren Korrekturen. Das erspart die Suche nach Einzelpatches, ersetzt aber nicht den Abgleich Ihres tatsächlichen Stands.

Die Fixed Versions laut Advisory im Überblick:

• VCF/vSphere Foundation ESX 9.1.x.x: ESXi-9.1.0.0-25370933
• VCF/vSphere Foundation ESX 9.0.x.x: ESXi-9.0.2.0100-25595025
• VMware ESX 8.0: ESXi80U3j-25429389
• VCF 5.x: Version 5.2.4, beschrieben im Async Patching Guide (KB88287)
• Telco Cloud Platform ESX 5.0.x und 5.1.x: KB449886

Für ESX 7.0 enthält die Matrix bei dieser CVE keinen Eintrag. Das ist eine Beobachtung, keine Entwarnung und keine Aussage über einen fehlenden Fix. Die Quellen sagen dazu schlicht nichts. Wer noch Hosts mit 7.0 betreibt, kann daraus weder ableiten, dass sie unbetroffen sind, noch, dass ein Patch kommt. Das Advisory selbst ist die Stelle, an der sich eine Klärung nachlesen lässt, sobald Broadcom die Matrix ergänzt.

So gehen Sie praktisch vor, als dm-Einordnung und nicht als Herstellervorgabe: Ermitteln Sie je Host den installierten Build, ordnen Sie ihn einer Zeile der Liste zu und vergleichen Sie ihn mit dem genannten Fix-Stand. Hosts, die mindestens den Fix-Build oder einen neueren tragen, gelten laut Hersteller als bereinigt. Hosts darunter gehören auf die Patchliste, auch wenn die Bewertung nur „Low“ lautet. Das Rating beschreibt die Wirkung der Lücke, nicht die Dringlichkeit im Kontext einer aktiven Beobachtung.

Etwas Aufwand verursachen gemischte Umgebungen. Wer VCF 5.x betreibt, aktualisiert laut Broadcom auf 5.2.4 und folgt dem Async Patching Guide; wer Telco Cloud Platform nutzt, findet die Anleitung in KB449886. Die Bezeichnungen der Builds unterscheiden sich je Linie deutlich, deshalb lohnt der Blick ins Advisory statt in ein Gedächtnisprotokoll. Die Angaben zu den Fixversionen stammen aus dem Advisory Broadcom VMSA-2026-0006.

Wer den Patch seit Juli eingespielt hat, ist hier fertig. Nach dem Update fehlen allerdings weiterhin die Spuren aus der Zeit davor: Der Fix schließt die Lücke, rekonstruiert aber keine nicht geschriebenen Einträge. Dieser Punkt führt zur Frage nach den Protokollen im letzten Abschnitt.

Die Quellen nennen also weder einen Fix noch eine Aussage, ob diese Version betroffen ist. Als dm-Einordnung gilt: Wer ESX 7.0 betreibt, sollte das nicht als Entwarnung lesen, sondern die Einstufung bei Broadcom direkt klären lassen.

Die Fixversionen dieser einen CVE sind daher nicht mit denen der übrigen Lücken gleichzusetzen. Prüfen Sie je CVE, welcher Build gefordert ist.

Warum der KEV-Eintrag trotzdem zählt

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptSecurity analyst in front of large screens with abstract timeline and log visualizations, one segment visibly missing as a gap, dark operations room. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.

Ein CVSS-Wert von 2,7 lädt dazu ein, den Fall zu den Akten zu legen. Die Aufnahme in den KEV-Katalog (Known Exploited Vulnerabilities) der CISA ändert die Lage. Der Katalog führt Schwachstellen, für die die Behörde eine Ausnutzung als nachgewiesen ansieht. Die CISA hat CVE-2026-41709 laut KEV-Feed am 28. Oktober aufgenommen; im Alert vom 28. Oktober steht sie als „Broadcom VMWare ESX Insufficient Logging Vulnerability“ unter zwei neuen Einträgen.

Die KEV-Kurzbeschreibung formuliert das Risiko so: Die Lücke könne einem Akteur mit Administratorzugriff erlauben, bestimmte Operationen ohne Protokollierung auszuführen. Mehr nennt die CISA nicht: keine Angreifergruppe, keine Kampagne, keine Angaben zu den betroffenen Operationen. Wir bleiben deshalb bei dem, was belegt ist, und ergänzen nichts.

Die Frist im Feed lautet 11. November. Sie ist verbindlich nur für Bundesbehörden der US-Zivilverwaltung (FCEB) nach der Anweisung BOD 26-04. Für Unternehmen in Deutschland ist sie keine Pflicht, wohl aber ein Orientierungspunkt: Wer einen Termin für das Patchen sucht, findet hier einen begründeten. Das ist dm-Einordnung, keine Vorgabe der CISA.

Beim Ransomware-Bezug steht im Feld knownRansomwareCampaignUse der Wert „Unknown“. Das heißt: Die CISA kennt keinen Zusammenhang oder gibt ihn nicht an. Es ist weder ein „Ja“ noch ein „Nein“. Wer daraus eine Verbindung zu Erpressungsangriffen ableitet, überdehnt die Quelle; wer sie ausschließt, ebenso.

Wie ordnet man den Widerspruch aus niedriger Bewertung und KEV-Eintrag ein? CVSS misst die technische Wirkung einer Lücke in der Regel isoliert. Die KEV-Liste fragt, ob etwas ausgenutzt wird. Eine Lücke, die Spuren verwischt, bringt in der Einzelbewertung wenig Punkte, ist für jemanden mit Adminrechten aber nützlich: Sie hilft, Aktionen unauffällig zu halten. Das ist eine Deutung, keine belegte Beobachtung; belegt ist nur die Aufnahme. Ähnlich gelagert war zuletzt der Fall, über den wir beim KEV-Eintrag einer VMware-vCenter-Lücke berichtet haben, ebenfalls mit Blick auf Administratoren.

Für Ihre Priorisierung folgt daraus: „Low“ und „ausgenutzt“ schließen sich nicht aus. Wer Patches nach CVSS sortiert, rutscht mit einer solchen Lücke ans Listenende, obwohl ein Behördenkatalog sie führt. Eine zweite Sortierachse nach KEV-Status ist deshalb eine naheliegende dm-Empfehlung.

Die dm-Rechnung zeigt den Abstand: Das Advisory erschien am 29.07.2026, die Aufnahme in den KEV-Katalog erfolgte am 28.10.2026. Der Juli hat ab dem 29. noch 2 Resttage (30. und 31.), dazu kommen 31 Tage im August und 30 im September sowie 28 Tage im Oktober. Das ergibt 2 + 31 + 30 + 28 = 91 Tage.

dm-Rechnung: Vom Advisory am 29.07. bis zur KEV-Aufnahme am 28.10. vergingen 91 Tage. Für Hosts, die seitdem ungepatcht blieben, bedeutet das rund drei Monate ohne verlässliche Protokollierung bestimmter administrativer Operationen. Welche Operationen betroffen sind, sagen die Quellen nicht. Als dm-Einordnung empfiehlt sich deshalb, die Zeit seit Veröffentlichung als Lücke in der Nachvollziehbarkeit zu behandeln und nach dem Update nicht davon auszugehen, dass sich die Zeit davor lückenlos belegen lässt.

Logs, die nicht auf dem Host liegen

Wenn ein Host bestimmte Operationen nicht protokolliert, hilft es, Ereignisse an einer zweiten Stelle zu erfassen. Die folgenden Punkte sind dm-Einordnung, keine Vorgaben von Broadcom oder CISA. Sie sollen die Frage beantworten, wie Sie nach einem Verdacht noch Aussagen treffen können, wenn das lokale Log schweigt.

Erstens: externe Protokollierung. Ein Host, der seine Meldungen an einen zentralen Loghost oder ein SIEM weiterleitet, ist von der Lücke nicht anders betroffen, aber Sie haben Vergleichsdaten. Was dort auftaucht und lokal fehlt, ist ein Hinweis; was an beiden Stellen fehlt, bleibt unklar. Wichtig: Die Quellen nennen nicht, welche Operationen unprotokolliert bleiben, deshalb kann niemand garantieren, dass ein externes Log sie abdeckt. Es erhöht die Chancen, mehr nicht.

Zweitens: Administratorrechte inventarisieren. Die Voraussetzung für den beschriebenen Angriff sind Adminrechte. Eine Liste, wer auf welchem Host und im Verwaltungssystem solche Rechte hat, verkleinert den Kreis der Möglichkeiten. Prüfen Sie dabei ungenutzte Konten, geteilte Zugänge und Dienstkonten. Je weniger Konten die Rechte tragen, desto leichter lässt sich später sagen, wer etwas getan haben kann.

Drittens: Build-Stände dokumentieren. Halten Sie je Host fest, seit wann welcher Build läuft. Das ergibt ein Datum, ab dem die Lücke geschlossen ist, und einen Zeitraum davor, für den Sie lokalen Einträgen nur eingeschränkt trauen. Die Lücke ist seit Juli behoben; wer erst später gepatcht hat, hat ein größeres Fenster.

Viertens: Änderungen gegenprüfen. Wo Sie Konfigurationen oder Rechte unabhängig vom Host nachvollziehen können, etwa über Änderungstickets, Verwaltungsprotokolle oder Backups mit Zeitstempeln, vergleichen Sie diese Daten mit den Host-Logs. Abweichungen verdienen eine Nachfrage. Dies ist ein Prüfansatz, der ohne Kenntnis der betroffenen Operationen auskommt.

Zum Umgang mit dem Ergebnis: Finden Sie Hosts, die unter dem Fix-Stand liegen, patchen Sie und notieren das Datum. Finden Sie Lücken zwischen lokalen und externen Logs, behandeln Sie diese als Befund für Ihre eigene Untersuchung. Kein Befund heißt hier nicht „nichts passiert“, sondern „mit diesen Mitteln nichts sichtbar“. Das ist unbequem, aber ehrlicher als ein grünes Häkchen.

Als dm-Einordnung gilt: Externe Logs sollten mindestens bis zum Datum zurückreichen, an dem der Patch für den jeweiligen Host eingespielt wurde, besser bis zur Veröffentlichung des Advisorys am 29.07.2026. Nur so lässt sich später vergleichen, welche Administratoraktionen extern sichtbar waren und welche lokal fehlen.

Prüfen Sie außerdem, ob die Aufbewahrungsfristen für Syslog-Ziele oder SIEM-Daten diesen Zeitraum abdecken und ob dort Zugriffe auf Verwaltungsschnittstellen mit erfasst werden. Eine Abweichung zwischen lokalem und externem Bestand ist dann ein konkreter Anlass zur Nachprüfung.