Splunk CVE-2026-20253: Неаутентифицированный RCE через сайдкар PostgreSQL

Каждый инженер платформы, когда-либо выставлявший Splunk за внутренний балансировщик нагрузки, только что потерял выходные. CVE-2026-20253 — именно тот тип раскрытия уязвимости, который превращает пятничный стендап в экстренный тикет на изменение. Сайдкар PostgreSQL поставлялся без аутентификации, с двумя REST-эндпоинтами и чистым путём от неаутентифицированного сетевого доступа до удалённого выполнения кода от имени пользователя Splunk.

Splunk, теперь входящий в состав Cisco, выпустил исправления на этой неделе. В пятницу watchTowr Labs опубликовала полную цепочку эксплойта. Данных об активной эксплуатации в дикой природе пока нет, однако технический разбор достаточно подробен, чтобы оппортунистическое сканирование стало вопросом дней, а не месяцев.

Что произошло

Splunk выпустил обновления безопасности для критической уязвимости в Splunk Enterprise, получившей идентификатор CVE-2026-20253 и оценку 9.8 по шкале CVSS. Как сообщает The Hacker News, ошибка позволяет неаутентифицированным пользователям выполнять файловые операции и удалённое выполнение кода через эндпоинт сервиса сайдкара PostgreSQL, лишённый механизмов контроля аутентификации.

По словам самого Splunk, «неаутентифицированный пользователь мог создавать или усекать произвольные файлы через эндпоинт сервиса сайдкара PostgreSQL» на версиях ниже 10.2.4 и 10.0.7. Splunk Enterprise от 10.0.0 до 10.0.6 исправлен в версии 10.0.7. Версии от 10.2.0 до 10.2.3 исправлены в 10.2.4. Версия 10.4 не затронута. Splunk Cloud также вне зоны риска, поскольку сайдкары Postgres в этом продукте не используются.

Технические подробности предоставили исследователи watchTowr Labs — Пётр Базыдло и Йордан Ганчев — опубликовавшие цепочку в пятницу. Два уязвимых эндпоинта, /v1/postgres/recovery/backup и /v1/postgres/recovery/restore, открыты без какой-либо аутентификации. Далее атакующий подключает эндпоинт резервного копирования к подконтрольной ему базе данных, скачивает дамп в файловую систему Splunk и воспроизводит его через restore. Шаг восстановления принимает аргумент passfile, указывающий на /opt/splunk/var/packages/data/postgres/.pgpass, который хранит пароль пользователя postgres_admin.

Это даёт выполнение SQL внутри локального экземпляра PostgreSQL. Оттуда атакующий злоупотребляет lo_export для записи произвольного содержимого в любое место на диске. Финальный переход к RCE прямолинеен: нужно перезаписать Python-скрипт, который Splunk регулярно выполняет — в демонстрационном эксплойте это файл /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py — и подождать. Никаких учётных данных. Никакого взаимодействия с пользователем. Никакого объединения CVE не требуется.

Техническая анатомия уязвимости

Природа этой ошибки до боли знакома. Команда строит микросервис с чистым HTTP API для внутренней оркестрации, полагает, что сетевой периметр является границей аутентификации, и отгружает продукт. Сайдкар PostgreSQL в Splunk Enterprise — именно такой случай. Эндпоинты резервного копирования и восстановления, предназначенные для внутренних рабочих процессов восстановления, открыты на порту, доступном всему, что может общаться с хостом Splunk.

Шаг первый в цепочке: атакующий поднимает экземпляр PostgreSQL с беспарольной аутентификацией и правами, достаточными для вызова lo_export. Шаг второй: обращение к /v1/postgres/recovery/backup на цели с указанием на базу данных атакующего. Сайдкар Splunk послушно сбрасывает содержимое удалённой БД в локальную файловую систему. Шаг третий: обращение к /v1/postgres/recovery/restore с аргументом passfile, указывающим на локальный файл .pgpass, что передаёт процессу восстановления пароль postgres_admin на локальном экземпляре.

В процессе восстановления SQL из этого дампа выполняется против локального PostgreSQL. Исследователи создали дамп, определяющий функцию с вызовом lo_export, которая извлекает большой бинарный объект и записывает его как файл. Это даёт примитив произвольной записи файлов с привилегиями процесса PostgreSQL в Splunk. Как выразились Базыдло и Ганчев: «Получив возможность восстанавливать подконтрольный атакующему SQL в локальный экземпляр PostgreSQL, мы быстро собрали шаблон дампа базы данных, дающий контролируемую запись файлов».

Эскалация до RCE — самая лёгкая часть. Splunk Secure Gateway запускает Python-скрипты по собственному расписанию. Перезапишите ssg_enable_modular_input.py, дождитесь следующего вызова — и ваша полезная нагрузка выполнится в контексте Splunk. Вся цепочка механична. Никакого повреждения памяти, никаких гонок, никаких экзотических примитивов. Это тот вид эксплойта, который будет превращён в модуль Metasploit в течение недели. Следите за записью в базе данных MITRE CVE для получения последующих уведомлений.

