Kibana закрывает три уязвимости, включая перехват данных между командами

Elastic исправила в Kibana три уязвимости, связанные с проверкой прав доступа. Наиболее значимая из них позволяет пользователю с ограниченными полномочиями перенаправить чужой поток данных на подконтрольную инфраструктуру. Оценка 8.8 по шкале CVSS 3.1 - это высокий уровень угрозы. Речь идёт о развёртываниях с включённым Fleet, где оператор без полного административного доступа получает право устанавливать собственные пакеты интеграций. Под удар попадают и локальные установки, и размещённые в Elastic Cloud Hosted. Две другие уязвимости получили средние оценки, 4.3 и 6.5, однако их последствия ощутимо различаются. Под арендатором в бюллетене понимается не отдельная организация в Elastic Cloud, а пользователь или команда, работающие в одном развёртывании Kibana.

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

Kibana служит панелью для работы с данными Elasticsearch. Через неё смотрят журналы приложений, метрики и события информационной безопасности. Компонент Fleet управляет агентами сбора данных, которые ставят на серверы и рабочие станции. Права в этой связке распределяют гибко, чтобы инженеры не получали лишнего доступа, и именно такая гибкость открыла лазейку.

Механика первой уязвимости (CVE-2026-102406) строится на подмене ключа. Пользователь с делегированными правами на управление пакетами Fleet указывает идентификатор потока данных, который уже занят другой командой. Kibana не проверяет, кому принадлежит этот идентификатор, и применяет настройки индекса и конвейера приёма данных к чужой инфраструктуре. В итоге записи второй команды начинают поступать на узлы, которыми распоряжается атакующий. Он читает их, меняет по своему усмотрению и не пропускает дальше по маршруту. Пострадавшая сторона теряет часть данных, а оставшиеся приходят с искажениями. Тип ошибки разработчики описали как обход авторизации через управляемый пользователем ключ.

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

Вторая уязвимость (CVE-2026-102410) относится к компоненту Metrics Experience. Один из внутренних программных интерфейсов не выполнял проверку прав на уровне Kibana, хотя родственный интерфейс в том же компоненте её делал. Из-за этого пользователь с правом чтения индекса на уровне хранилища, но без соответствующего права в Kibana, мог получить производные метрики. Оценка - 4.3. Проблема касается версий с 9.2.0 по 9.3.8; ветка 8.x не затронута, поскольку функциональность появилась позже. В версии 9.4.0 компонент убрали целиком, так что исправление сводится к переходу на 9.4.0 или новее. Обходных путей нет, а ветки 9.2.x и 9.3.x новых выпусков больше не получают.

Третья уязвимость (CVE-2026-102412) связана с хранением закрытых ключей. Аутентифицированный пользователь с ограниченными правами управления Fleet мог добраться до криптографического материала, предназначенного для подключения к хостам Fleet Server. Такие ключи подтверждают подлинность узлов при обмене данными. Получив их, злоумышленник способен выдать себя за доверенный компонент инфраструктуры. Оценка - 6.5. Уязвимы версии с 9.3.0 по 9.3.8, с 9.4.0 по 9.4.7 и с 9.5.0 по 9.5.4. Ветка 8.x не подвержена проблеме. Исправление вошло в 9.4.8 и 9.5.5, для 9.3.x патча нет.

Первая уязвимость закрыта в версиях 8.19.22, 9.4.7 и 9.5.4. Уязвимы были все выпуски 8.x начиная с 8.14.0, а также 9.0.0-9.4.6 и 9.5.0-9.5.3. До обновления администраторам стоит убрать у ролей право устанавливать собственные пакеты интеграций и оставить такую возможность только полным администраторам. Права на управление агентами Fleet тоже лучше снять у тех, кому не нужен доступ к настройкам Fleet Server. Облачная версия Serverless получила исправление до публикации бюллетеня, поскольку там патчи ставят непрерывно.

Три ошибки собрались вокруг одной темы - разграничения прав в Fleet. Модель доверия здесь опирается на идентификаторы и привилегии, которыми управляет сам пользователь, а проверки владения выполняются не везде. Пока так, роль "чуть выше обычной" остаётся достаточным условием для перехвата чужих данных. Для организаций, которые держат в Kibana журналы доступа и служебные метрики, перенаправление потока означает утечку вполне конкретных сведений, а не абстрактный риск. Восстановление после такой атаки требует не только обновления, но и ревизии инфраструктуры.

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

Ссылки