Критическая уязвимость в Splunk Enterprise позволяет выполнить код без аутентификации через PostgreSQL sidecar

Splunk выпустил экстренные обновления безопасности для устранения критической уязвимости CVE-2026-20253 с оценкой CVSS 9.8 в продукте Splunk Enterprise. Уязвимость позволяет неаутентифицированному злоумышленнику создавать и усекать произвольные файлы через незащищённый эндпоинт PostgreSQL sidecar, что, по данным исследователей из watchTowr Labs, может быть развито до полноценного удалённого выполнения кода (RCE) без предварительной аутентификации. Затронуты версии 10.0.0–10.0.6 и 10.2.0–10.2.3; исправления доступны в версиях 10.0.7 и 10.2.4. Splunk Cloud не подвержен уязвимости. Учитывая публикацию технических деталей эксплуатации, обновление следует рассматривать как первоочередную задачу.

Суть уязвимости

Согласно официальному бюллетеню Splunk, корневая причина проблемы — полное отсутствие аутентификации на эндпоинте PostgreSQL sidecar. Любой пользователь, имеющий сетевой доступ к уязвимому экземпляру Splunk Enterprise, может вызывать файловые операции без предоставления учётных данных. Вендор формулирует это так: неаутентифицированный пользователь может создавать или усекать произвольные файлы через сервисный эндпоинт PostgreSQL sidecar.

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

• Splunk Enterprise 10.0.0–10.0.6 — исправлено в версии 10.0.7
• Splunk Enterprise 10.2.0–10.2.3 — исправлено в версии 10.2.4
• Splunk Enterprise 10.4 — не затронута
• Splunk Cloud — не затронут (PostgreSQL sidecar не используется в облачном продукте)

Цепочка эксплуатации: от записи файлов до RCE

Исследователи Пётр Базыдло и Йордан Ганчев из watchTowr Labs опубликовали детальный технический анализ, описывающий путь от примитива записи файлов до полноценного выполнения произвольного кода. Важно отметить: вендорский бюллетень подтверждает возможность неаутентифицированных файловых операций, тогда как полная цепочка RCE описана исследователями и пока не подтверждена независимо.

По данным исследователей, атака использует два эндпоинта:

• /v1/postgres/recovery/backup — для подключения к контролируемой атакующим базе данных и сброса её содержимого в произвольный файл на файловой системе Splunk
• /v1/postgres/recovery/restore — для загрузки вредоносного дампа в локальный экземпляр PostgreSQL с использованием параметра passfile, указывающего на файл /opt/splunk/var/packages/data/postgres/.pgpass, содержащий пароль пользователя postgres_admin

Ключевой элемент атаки — SQL-запросы, встроенные в дамп базы данных, выполняются экземпляром PostgreSQL в процессе восстановления. Это позволяет атакующему определить пользовательскую функцию, использующую lo_export — штатный механизм PostgreSQL для экспорта больших объектов (BLOB) в файлы на диске. Через эту функцию атакующий получает примитив контролируемой записи произвольного содержимого в файловую систему.

Для эскалации до выполнения кода, по данным watchTowr Labs, достаточно перезаписать Python-скрипт, который Splunk регулярно исполняет — например, /opt/splunk/etc/apps/splunk_secure_gateway/bin/ssg_enable_modular_input.py. После перезаписи вредоносный код выполняется в контексте процесса Splunk.

Полная последовательность атаки

1. Атакующий создаёт внешнюю базу данных PostgreSQL с конфигурацией, допускающей аутентификацию без пароля, и предоставляет достаточные привилегии для вызова функций вроде CREATE FUNCTION и lo_export
2. Через эндпоинт /backup дамп этой базы помещается на файловую систему Splunk
3. Через эндпоинт /restore вредоносный дамп загружается в локальный PostgreSQL, при восстановлении срабатывает вредоносная функция, записывающая контролируемый атакующим Python-скрипт на диск

Оценка воздействия

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

Оценка CVSS 9.8 отражает критичность: атака не требует аутентификации, может быть проведена удалённо и приводит к полной компрометации конфиденциальности, целостности и доступности. Наибольшему риску подвержены организации, чьи экземпляры Splunk Enterprise доступны из недоверенных сетевых сегментов.

На момент публикации подтверждённых случаев эксплуатации в реальных атаках не зафиксировано, а уязвимость не внесена в каталог CISA KEV. Однако публикация детального технического описания цепочки эксплуатации существенно повышает вероятность оппортунистических атак в ближайшие дни.

Рекомендации

• Немедленно обновите Splunk Enterprise до версий 10.0.7 или 10.2.4 в зависимости от используемой ветки
• Ограничьте сетевой доступ к эндпоинтам /v1/postgres/recovery/backup и /v1/postgres/recovery/restore средствами сетевого сегментирования и межсетевых экранов — как временная мера до обновления
• Проверьте целостность Python-скриптов в каталоге /opt/splunk/etc/apps/, в частности файла ssg_enable_modular_input.py, на предмет несанкционированных изменений
• Проанализируйте журналы доступа к PostgreSQL sidecar на наличие обращений к указанным эндпоинтам от неавторизованных источников
• Если используется Splunk Enterprise версии 10.4 или Splunk Cloud — обновление не требуется, эти продукты не затронуты

Сочетание максимальной критичности (CVSS 9.8), отсутствия необходимости в аутентификации и публично доступного описания полной цепочки эксплуатации делает CVE-2026-20253 одной из приоритетных уязвимостей для немедленного устранения. Организациям, использующим затронутые версии Splunk Enterprise, следует применить обновления в рамках экстренного цикла патчинга, не дожидаясь планового окна обслуживания, а до момента обновления — изолировать PostgreSQL sidecar от недоверенных сетей.