Десять уязвимостей в Elasticsearch позволяют получить полный контроль над кластером и раскрыть данные из чужих индексов

Elastic закрыла десять уязвимостей в поисково-аналитической платформе Elasticsearch. Семь из них ведут к отказу в обслуживании, две связаны с проверкой прав доступа, ещё одна открывает доступ к содержимому закрытых индексов. Оценки по шкале CVSS разошлись от 4.3 до 7.2. Выше семи баллов оказались только две проблемы, остальные восемь остались в средней категории. Затронуты ветки 8.x и 9.x, то есть и самостоятельно развёрнутые кластеры, и облачные развёртывания Elastic Cloud Hosted. Сервиса Elastic Cloud Serverless это не касается: там исправления применили до публикации бюллетеней.

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

Больше половины списка устроено по одной схеме. Пользователь с действительной учётной записью отправляет запрос, и узел кластера прекращает работу. В первом случае неконтролируемый рост памяти в движке обработки вызывает запрос на языке ES|QL. Узел исчерпывает доступную память и останавливается. Повторять такую попытку можно сколько угодно, вдобавок запрос удаётся спрятать внутри общих ресурсов. Кластер теряет доступность надолго, а права у атакующего могут быть минимальными.

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

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

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

Самой серьёзной оказалась ошибка в делегированном управлении ролями, её оценили в 7.2 по шкале CVSS, идентификатор CVE-2026-103007. Речь о настраиваемом праве, которое по умолчанию не включено. Администратор передаёт его сотруднику с привязкой к конкретным индексам. Проверка прав не учитывает одну настройку определения роли, расширяющую набор совпавших индексов. Если в шаблоне имени стоят маски или регулярные выражения, владелец такого права переписывает собственную роль и получает доступ к закрытым данным, включая служебные. Развитие атаки позволяет дойти до полного административного контроля над кластером.

Рядом по значимости стоит проблема в поиске между кластерами, оценка 7.1. Проверка сверяет запрос с одним признаком целевого сегмента индекса, а обращение идёт по другому признаку. Владелец ключа доступа к одному индексу составляет запрос, где два признака указывают на разные индексы. Авторизация проходит по разрешённому индексу, а работа выполняется с чужим. Раскрываются документы, схемы полей и метаданные, в отдельных случаях удаётся изменить состояние аренды хранения. Уязвимость проявляется только в модели безопасности удалённых кластеров RCS 2.0 (Remote Cluster Security, схема защищённого обмена между кластерами) и недоступна через программный интерфейс REST.

Исправления вошли в версии 8.19.23, 9.4.8 и 9.5.5. Они закрывают большую часть перечисленных проблем. Часть ошибок устранили раньше, в выпусках 8.19.19, 8.19.21, 8.19.22, 9.4.6 и 9.4.7. Для ветки 7.17.x исправлений не выпустили вовсе, как и для линий 9.1.x, 9.2.x и 9.3.x. Пользователям этих версий предлагают перейти на поддерживаемую ветку. Готовых обходных путей почти нет. Исключение - уязвимость в делегированном управлении ролями: там советуют переписать права так, чтобы имена индексов задавались буквально, без масок, и проверить уже созданные роли на доступ к служебным данным. От соединений с удалёнными кластерами можно отказаться, если поиск между кластерами не нужен.

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

Восемь уязвимостей из десяти укладываются в средний уровень, и это снижает вероятность громких атак. Меняется другое: почти все они срабатывают изнутри, от имени легального пользователя. Защита от таких сценариев строится не на периметре, а на разумном распределении прав и своевременных обновлениях. Администраторам нужно проверить, кому выданы права управления ролями и потоками данных, а затем перейти на последние выпуски 8.19.x или 9.5.x.

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

Ссылки