Статья Splunk уязвимость CVE-2026-20253: полный разбор атаки и защита SIEM

18 июня 2026 года CISA добавила CVE-2026-20253 в каталог Known Exploited Vulnerabilities с дедлайном на патч - три дня, до 21 июня. CVSS 9.8, вероятность эксплуатации по EPSS - 0.8817 (top 1% среди всех CVE в базе FIRST.org), подтверждённая active exploitation по данным Splunk PSIRT. Pre-auth arbitrary file creation/truncation через незащищённый PostgreSQL sidecar в Splunk Enterprise, с развитием до RCE (исследование watchTowr Labs) - причём на AWS-инсталляциях этот sidecar включён по умолчанию. Платформа, на которой строится весь детект SOC-команды, сама стала вектором проникновения. Ирония, которая дорого обходится.

Зачем атакующему ваш SIEM​

Компрометация Splunk Enterprise - не "ещё один RCE на сервере". Splunk хранит и обрабатывает логи всей инфраструктуры: события Active Directory, сетевой трафик, алерты EDR, аудит файловых систем. Получив контроль над SIEM, атакующий закрывает сразу три задачи:

• Полная разведка - карта инфраструктуры с IP-адресами, хостнеймами, учётками и паттернами поведения пользователей лежит в индексах Splunk. Не надо ничего сканировать - всё уже собрано за тебя
• Слепая зона - удаление или модификация логов скрывает следы lateral movement. SOC-аналитик не увидит алерт, если алерт удалён до появления в дашборде
• Доверенный хост - в типичных enterprise-развёртываниях Splunk-серверу открыт сетевой доступ к критическим сегментам (DC, серверы приложений) для сбора событий через WMI, WEC, syslog. Отличная точка для пивота

По оценке CISA SSVC, эксплуатация CVE-2026-20253 полностью автоматизируема (automatable: yes), технический импакт - тотальный (total). Массовое сканирование и exploitation возможны без участия оператора - достаточно скрипта.

Splunk Enterprise уязвимость: что затронуто и как определить риск​

CVE-2026-20253 - критическая уязвимость типа CWE-306 (Missing Authentication for Critical Function) в PostgreSQL sidecar service endpoint. По данным NVD, CVSS 3.1 score: 9.8 (Critical), вектор: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H.

Расшифровка каждого компонента CVSS-вектора:

Параметр	Значение	Что означает
AV:N	Network	Атака по сети, локальный доступ не нужен
AC:L	Low	Низкая сложность эксплуатации
PR:N	None	Привилегии не требуются
UI:N	None	Действие пользователя не нужно
C:H / I:H / A:H	High	Полный импакт на конфиденциальность, целостность, доступность

Затронутые версии Splunk Enterprise по данным вендора (Cisco/Splunk, advisory на advisory.splunk.com):

Ветка	Уязвимые версии	Исправлено в
10.2.x	10.2.0 - 10.2.3	10.2.4
10.0.x	10.0.0 - 10.0.6	10.0.7
10.4.x	Не затронута	-
9.4.x и ранее	Не затронута	-
Splunk Cloud Platform	Не затронута	-

Splunk Cloud Platform не подвержен уязвимости - PostgreSQL sidecars там не используются. Версии 9.4 и ранее не содержат компонент sidecar - он появился начиная с Splunk Enterprise 10.

Уровень риска по типу развёртывания​

По данным watchTowr Labs (Tier-1 research), конфигурация PostgreSQL sidecar различается в зависимости от способа установки:

Тип развёртывания	PostgreSQL sidecar	Уязвим из коробки
On-Premise Windows	Не установлен по умолчанию	Нет
AWS	Установлен и активирован	Да

Инсталляции Splunk Enterprise на AWS уязвимы без какой-либо дополнительной конфигурации. На On-Premise Linux sidecar может быть включён администратором для Edge Processor или SPL2-пайплайнов - такие инсталляции тоже в зоне риска.

Исследователи watchTowr Labs описали расширение импакта до полного pre-auth RCE через chaining с конфигурационными особенностями - шаги 4-7 ниже основаны на их исследовании и могут требовать дополнительных предусловий.

Шаг 1 - доступ к внутреннему сервису. PostgreSQL sidecar (splunk-postgres) слушает на loopback - вроде бы изолирован. Но главный веб-интерфейс Splunk (порт 8000, доступен по сети) проксирует запросы к sidecar через путь /en-US/splunkd/__raw/v1/postgres/. Сервис, который выглядит изолированным, торчит наружу через веб.

Шаг 2 - обход аутентификации. Recovery endpoints формально ожидают HTTP Basic Authorization header. На практике принимают любые credentials, включая пустые. Заголовок Authorization: Basic Og== (декодируется в : - пустой логин и пустой пароль) проходит "валидацию". Sidecar не выполняет никакой проверки - имя пользователя просто передаётся утилитам PostgreSQL. По документам - аутентификация есть. На практике - её нет.

POST /en-US/splunkd/__raw/v1/postgres/recovery/backup HTTP/1.1
Host: <target>
Content-Type: application/json
Authorization: Basic Og==