Кто пострадает

Splunk Enterprise находится в центре конвейеров обнаружения угроз для банков, бирж, операторов iGaming, рекламных сетей и большинства SOC из списка Fortune 500. В этом и заключается болезненность ситуации. Система, которой вы доверяете обнаружение инцидентов, сама является уязвимой мишенью. По опыту производственных инцидентов: когда стек логирования или наблюдаемости падает, команды защиты теряют видимость именно в тот момент, когда она нужна больше всего. Атакующие это знают. Предварительно-аутентифицированный RCE в Splunk — это не цель для кражи учётных данных; это цель для «ослепления защитников».

Оценка CVSS 9.8 — не маркетинг. Она отражает сетевой вектор атаки, отсутствие необходимых привилегий, отсутствие взаимодействия с пользователем и полное воздействие на конфиденциальность, целостность и доступность. Для регулируемого оператора iGaming, использующего Splunk как систему учёта активности игроков, эта оценка означает немедленные проверки соответствия требованиям. Аудиторы захотят знать сроки применения патчей, сетевую доступность затронутых портов и факты аномальной записи файлов в дерево /opt/splunk/etc/apps/.

Команды, использующие Splunk Cloud, здесь в безопасности. Сайдкары PostgreSQL в этом продукте не используются. Все, кто работает на самостоятельно размещённом Enterprise между 10.0.0 и 10.0.6 или 10.2.0 и 10.2.3, должны принять меры. Инсталляции версии 10.4 могут не беспокоиться по поводу этого CVE.

Моё мнение: сильнее всего пострадают те операторы, которые считают Splunk «внутренней» инфраструктурой и никогда не ставили его за настоящий прокси аутентификации или политику сетевой сегментации. В командах, с которыми мне приходилось работать, порты индексеров и управления регулярно оставались доступными через плоские VLAN, потому что «это за файрволом». Именно это допущение наказывает данный CVE. Если ваш узел Splunk доступен с ноутбука разработчика, он доступен и с ноутбука скомпрометированного разработчика.

План действий для команд безопасности

Сначала патч, затем расследование, затем рефакторинг. Неудобная правда: если вы всё ещё работаете на 10.0.x или 10.2.x с открытым уязвимым сайдкаром, считайте, что временной горизонт для оппортунистического сканирования — дни, а не недели. Разбор watchTowr настолько подробен, что работа по созданию эксплойта фактически завершена.

Действия на эту неделю:

• Немедленно обновите Splunk Enterprise до версии 10.0.7, 10.2.4 или 10.4. Никакого промежуточного этапа дольше 48 часов для производственных индексеров.
• Проверьте сетевую доступность эндпоинтов сайдкара PostgreSQL. Два пути для поиска в логах файрвола и WAF: /v1/postgres/recovery/backup и /v1/postgres/recovery/restore.
• Вычислите хеши и мониторьте содержимое /opt/splunk/etc/apps/splunk_secure_gateway/bin/ и смежных каталогов приложений. Любая неожиданная модификация ssg_enable_modular_input.py является индикатором компрометации.
• Проверьте наличие неожиданных файлов, записанных в пути, доступные пользователю Splunk. Ошибка предоставляет произвольную запись файлов, а не только тот скрипт, который был целью в PoC.
• Ежедневно сверяйтесь с каталогом CISA KEV для получения обновлений о статусе активной эксплуатации.

В ближайшие 90 дней структурным решением является сегментация. Индексеры и поисковые узлы Splunk не должны быть доступны на управляющих портах из общекорпоративных сетей. Поместите их за бастионный хост или сервисную сетку с принудительным mTLS. По умолчанию относитесь к каждому внутреннему сайдкару как к публичному эндпоинту — именно так придёт следующая подобная ошибка.

Ключевые выводы

• CVE-2026-20253 — предварительно-аутентифицированный RCE с оценкой CVSS 9.8 в сайдкаре PostgreSQL Splunk Enterprise. Обновитесь до 10.0.7, 10.2.4 или 10.4.
• Цепочка эксплойта злоупотребляет /v1/postgres/recovery/backup и /v1/postgres/recovery/restore совместно с lo_export для произвольной записи файлов, затем перезаписывает запланированный Python-скрипт для выполнения кода.
• Splunk Cloud не затронут. Пользователи самостоятельно размещённого Enterprise в уязвимых диапазонах версий — затронуты.
• Данных об активной эксплуатации пока нет, однако публичный технический разбор watchTowr делает оппортунистическое сканирование весьма вероятным в течение нескольких дней.
• По умолчанию считайте внутренние сайдкар-сервисы ненадёжными. Сетевое положение — это не аутентификация, и данный CVE тому доказательство.