VMware vCenter im CISA-KEV-Katalog: Warum Admins den Cybersecurity Patch jetzt priorisieren müssen

CVE‑2024‑37079. CVSS 9,8. Kein Login erforderlich. Aktiv ausgenutzt. Und seit Januar 2026 im CISA‑KEV‑Katalog. Wer vCenter administriert und jetzt noch wartet, spielt russisches Roulette mit seiner gesamten virtualisierten Infrastruktur.

Der Kronjuwel brennt – was im KEV‑Katalog wirklich steht

Der CISA Known Exploited Vulnerabilities Catalog ist kein akademisches Archiv. CISA nimmt dort nur Schwachstellen auf, für die verifizierte Exploitation vorliegt – nicht Proof‑of‑Concept‑Code auf GitHub, sondern echte Angriffe in echten Netzen. CVE‑2024‑37079 steht dort. Das ist der entscheidende Unterschied zu den Tausenden anderen CVEs, die jede Woche veröffentlicht werden und auf die kein einziger Angreifer je einen Exploit schreibt.

Plot Twist: Die Schwachstelle ist nicht neu. Broadcom hatte das Security Advisory VMSA‑2024‑0012 bereits im Juni 2024 veröffentlicht – inklusive Patches. Am 23. Januar 2026 aktualisierte Broadcom das Advisory mit einem Hinweis, den niemand ignorieren kann: Informationen über aktive Ausnutzung „in the wild“ liegen vor. CISA zog unmittelbar nach und listete CVE‑2024‑37079 im KEV‑Katalog. Wer seitdem noch auf „theoretisch ausnutzbar“ besteht, hat die letzten sechs Monate verschlafen.

Das Pikante daran: VMware vCenter ist in den meisten Rechenzentren das Nervenzentrum schlechthin. Wer vCenter kontrolliert, kontrolliert ESXi‑Hosts, virtuelle Maschinen, Netzwerke, Snapshots, Datastores – praktisch alles. Angreifer wissen das. Ransomware‑Gruppen und APT‑Akteure fokussieren sich seit Jahren zunehmend auf Hypervisor‑Management‑Ebenen, weil ein einziger Treffer dort mehr Schaden anrichtet als hundert kompromittierte Endpunkte. Wer vCenter als Angriffsziel versteht, versteht auch, warum diese Lücke in einer eigenen Prioritätsklasse landet.

Technischer Kern: Heap‑Overflow ohne Eintrittskarte

Die Schwachstelle steckt in der DCE/RPC‑Verarbeitung von VMware vCenter Server. Technisch handelt es sich um einen Heap‑Overflow beziehungsweise Memory Corruption im Prozess, der eingehende DCE/RPC‑Pakete verarbeitet. Ein Angreifer schickt speziell präparierte Netzwerkpakete an den zuständigen Endpunkt. Fertig. Kein Benutzerkonto, kein Passwort, kein Social Engineering.

Das ergibt einen CVSS‑v3.1‑Score von 9,8 – kritisch. Brisant ist nicht nur die Zahl, sondern die Kombination: Netzwerkzugriff genügt, Komplexität ist niedrig, keine Privilegien notwendig, keine Nutzerinteraktion erforderlich. Die Auswirkung ist Remote Code Execution im Kontext des vCenter‑Server‑Prozesses. Wer diesen Prozess kontrolliert, hat faktisch Root‑Rechte auf der Management‑Ebene der gesamten virtualisierten Infrastruktur.

Wenig überraschend: Sicherheitsforscher und Threat‑Intelligence‑Teams ordnen diese Kategorie von Lücken als High‑Value‑Target für Ransomware‑Operatoren ein. Ein kompromittierter vCenter‑Server erlaubt es, Ransomware gleichzeitig auf alle verbundenen VMs auszurollen – mit einem einzigen Befehl, ohne jeden einzelnen Host manuell anzugreifen. Administratoren, die das noch nicht mental verarbeitet haben, sollten das jetzt nachholen.

Was CISA KEV für Ihre Patch‑Priorisierung bedeutet

Für US‑Bundesbehörden gilt die Binding Operational Directive BOD 22‑01: Schwachstellen im KEV‑Katalog müssen innerhalb gesetzter Fristen gepatcht werden. Bei kritischen RCE‑Lücken in Infrastrukturkomponenten lagen diese Fristen in der Vergangenheit bei 21 Tagen. Europäische Behörden und private Unternehmen unterliegen dieser Direktive nicht – aber sie übernehmen die KEV‑Liste faktisch als Benchmark, weil sie das beste öffentlich verfügbare Signal für tatsächlich ausgenutzte Schwachstellen ist.

