Интерфейс Patroni REST API на узле кластера поисковых голов Splunk Enterprise принимает запросы без проверки подлинности. Любой, у кого есть к нему сетевой доступ, может выполнить на сервере команды операционной системы. Учётные данные и действия со стороны пользователя не нужны, хватает сетевой достижимости интерфейса. Оценка уязвимости по шкале CVSS - 9.8 из 10, в классификации Splunk это высшая степень опасности. Исправление вышло в версиях 10.4.3 и 10.2.7.
Детали уязвимостей
Проблему отслеживают под идентификатором CVE-2026-76268. Обработчик Patroni REST API не требует аутентификации для критичных операций настройки, поэтому злоумышленник получает доступ к управлению конфигурацией. В базе слабостей это CWE-306, отсутствие проверки подлинности для важной функции. Уязвимость выявил сотрудник Splunk Габриэль Ниту, внутренний номер ошибки - VULN-79185.
Атака идёт по сети, сложность низкая, привилегии не требуются, взаимодействие с пользователем не нужно. Достаточно достучаться до нужного интерфейса. Уязвимы выпуски ветки 10.4 с 10.4.0 по 10.4.2 и ветки 10.2 с 10.2.0 по 10.2.6. Ветки 10.0.x и 9.4.x этой проблеме не подвержены, хотя обновления в них вышли в том же цикле и закрыли другие ошибки.
Patroni управляет PostgreSQL, который Splunk использует как вспомогательное хранилище. Сайдкар, то есть дополнительный процесс рядом с основным, включён по умолчанию: в файле server.conf для него задан параметр disabled = false. Рассчитывать на стандартный TCP-порт 8008 при этом не стоит. В документации Splunk он приведён только как пример. Если адрес службы не задан явно, IPC Broker, внутренняя служба обмена сообщениями, выделяет произвольный свободный порт. Поэтому проверять доступность интерфейса нужно по фактическим привязкам служб, а не по одному запомнившемуся номеру.
Вектор атаки описывает высокое влияние на конфиденциальность, целостность и доступность данных. Успешный взлом угрожает и раскрытию сведений, и изменению конфигурации, и работе сервиса. О случаях эксплуатации в реальных атаках Splunk не сообщает. Компания не уточняет, с какими правами выполняются команды, и не публикует готовый эксплойт. Риск зависит от того, доступен ли интерфейс Patroni из недоверенных сетей и сколько узлов кластера поисковых голов выставлено наружу.
В общей сложности в этом цикле Splunk устранила 17 уязвимостей - в самой платформе, в шлюзе Splunk Secure Gateway и в приложениях для Observability Cloud. Часть из них требует ручных действий после обновления, поэтому одним апгрейдом ограничиться не получится.
Высшая по оценке уязвимость - не единственная серьёзная в списке. Ещё одна проблема высокого уровня угрозы касается обновления Linux-пакетов. Локальный пользователь, который может запускать команды от имени учётной записи Splunk, способен добиться выполнения своих команд с правами root, если после изменения установки произойдёт обновление пакета. Оценка - 7.7 по шкале CVSS, идентификатор CVE-2026-76266. Условие срабатывания узкое, поэтому массовых атак здесь не ожидается. Обойти проблему можно, обновляя платформу из tar-архива, а не через пакетный менеджер системы.
Дальше идут ошибки со средними оценками. Внедрение SQL-кода в каталоге модулей SPL2 позволяет пользователю с правом на просмотр списка модулей добраться до чужих приватных описаний: значения из запроса не параметризовали перед обращением к базе. Некорректный контроль доступа при получении данных о поисковых заданиях даёт текст чужих запросов, метаданные, результаты и предварительный просмотр. Подмена исходящего запроса в приложении для Observability Cloud приводит к утечке токена API. Несколько проблем нашлось в Splunk Secure Gateway: пользователь без роли администратора может заставить шлюз подписывать подконтрольные ему данные и изменить списки получателей оповещений в хранилище "ключ - значение".
Есть и более скромные по последствиям ошибки. Подделка записей в журнале приложения, отказ в обслуживании из-за неэффективного регулярного выражения, доступ к исходному коду приложения через карты исходников в веб-интерфейсе, некорректная проверка имён индексов и учётных записей. Их оценки держатся в диапазоне от 4.1 до 6.5, но настройки в некоторых случаях всё равно требуются.
Обновиться нужно до Splunk Enterprise 10.4.3, 10.2.7, 10.0.10 или 9.4.15 - в зависимости от используемой ветки. Для части уязвимостей одного обновления мало. После апгрейда требуется прописать scripted_lookup_raw_write_enforcement = block в файле limits.conf в разделе [lookup] и перезапустить Splunk. Приложение Splunk Secure Gateway обновляют отдельно, до версий 3.10.11, 3.9.25 или 3.8.72.
Если установить исправление пока нельзя, а модули Edge Processor, OpAmp и конвейеры обработки данных SPL2 не используются, PostgreSQL-сайдкар можно выключить. В файле $SPLUNK_HOME/etc/system/local/server.conf в секции [postgres] выставляют disabled = true. Изменение вступает в силу после перезапуска Splunk Enterprise. Перед этим стоит убедиться, что на сайдкар не завязаны рабочие процессы: мера подходит не всем.
Общая черта большинства перечисленных проблем - не изощрённая техника атаки, а недостающие проверки прав на внутренних программных интерфейсах. Главный риск создаёт открытый сетевой доступ к служебным службам. Чем больше вспомогательных компонентов развёрнуто рядом с платформой, тем шире поверхность атаки. Проверка того, кто и на каком порту слушает в инфраструктуре, оказывается не менее важной, чем своевременная установка обновлений.
Ссылки