{"database":"search_metadata","backupFile":"../../../../../../tmp/testfile"}

Шаг 3 - произвольное создание файлов. Параметр backupFile используется как выходной путь для pg_dump без санитизации. Path traversal через ../../ создаёт пустой файл в произвольной директории файловой системы. Если файл уже существует - он усекается (truncate). Само по себе деструктивно, но ещё не даёт исполнение кода.

Шаг 4 - запись контролируемого содержимого. PostgreSQL позволяет передавать полную строку подключения через параметр database. Атакующий вставляет hostaddr=<attacker_ip> - и pg_dump подключается к PostgreSQL-серверу атакующего вместо локального. Удалённая БД настроена на беспарольный вход и содержит подготовленные данные - её содержимое дампится на файловую систему Splunk уже с реальным контентом. Элегантно и неприятно.

Шаг 5 - доступ к локальной БД. Splunk хранит credentials от локального PostgreSQL в файле /opt/splunk/var/packages/data/postgres/.pgpass. Через параметр passfile в строке подключения атакующий указывает путь к этому файлу - PostgreSQL читает пароль из .pgpass и аутентифицируется как привилегированный пользователь postgres_admin.

Шаг 6 - произвольная запись через SQL. Endpoint /v1/postgres/recovery/restore загружает дамп и выполняет содержащийся в нём SQL. Атакующий создаёт вредоносный дамп с функцией, использующей lo_export - стандартный механизм PostgreSQL для извлечения BLOB из базы в файл на диске. Результат: запись произвольного содержимого в произвольный файл на Splunk-сервере.

Шаг 7 - RCE. Атакующий перезаписывает Python-скрипт /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py, который Splunk периодически запускает как часть modular input. При следующем запуске - payload исполняется с правами сервисной учётной записи Splunk. Игра окончена.

Маппинг на MITRE ATT&CK​

Цепочка эксплуатации CVE-2026-20253 покрывает несколько тактик:

Тактика	Техника	ID	Шаг цепочки
Initial Access	Exploit Public-Facing Application	T1190	Шаги 1-2: HTTP-запрос через веб-интерфейс без аутентификации
Command and Control	Ingress Tool Transfer	T1105	Шаг 4: Подключение к PostgreSQL-серверу атакующего
Execution	Command and Scripting Interpreter	T1059	Шаг 7: Исполнение подменённого Python-скрипта
Execution	Service Execution	T1569.002	Шаг 7: Splunk как сервис запускает модифицированный модуль

Предусловия и ограничения техники​

Работает если:

• Splunk Enterprise версии 10.0.0-10.0.6 или 10.2.0-10.2.3
• PostgreSQL sidecar активирован (по умолчанию - только на AWS)
• Веб-интерфейс Splunk (порт 8000 или 8089) доступен атакующему по сети
• Атакующий может поднять внешний PostgreSQL-сервер, доступный с Splunk-хоста (шаг 4)

Не работает если:

• Splunk Enterprise 9.4.x и ранее - sidecar отсутствует
• Splunk Enterprise 10.4.0+ - уязвимость исправлена на уровне baseline
• Splunk Cloud Platform - sidecars не используются
• Sidecar явно отключён в server.conf (секция [postgres], disabled = true)
• Веб-интерфейс изолирован от недоверенных сетей - сетевая сегментация блокирует T1190
• Splunk-сервер не может устанавливать исходящие подключения к внешним PostgreSQL-серверам (egress filtering блокирует шаг 4)

Публичные PoC: репозиторий watchtowrlabs/watchTowr-vs-Splunk-CVE-2026-20253 на GitHub содержит detection artifact generator (не эксплойт - проверка уязвимости без выполнения RCE). Nuclei template CVE-2026-20253.yaml доступен в projectdiscovery/nuclei-templates для внешнего сканирования.

Обнаружение атак на SIEM: детект CVE-2026-20253​

Требования к окружению для детекта​

• Splunk Enterprise с включённым _internal index (активен по умолчанию)
• Sourcetype splunkd_access - логи HTTP-запросов к Splunk Web
• Сетевые логи (firewall, IDS/IPS) с фиксацией исходящих подключений от Splunk-сервера
• File integrity monitoring на сервере Splunk: auditd на GNU/Linux или сторонний FIM-агент

Индикаторы компрометации​

По данным watchTowr Labs и Rescana, при расследовании ищите следующие артефакты:

1. Аномальные HTTP POST-запросы к /v1/postgres/recovery/backup или /v1/postgres/recovery/restore через веб-интерфейс Splunk - любой такой запрос от внешнего IP подозрителен
2. Неожиданные файлы в /tmp/, /opt/splunk/var/run/supervisor/pkg-run/ или /opt/splunk/share/splunk/search_mrsparkle/exposed/
3. Модифицированные Python-скрипты в директории splunk_secure_gateway - в первую очередь ssg_enable_modular_input.py
4. Исходящие PostgreSQL-подключения - трафик от Splunk-сервера на порт 5432 к IP-адресам, не входящим в список доверенных хостов
5. Файл-маркер PoC - наличие watchTowr.txt в /opt/splunk/share/splunk/search_mrsparkle/exposed/ (артефакт публичного detection artifact generator от watchTowr Labs)

