Версия 4.2.1 продукта Elastic Cloud Enterprise закрывает уязвимости в системе управления развёртываниями

В Elastic Cloud Enterprise обнаружены уязвимости, которые позволяют повышать привилегии, обходить проверку прав и читать данные чужих развёртываний на том же хосте. Платформа управляет развёртываниями (deployment, отдельный набор кластеров Elasticsearch и связанных сервисов) и служебными хостами установки. Затронуты ветки 3.x и 4.x. Исправления вышли в версиях 3.8.6 и 4.2.1.

Обход авторизации, утечка секретов и подмена ссылок в ECE

Ряд проблем связан с обработкой символических ссылок. Символическая ссылка - файл, который указывает на другой файл; при неверной проверке пути платформа открывает не тот объект. Самая высокая оценка в наборе - 8.2 из 10, уровень High по классификации Elastic. Атака здесь локальная: код нужно запустить внутри контейнера развёртывания Elasticsearch или Enterprise Search, например через собственный плагин. Права требуются высокие, участие пользователя не нужно.

Что получает атакующий, зависит от конкретного случая. В одном он читает и удаляет данные других развёртываний на том же хосте, в другом читает и меняет их, а также обходит аутентификацию (вход без проверки учётных данных) и правит настройки соседних развёртываний. Для части этих случаев нужно, чтобы на одном хосте работало больше одного развёртывания.

Отдельная группа проблем касается учётных данных платформы. Хост, которым управляет атакующий, получает секреты, зарезервированные за другими ролями, и с ними забирает под контроль плоскость управления (control plane, часть платформы, которая управляет развёртываниями) вместе со всеми размещёнными развёртываниями. Атака идёт из соседнего сетевого сегмента, сложность низкая, привилегии высокие, участие пользователя не требуется.

Похожий результат даёт процедура ротации сертификатов. После её запуска платформа сохраняет данные, в которых остаются учётные данные и закрытые ключи удостоверяющего центра (компонента, который выпускает сертификаты). Читать их могут компоненты с низкими привилегиями, поэтому точкой входа становится любой хост установки. Второй случай того же типа касается сведений о служебных контейнерах: из них извлекаются токены ролей, а такой токен позволяет добавить в установку посторонний хост с нужным набором ролей.

Ещё одна уязвимость не требует доступа к хосту. Пользователь с правами только на чтение меняет общеустановочный параметр учётной записи, который доступен лишь администраторам платформы. Атака идёт по сети, привилегии низкие, участие пользователя не нужно, влияние на целостность ограниченное.

Elastic описала все случаи в уведомлениях с идентификаторами ESA-2026-211 по ESA-2026-222 от 29 октября 2026 года. Затронуты версии с 1.0.0 по 3.8.5 и с 4.0.0 по 4.2.0; у части проблем нижняя граница выше - 2.6.0 или 3.8.0. Для ветки 3.x исправление несёт версия 3.8.6, для ветки 4.x - версия 4.2.1. Один случай затрагивает только выпуски с 4.1.0 по 4.2.0 и только развёртывания с экземпляром Enterprise Search: в более ранних версиях этого кода нет. В записях CVE исправленная версия не указана, номер исправления назван лишь в уведомлениях Elastic.

Обходных мер Elastic не предлагает почти ни для одного случая. Исключение - история с ротацией сертификатов: если процедура запускалась, после обновления нужно выполнить её команду очистки с хоста, у которого есть роль director (узел, управляющий установкой), а до обновления не повторять ротацию. Для случая с токенами вендор советует отозвать постоянные токены ролей, которые больше не нужны, и добавлять новые хосты по одноразовым токенам. При этом Elastic предупреждает, что процедуры смены корневого пароля ZooKeeper и ключей удостоверяющего центра пока нет.

Сведений об эксплуатации в реальных атаках в уведомлениях нет. Индикаторы компрометации Elastic приводит только для одного случая: хост в списке хостов платформы, который организация не добавляла, может указывать на эксплуатацию. Дату публичного раскрытия деталей вендор не называет.

Порог входа у большинства описанных атак высокий: нужен административный доступ к хотя бы одному хосту установки или доступ к внутренним службам платформы из сети. Вендор рассчитывает, что хосты ECE и внутренняя сеть доступны только доверенным администраторам, и это ограничивает риск. Внешний злоумышленник без таких прав воспользоваться уязвимостями не может. Риск выше там, где несколько развёртываний делят один хост, где применялись постоянные токены ролей и где запускали ротацию сертификатов.

Что сделать администратору: обновить установку до 3.8.6 или 4.2.1, затем выполнить очистку данных ротации и отозвать ненужные постоянные токены. Пока обновление не установлено, отслеживать уведомления Elastic и не запускать ротацию сертификатов повторно.

Обход авторизации, утечка секретов и подмена ссылок в ECE

Ссылки