Der Clou: CVSS‑Scores allein taugen schlecht zur Priorisierung. Jede Woche erscheinen Dutzende CVEs mit CVSS 8 oder höher, von denen statistisch gesehen ein Bruchteil je aktiv ausgenutzt wird. Der KEV‑Katalog filtert genau diesen Bruchteil heraus. CVE‑2024‑37079 ist in diesem Filter drin. Threat‑informiertes Vulnerability Management bedeutet: zuerst patchen, was gerade angegriffen wird – nicht was den höchsten theoretischen Score hat.

Persönlich halte ich den KEV‑Katalog für eines der praktischsten kostenlosen Werkzeuge, die SOC‑Teams und Administratoren aktuell haben. Er ist keine Garantie, keine vollständige Liste, aber er ist ehrlich: Nur rein, was wirklich ausgenutzt wird. Das ist für die tägliche Prioritätssetzung wertvoller als jede automatisierte CVSS‑basierte Patch‑Queue.

Betroffene Versionen: Was Broadcom sagt – und was Sie prüfen müssen

Eine konkrete, vollständige Versionsmatrix gehört in das Broadcom Security Advisory VMSA‑2024‑0012.x (aktualisiert 23. Januar 2026) – und nur dorthin. Der Grund: Broadcom aktualisiert diese Tabelle laufend, zusätzliche Builds werden nachgepflegt, und ein Blog‑Artikel, der eine feste Versionsnummer nennt, ist drei Monate später möglicherweise irreführend.

Was sich sicher sagen lässt: Das Advisory benennt betroffene vCenter‑Server‑Versionen und listet die gepatchten Zielbuilds explizit auf. Admins sollten ihre lokale vCenter‑Build‑Nummer – abrufbar über das GUI oder via Kommandozeile – gegen diese Liste abgleichen. Nur Builds, die dort explizit als gepatcht markiert sind, gelten als nicht mehr verwundbar gegenüber CVE‑2024‑37079. Alles andere ist ein offenes Einfallstor, und gezielte Cyberangriffe auf Authentifizierungssysteme und Management-Ebenen zeigen, wie schnell Angreifer solche Lücken nach einem Advisory systematisch abzuscannen beginnen.

Wichtig: Es gibt laut CSIRT Nigeria und dem Broadcom Advisory keine bekannten effektiven Workarounds, die ohne Patch vollständigen Schutz bieten. Das ist kein Disclaimer‑Boilerplate. Das ist eine harte Aussage: Konfigurationsänderungen, Dienste‑Restarts oder Registry‑Tweaks ersetzen das Einspielen des Patches nicht. Wer das Advisory aus dem Juni 2024 kannte, es auf die lange Bank geschoben hat und jetzt denkt, Netzwerksegmentierung allein reiche – liegt falsch.

Netzwerksegmentierung: Der einzige sinnvolle Puffer, wenn Patching wartet

Patching ist Pflicht. Aber Patching in Produktionsumgebungen braucht manchmal ein Change‑Fenster, Freigabeprozesse oder Tests. In dieser Zwischenzeit gibt es einen einzigen Puffer, der wirklich etwas bringt: radikale Netzwerksegmentierung der Management‑Ebene.

vCenter sollte niemals direkt aus dem Internet erreichbar sein. Das klingt trivial, ist aber in der Praxis erschreckend oft nicht umgesetzt – besonders in gewachsenen Infrastrukturen, wo vCenter irgendwann einmal „schnell“ aufgesetzt wurde und das Netzwerkkonzept nie wirklich nachgezogen hat. Der Zugriff auf vCenter und ESXi‑Management‑Interfaces gehört in ein dediziertes, strikt kontrolliertes Admin‑Netz. Keine direkten User‑Zugriffe. Kein Routing aus Produktions‑VLANs.