SPL-запросы для мониторинга безопасности Splunk​

Базовый запрос для обнаружения обращений к уязвимым endpoints в логах самого Splunk:

index=_internal (sourcetype=splunkd_access OR sourcetype=splunk_web_access)
  uri="*postgres/recovery/*" method=POST
| stats count values(uri) as paths by clientip, status
| sort -count

Запрос покрывает оба sourcetype - splunkd_access (порт 8089) и splunk_web_access (порт 8000), которые Splunk пишет по умолчанию в _internal index. Любой POST к recovery-эндпоинтам - повод для немедленного расследования. Легитимные backup/restore-операции PostgreSQL sidecar не выполняются через веб-интерфейс с внешних IP. Сохраните этот запрос как scheduled search с alert action - если он когда-нибудь сработает, у вас будет окно для реагирования.

Мониторинг файловой системы через auditd: если логи аудита индексированы в Splunk - ищите создание файлов процессом splunk-postgres за пределами стандартных директорий sidecar. Для внешнего сканирования периметра - Nuclei с шаблоном CVE-2026-20253.yaml из репозитория projectdiscovery/nuclei-templates.

Защита SIEM от атак: харденинг Splunk Enterprise​

Патч - приоритетное действие​

Обновление до исправленных версий закрывает уязвимость полностью:

• 10.2.x - обновить до 10.2.4 или выше
• 10.0.x - обновить до 10.0.7 или выше

Версия 10.4.0 не подвержена уязвимости. Полное руководство - в Splunk Security Advisory для CVE-2026-20253 на advisory.splunk.com.

Временная митигация: отключение sidecar​

Если немедленный патч невозможен - отключите PostgreSQL sidecar, добавив в $SPLUNK_HOME/etc/system/local/server.conf:

[postgres]
disabled = true

После изменения - перезапуск Splunk Enterprise. Побочный эффект: отключение ломает Edge Processor, OpAmp и SPL2 data pipelines. Если эти компоненты используются - взвесьте риск эксплуатации CVE-2026-20253 против потери этих функций. При CVSS 9.8 и active exploitation выбор обычно очевиден.

Сетевая изоляция management-интерфейсов​

Независимо от патча - management-интерфейсы Splunk не должны быть доступны из недоверенных сетей. На практике Splunk Web часто открыт широко для доступа аналитиков к дашбордам. Разграничьте: пользовательский веб-интерфейс для просмотра дашбордов - в одном сегменте, management API (порт 8089) и sidecar-эндпоинты - в изолированном VLAN с ACL по белому списку IP. Egress filtering от Splunk-сервера блокирует шаг 4 цепочки атаки - исходящее подключение к PostgreSQL-серверу атакующего.

Сравнение подходов к митигации​

Мера	Скорость	Побочные эффекты	Когда применять
Патч до 10.2.4 / 10.0.7	Средняя (плановое окно)	Нет	Основной подход
Отключение PostgreSQL sidecar	Высокая (правка конфига + рестарт)	Ломает Edge Processor, OpAmp, SPL2	Когда патч невозможен в ближайшие часы
Сетевая изоляция management	Средняя	Нет при корректной настройке	Дополнительная мера - всегда
Egress filtering (блокировка порта 5432 наружу)	Высокая	Нет, если Splunk не использует внешние PostgreSQL	Блокирует шаг 4 цепочки
Мониторинг IoC (SPL + FIM)	Высокая	Нет	Параллельно с любым подходом

Чеклист реагирования на CVE-2026-20253​

Готовый список действий - передайте администратору Splunk:

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

CVE-2026-20253 - из тех уязвимостей, после которых пересматриваешь подход к безопасности самой security-инфраструктуры. Три года администрирую Splunk в SOC, и до этого кейса management plane SIEM был для нашей команды "серой зоной" - мониторили всё, кроме себя. PostgreSQL sidecar появился в десятой версии, многие команды включили его для Edge Processor и SPL2-пайплайнов, не задумываясь о поверхности атаки. Результат: endpoint без аутентификации, проксируемый через веб-интерфейс, с полным CVSS 9.8.

Неудобная правда: CWE-306 - Missing Authentication for Critical Function - это не сложная логическая ошибка, не race condition и не side-channel. Это банальное отсутствие проверки аутентификации на критическом endpoint. Такое находят на CTF-задачах начального уровня. И это в продукте, который позиционируется как основа security operations. Мы привыкли доверять security-вендорам больше, чем остальному софту, и CVE-2026-20253 показывает, насколько это опасное допущение.

Вывод для моей команды: SIEM, SOAR, EDR-консоли - это software, и он ломается ровно так же, как любое веб-приложение. Splunk нужно включать в scope пентеста, ставить FIM на его директории, изолировать management-интерфейсы от пользовательских сегментов. Не "после того как разберёмся с основной инфрой", а в первую очередь - потому что компрометация SIEM делает невидимыми все остальные атаки. На codeby.net держим живой тред по threat hunting в этой группе TTP - присоединяйся.