6 часов

Splunk устранила более сотни уязвимостей в своих продуктах: от утечки данных до отказа в обслуживании

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

Детали уязвимостей

Суть происходящего - не просто плановое обновление сторонних библиотек. Splunk одновременно опубликовала шестнадцать бюллетеней безопасности (идентификаторы от SVD-2026-0501 до SVD-2026-0516). Тринадцать из них вышли 20 мая, ещё один - неделей раньше. Общий список уязвимых компонентов впечатляет: это Splunk Enterprise (версии от 9.3 до 10.2), Splunk Cloud Platform, Docker-образы Splunk, агенты AppDynamics (Java, Python, Database, Machine, Cluster, Private Synthetic, Apache Web Server), Splunk AI Toolkit, Splunk User Behavior Analytics и даже Splunk Add-on for Tomcat.

Наиболее опасные уязвимости, по мнению экспертов, - это три находки, получившие собственные CVE-идентификаторы (система идентификации общеизвестных уязвимостей). Первая из них, CVE-2026-20238, затрагивает Splunk AI Toolkit версий ниже 5.7.3. Она связана с неправильным наследованием ролей. Суть в том, что низкопривилегированный пользователь, не имеющий прав администратора или "power", мог получить доступ к данным, которые должны быть скрыты через фильтры srchFilter. Проблема возникла из-за того, что платформа комбинирует унаследованные фильтры поиска с помощью оператора OR, и встроенный фильтр для роли "user" переопределял более строгие ограничения на дочерних ролях. Проще говоря, сотрудник с минимальными правами мог читать логи и данные, доступные только администраторам. Хотя оценка CVSSv3.1 (стандарт оценки критичности уязвимостей) здесь всего 6,5 (средний уровень), на практике это прямой путь к утечке корпоративных секретов.

Вторая критическая уязвимость - CVE-2026-20239, получившая уже 7,5 балла (высокий уровень). Она обнаружена в Splunk Enterprise версий ниже 10.0.5 и 10.2.2, а также в облачных версиях ниже определённых сборок. Причина - отсутствие санитизации выходного буфера в компоненте TcpChannel. При сбоях сокета вся полезная нагрузка (payload) логов, включая сессионные куки и тела HTTP-ответов, попадала в журналы событий на уровне WARN. Любой пользователь, имеющий доступ к индексу _internal, мог просмотреть эти чувствительные данные. А ведь именно _internal часто открыт для ограниченного круга специалистов. Иными словами, злоумышленник, получивший даже низкие права, мог перехватить куки аутентификации администратора и полностью захватить хост.

Третья уязвимость - CVE-2026-20240 (оценка 7,1, высокий уровень) - представляет собой отказ в обслуживании (denial of service). Она затрагивает Splunk Enterprise версий ниже 10.2.2, 10.0.5, 9.4.11 и 9.3.12, а также облачные платформы. Проблема - отсутствие проверки входных данных в скрипте coldToFrozen.sh, который входит в состав приложения splunk_archiver. Низкопривилегированный пользователь мог передать скрипту произвольный путь к каталогу, и тот переименовывал критически важные директории Splunk, делая экземпляр полностью неработоспособным. По сути, это способ "уронить" всю систему мониторинга, не имея высоких прав.

Помимо этих трёх главных брешей, почти все бюллетени посвящены обновлению сторонних пакетов. Например, в Splunk Enterprise обновлены библиотеки Go (golang) для исправления критических уязвимостей в бинарных файлах spl2-orchestrator и splunk-edge. В Docker-образе Splunk удалены или обновлены опасные зависимости - aiohttp, certifi, urllib3, криптография и другие. В агентах AppDynamics пересобраны OpenSSL, musl, log4j-core, netty, jetty - список можно продолжать долго. Особняком стоит Splunk User Behavior Analytics (UBA): там обновлены Apache Spark, Hive, Parquet, Python, Node.js и даже сам docker-ce. В Splunk Add-on for Tomcat поднята версия Apache Log4j с 2.17.1 до 2.25.3, чтобы закрыть CVE-2025-68161.

С точки зрения последствий, потенциальный ущерб для бизнеса огромен. Splunk - это "нервная система" многих компаний, через которую проходят логи всех ИТ-систем. Если злоумышленник получает доступ к этой платформе, он может не только украсть данные, но и заметать следы, ведь логи перестают быть надёжным источником. Атаки на основе описанных уязвимостей могут привести к утечкам персональных данных, остановке процессов мониторинга и, как следствие, к финансовым потерям. Особенно тревожит, что многие бреши эксплуатируются с низкими привилегиями - это означает, что даже стандартная учётная запись пользователя может стать точкой входа для хакера.

Администраторам безопасности следует без промедления обновить все затронутые компоненты до версий, указанных в бюллетенях: Splunk Enterprise - до 10.2.3, 10.0.6, 9.4.11 или 9.3.12; Splunk AI Toolkit - до 5.7.3; Splunk Universal Forwarder - до 9.4.11; агенты AppDynamics - до 26.4.0 (кроме Python Agent - до 26.4.1); Add-on for Tomcat - до 3.3.1; UBA - до 5.4.5. Docker-образы следует пересобрать с тегами latest или указанными в документации (10.2.2, 10.0.5, 9.4.10, 9.3.11). Тем, кто пока не может обновиться, Splunk рекомендует временные меры: для уязвимости в AI Toolkit - отключить приложение или вручную удалить строку srchFilter из файла конфигурации; для уязвимости с логами - ограничить доступ к индексу _internal только администраторами; для отказа в обслуживании - отключить приложение splunk_archiver (это остановит автоматический перенос данных в холодное хранилище).

Важно понимать: это не просто очередной патч-вторник. Масштаб исправлений говорит о том, что Splunk системно пересматривает архитектуру безопасности своих продуктов. Учитывая, что платформа обрабатывает терабайты чувствительной информации, промедление с обновлением может стоить дорого. Специалистам по кибербезопасности стоит также обратить внимание на общий тренд: множество уязвимостей связано со сторонними библиотеками, особенно в агентах и дополнениях. Значит, процессами управления зависимостями нужно заниматься не менее тщательно, чем настройкой политик доступа.

Детали уязвимостей

Ссылки