Zusätzlich: Firewalls und IPS‑Systeme sollten DCE/RPC‑Traffic zu vCenter auf die absolut notwendigen Quell‑IP‑Ranges begrenzen. Jede Verbindung, die nicht von einem explizit autorisierten Admin‑System kommt, sollte geblockt und geloggt werden. Das ersetzt den Patch nicht – aber es verkleinert das Angriffsfenster auf die Zeit, bis das Change‑Fenster kommt. Authentifizierungssysteme, die auf diese Management‑Ebene zugreifen, verdienen dabei besondere Aufmerksamkeit: Kompromittierte Identitäten wären ein zweiter Angriffsvektor, den Segmentierung allein nicht abdeckt.

Logging und Monitoring: Wer schaut überhaupt zu?

Eine Frage, die sich jeder vCenter‑Admin jetzt stellen sollte: Würde mein SIEM oder mein IDS anschlagen, wenn jemand gerade aktiv CVE‑2024‑37079 ausnutzt? In vielen Umgebungen lautet die ehrliche Antwort: Nein.

vCenter‑Logs werden erschreckend selten aktiv überwacht. Der Standardfall ist: Logs laufen irgendwo hin, werden aufbewahrt, und im Ernstfall – also nach dem Incident – schaut jemand rein. Das ist Forensik, kein Detection. Für eine aktiv ausgenutzte RCE‑Lücke reicht Forensik nach dem Angriff nicht. Auffällige DCE/RPC‑Requests an den vCenter‑Endpunkt, unerwartete Prozess‑Spawns, Zugriffsmuster außerhalb der Geschäftszeiten – das alles sind Signale, die ein gut konfiguriertes SIEM in Echtzeit sehen könnte.

IDS‑ und IPS‑Anbieter haben Signaturen für bekannte vCenter‑Exploits. Ob diese Signaturen für CVE‑2024‑37079 aktuell sind und aktiviert wurden, ist eine Frage, die das Security‑Team heute beantworten sollte – nicht nächste Woche. VPN‑Gateways und Zero‑Trust‑Zugangslösungen können dabei helfen, den Perimeter um das Admin‑Netz so zu gestalten, dass unerwartete Verbindungsversuche bereits auf Netzwerkebene sichtbar werden. Für Umgebungen, in denen vCenter remote administriert wird, ist das keine Option, sondern Mindeststandard.

Historischer Kontext: vCenter ist kein Einzelfall

CVE‑2024‑37079 ist nicht die erste kritische vCenter‑Lücke im CISA‑KEV‑Katalog. CVE‑2023‑34048 – ebenfalls eine DCE/RPC‑basierte RCE‑Schwachstelle in vCenter – hatte denselben Weg: Advisory, Patches, dann Bestätigung aktiver Ausnutzung und KEV‑Eintrag. Das Muster ist konsistent: vCenter wird von Angreifern gezielt angegangen, weil es der Single Point of Control für virtuelle Infrastrukturen ist.

Das ist kein Zufall. Ransomware‑Gruppen wie die Betreiber von ALPHV/BlackCat oder verschiedene APT‑Cluster haben in den letzten Jahren bewiesen, dass sie Hypervisor‑Management‑Interfaces gezielt im Visier haben. Ein erfolgreicher vCenter‑Angriff kann innerhalb von Minuten eine gesamte VM‑Farm verschlüsseln oder exfiltrieren. Kein Endpoint‑Agent auf einzelnen VMs stoppt das, wenn die Management‑Ebene bereits kompromittiert ist. Endpoint Protection greift dort nicht.

Der anhaltende Trend ist eindeutig: Angreifer steigen eine Ebene höher. Nicht mehr einzelne Windows‑Server, nicht mehr einzelne Anwendungen – sondern die Plattformen, auf denen alles läuft. vCenter, Orchestrierungssysteme, Backup‑Infrastrukturen. Wer dort die Kontrolle hat, hat alles. Das erklärt, warum Broadcom‑VMware‑Advisories für vCenter mittlerweile in einer ähnlichen Aufmerksamkeitskategorie landen wie kritische Kernel‑Lücken.

Warum viele Umgebungen trotz bekannter Lücken ungepatcht bleiben

An dieser Stelle lohnt ein ehrlicher Blick auf die organisatorischen Realitäten, die dazu führen, dass Systeme wie vCenter monatelang nach einem Advisory ungepatcht bleiben. Häufig ist es keine Gleichgültigkeit, sondern eine Kombination aus strukturellen Hindernissen: Change‑Management‑Prozesse, die für Notfall‑Patches nicht ausgelegt sind; fehlende Test‑Umgebungen, in denen Patches vor dem Produktionseinsatz validiert werden können; und eine Risikoabwägung, die das Ausfallrisiko eines ungeplanten Wartungsfensters höher gewichtet als die abstrakt wirkende Bedrohung durch eine Sicherheitslücke.

