Splunk выпустила бюллетень по CVE-2026-20253 ещё 13 июня, и оценка CVSS 9.8 уже тогда намекала, что тянуть не стоит. 18 июня PSIRT компании подтвердил «ограниченную эксплуатацию» уязвимости в реальных атаках, а CISA в тот же день добавила её в каталог Known Exploited Vulnerabilities с дедлайном для федеральных агентств США — 21 июня. Три дня на патч в KEV дают редко.
Суть проблемы — в сервисе PostgreSQL-сайдкара, который в новых версиях Splunk Enterprise обслуживает бэкапы. Две конечные точки, /v1/postgres/recovery/backup и /v1/postgres/recovery/restore, оказались доступны без аутентификации. Этого достаточно, чтобы создать или обнулить произвольный файл на диске от имени сервиса.
Дальше исследователи собрали из этого полноценную цепочку до преаутентификационного RCE: атакующий выгружает подконтрольную ему базу на файловую систему, затем запускает восстановление, указав путь к passfile, выполняет свои SQL-функции для записи файлов и в итоге перезаписывает Python-скрипты, которые Splunk регулярно запускает сам. То есть код исполнится не в момент атаки, а по расписанию платформы — что заодно усложняет обнаружение.
Затронуты Splunk Enterprise 10.0.0–10.0.6 и 10.2.0–10.2.3. Исправления — в 10.0.7 и 10.2.4; ветка 10.4 не подвержена, Splunk Cloud тоже не затронут, поскольку PostgreSQL-сайдкары там не используются. Обидная деталь для многих команд: SIEM традиционно считают «внутренней» системой и не спешат её патчить — а здесь именно система, которая должна ловить атаки, оказалась точкой входа.
Что делать прямо сейчас. Порядок действий простой. Обновитесь до 10.0.7 или 10.2.4 — это единственное настоящее исправление. Если окно обслуживания на следующей неделе, до него закройте сетевой доступ к порту сайдкара: он не должен быть виден ни из интернета, ни из общей корпоративной подсети, только с самих узлов Splunk. Затем проверьте логи веб-слоя и прокси на любые обращения к /v1/postgres/recovery/* — легитимного трафика туда извне быть не должно, любая такая строка это индикатор компрометации. Если обращения нашлись, дальше смотрите целостность Python-скриптов в каталоге установки (сверьте с эталонной поставкой) и время их изменения, а также ищите свежие файлы в директориях, куда пишутся бэкапы. И на всякий случай ротируйте креды и токены, которые Splunk хранил или к которым имел доступ, — при успешной эксплуатации они утекли первыми.
Комментарии