Уязвимость в REST API Splunk позволяет злоумышленникам выполнять произвольные команды на сервере

Splunk

В экосистеме корпоративной кибербезопасности обнаружена опасная уязвимость, позволяющая выполнение произвольных команд на уровне операционной системы в популярных платформах для анализа данных Splunk Enterprise и Splunk Cloud Platform. Данный инцидент затрагивает тысячи организаций по всему миру, использующих эти системы для централизованного сбора логов, мониторинга безопасности и бизнес-аналитики. Уязвимость, получившая идентификатор CVE-2026-20163 и высокий балл CVSS 8.0, классифицируется как проблема неправильной нейтрализации входных данных (CWE-77) и представляет собой критический риск для целостности ИТ-инфраструктуры.

Уязвимость CVE-2026-20163

В основе уязвимости лежит ошибка в REST API платформы, а именно в эндпоинте "/splunkd/__upload/indexing/preview". Этот интерфейс отвечает за предварительный просмотр файлов, которые пользователи загружают в систему перед их индексированием. В процессе обработки используется параметр "unarchive_cmd", предназначенный для указания команды распаковки архивов. Однако из-за недостаточной проверки и очистки входных данных, передаваемых в этот параметр, злоумышленник может внедрить и выполнить произвольные команды оболочки операционной системы хост-сервера. Таким образом, рутинная операция загрузки файла превращается в канал для удаленного выполнения кода.

Важным ограничивающим фактором, снижающим непосредственную угрозу, является требование к правам доступа для эксплуатации этой уязвимости. Для успешной атаки злоумышленник должен обладать учетной записью с высокой привилегией "edit_cmd". Это означает, что рядовой пользователь не сможет инициировать атаку самостоятельно. Однако данное условие трансформирует уязвимость из удаленной в локальную с критическими последствиями для эскалации привилегий. Если учетные данные администратора или пользователя с необходимыми правами будут скомпрометированы в результате фишинга, утечки или другой атаки, злоумышленник сможет использовать эту брешь для полного захвата контроля над сервером Splunk. В свою очередь, это открывает путь к дальнейшему движению по корпоративной сети, компрометации данных и дестабилизации работы SOC (Security Operations Center, центра управления безопасностью).

Уязвимость затрагивает широкий спектр версий как локальных, так и облачных развертываний Splunk. В зоне риска находятся следующие версии программного обеспечения: Splunk Enterprise 10.0 от 10.0.0 до 10.0.3, версии 9.4 от 9.4.0 до 9.4.8, а также версии 9.3 от 9.3.0 до 9.3.9. Что касается облачной платформы Splunk Cloud Platform, то проблема присутствует в сборках, более старых, чем 10.2.2510.5, 10.0.2503.12, 10.1.2507.16 и 9.3.2411.24. При этом базовая версия Splunk Enterprise 10.2 не подвержена данной конкретной проблеме в REST API, что указывает на исправление ошибки в более новой ветке разработки.

Для защиты корпоративных сетей от потенциального выполнения произвольных команд администраторам необходимо в приоритетном порядке установить официальные обновления безопасности, выпущенные Splunk. Эти патчи исправляют недостатки очистки входных данных во всех затронутых ветках. В частности, требуется обновить Splunk Enterprise 10.0 до версии 10.0.4, версию 9.4 до 9.4.9, а версию 9.3 до 9.3.10. Для клиентов облачной платформы Splunk Cloud Platform компания-разработчик берет процесс обновления на себя, применяя исправления напрямую к размещенным экземплярам, однако владельцам таких решений рекомендуется уточнить статус своих сервисов у провайдера.

Помимо немедленного применения патчей, эксперты по безопасности рекомендуют пересмотреть и ужесточить политики управления доступом в системах Splunk. Следует строго придерживаться принципа наименьших привилегий, минимизируя количество учетных записей с возможностью "edit_cmd". Кроме того, необходимы усиленный мониторинг активности на критических эндпоинтах REST API и регулярный аудит логов на предмет подозрительных попыток загрузки файлов или выполнения нестандартных системных команд. Обнаружение подобных аномалий в работе SIEM-системы может стать ранним индикатором попытки эксплуатации уязвимости. Данный инцидент в очередной раз подчеркивает, что даже специализированное программное обеспечение для кибербезопасности не является неуязвимым и требует такого же внимательного подхода к обновлениям и конфигурации, как и любая другая часть ИТ-инфраструктуры.

Ссылки

Комментарии: 0