Diese Abwägung kehrt sich mit dem CISA‑KEV‑Eintrag schlagartig um. Aktive Ausnutzung bedeutet: Das Risiko ist nicht mehr abstrakt. Die Wahrscheinlichkeit, dass ein Angreifer CVE‑2024‑37079 gegen eine verwundbare, erreichbare vCenter‑Instanz einsetzt, steigt mit jedem Tag, an dem Exploit‑Code zirkuliert und Angreifer ihre Scanning‑Aktivitäten auf bekannte Zielports intensivieren. In dieser Situation ist das Ausfallrisiko eines Patch‑Fensters das kleinere Problem. Ein kompromittierter vCenter‑Server erzeugt in der Regel einen weit längeren und kostspieligeren Ausfall als ein geplantes Wartungsfenster.

Für Teams, die intern Überzeugungsarbeit leisten müssen: Der KEV‑Eintrag ist ein starkes Argument gegenüber Entscheidern, die Patch‑Risiken gegen Betriebskontinuität abwägen. CISA‑KEV ist kein theoretisches Risiko-Framework – es ist ein behördlich verifiziertes Signal für laufende Angriffe. Das lässt sich in einem internen Eskalationsgespräch deutlich klar kommunizieren.

Praktische Handlungsschritte – Priorisierung ohne Ausrede

Schritt eins: Broadcom Security Advisory VMSA‑2024‑0012.x aufrufen. Betroffene Versionen gegen den lokalen vCenter‑Build abgleichen. Wenn der Build nicht auf der „fixed“-Liste steht, ist das System verwundbar. Diese Prüfung dauert zehn Minuten.

Schritt zwei: Wenn Patching nicht sofort möglich ist, vCenter‑Zugriff auf das Admin‑Netz beschränken. Alle direkten Verbindungen aus Produktions‑VLANs, aus dem Internet oder von nicht autorisierten Systemen blocken. DCE/RPC‑Traffic zu vCenter auf autorisierte Admin‑IPs begrenzen. Das Change‑Fenster für den Patch auf die nächstmögliche Gelegenheit vorziehen – idealerweise außerplanmäßig, wenn die Lage es erfordert.

Schritt drei: IDS/IPS‑Signaturen für CVE‑2024‑37079 aktivieren und prüfen. vCenter‑Logs in das SIEM einspeisen, falls noch nicht geschehen. Alerting auf ungewöhnliche Prozesse und Verbindungsmuster konfigurieren. Sicherheitsvorfälle in virtualisierten Umgebungen sind oft erst im Nachhinein sichtbar – wer Logging jetzt aktiviert, hat zumindest eine Chance auf Frühwarnung.

Schritt vier: Inventur der Authentifizierungswege zu vCenter. Multi‑Faktor‑Authentifizierung für alle vCenter‑Zugänge erzwingen. Privilegierte Accounts überprüfen, nicht mehr genutzte Konten deaktivieren. Ein Angreifer, der CVE‑2024‑37079 ausnutzt, braucht zwar keinen Login – aber nach der initialen Kompromittierung werden Credentials fast immer als nächstes abgegriffen, um den Zugang zu festigen.

Persönlich finde ich es bemerkenswert, wie oft bei kritischen Infrastrukturkomponenten wie vCenter dasselbe Muster auftaucht: Das Advisory kommt, der Patch ist da, und trotzdem bleiben Systeme monatelang ungepatcht – bis CISA die KEV‑Listung macht und plötzlich alle aufwachen. CVE‑2024‑37079 ist der nächste Beleg dafür. Die Frage ist, ob Ihr Team diesmal dazugehört oder nicht.

Was bleibt – und was Sie morgen früh prüfen sollten

Der CISA‑KEV‑Eintrag zu CVE‑2024‑37079 ist keine bürokratische Fußnote. Er ist das deutlichste Signal, das eine Sicherheitsbehörde senden kann: Diese Lücke wird gerade ausgenutzt. vCenter ist das Ziel. Kein Workaround schützt vollständig. Der Patch ist da.

Wie viele unverwundbare vCenter‑Instanzen in Ihrer Umgebung laufen gerade – und wissen Sie das mit Sicherheit?