Поисковый движок Elasticsearch получил семь исправлений по безопасности. Все уязвимости принадлежат одному классу - неконтролируемый расход ресурсов (CWE-400). Злоумышленник, у которого есть действующая учетная запись, отправляет запрос, заставляющий узел бесконтрольно выделять память и процессорное время. Нескольких таких запросов хватает, чтобы кластер (набор серверов, работающих как единая система) перестал отвечать. Пользователи получают отказ в обслуживании: поиск не работает, новые данные не индексируются, панели мониторинга пустеют.
Детали уязвимостей
Проблемы задевают обе поддерживаемые ветки. В восьмой это выпуски с 8.0.0 по 8.19.21, в девятой - с 9.0.0 по 9.4.6 и с 9.5.0 по 9.5.3. Оценки по CVSS 3.1 у шести уязвимостей совпадают - 6.5 балла, у седьмой 4.9. Средний уровень, и повода для паники нет. Вектор во всех случаях описывает удаленную атаку по сети, низкую сложность и отсутствие взаимодействия с пользователем. Страдает только доступность. Данные не утекают и не подменяются, поэтому к уязвимостям такого рода подходит слово "отказ", а не "утечка".
Условия срабатывания различаются. Для большинства уязвимостей хватает учетной записи с минимальными правами. Одна срабатывает там, где включены аналитические агрегации, то есть сводные выборки по большим массивам документов. Другая требует прав на служебные интерфейсы анализа индекса. Индексом в Elasticsearch называют набор документов, по которому идет поиск. Самую низкую оценку 4.9 получила уязвимость, для которой нужны высокие привилегии. Разница существенна: чем ниже требования к правам, тем шире круг тех, кто способен навредить.
В этот круг попадают подрядчики, аналитики, сервисные учетные записи и сотрудники с частичным доступом. Внешний атакующий тоже в списке, однако сначала ему нужно раздобыть хотя бы один действующий логин. Отдельная неприятность в том, что аутентификация здесь не защита. Уязвимость срабатывает через доверенного пользователя, чьи запросы система считает законными. Ни подозрительный адрес, ни необычный клиент злоумышленника не выдадут. Отличить вредоносный запрос от обычной аналитической задачи трудно, потому что синтаксически они совпадают. Фильтрация трафика по адресам в такой ситуации бесполезна.
Elasticsearch держат в контуре ради поиска по большим объемам данных, аналитики и хранения журналов. Если узел забит под нагрузкой, поток событий прерывается. В компаниях, где на движке построена SIEM-система (класс продуктов для управления событиями информационной безопасности и корреляции данных), пауза в приеме журналов оборачивается слепой зоной для дежурной смены. Аналитики в это время не видят ни атак, ни сбоев инфраструктуры. Между тем именно в первые минуты после вторжения журналы ценятся дороже всего.
Исправления вышли в версиях 8.19.22, 9.4.7 и 9.5.4. Эти выпуски закрывают все семь уязвимостей разом. Важная деталь для тех, кто обновился недавно: одну из уязвимостей, CVE-2026-82294, исправили еще в 8.19.21, 9.4.6 и 9.5.3, а остальные там остаются. Обходных путей Elastic не предлагает и заявляет об их отсутствии прямо. Значит, единственный выход - переход на актуальный выпуск. Перед обновлением полезно свериться со списком известных проблем выбранной версии, о чем просит сам производитель. Облачный сервис Elastic Cloud Serverless под эти уязвимости не попадает: там исправления применяют автоматически, до публичного раскрытия.
Сложность самой атаки невелика. Специальный инструмент не нужен, хватает скрипта и знания, какой именно запрос раздувает потребление. Второй идентификатор, CVE-2026-94398, помогает понять масштаб: одинаковый дефект повторяется в разных участках кода и требует отдельной правки в каждом. Ошибки класса CWE-400 сопровождают распределенные системы постоянно, поскольку ограничивать потребление ресурсов приходится вручную почти в каждом обработчике.
Пока обновление не установлено, снизить ущерб помогают организационные меры. Ревизия ролей и удаление лишних прав у учетных записей, которые обращаются к движку, сужают круг потенциальных виновников. Наблюдение за всплесками нагрузки и временем отклика тоже работает: резкий рост памяти и процессорного времени на одном узле заметен раньше, чем полный отказ. Резервирование узлов и ограничение скорости запросов от сервисных аккаунтов уменьшают шансы, что один поток запросов утащит за собой весь кластер.
Отказ в обслуживании выглядит менее драматично, чем кража данных, и потому его часто откладывают на потом. Между тем прерванный сбор журналов способен скрыть куда более серьезную атаку, которая идет следом. В истории с Elasticsearch важен не размер оценки CVSS, а низкая планка для злоумышленника: действующая учетная запись и один запрос. Обновление до 8.19.22, 9.4.7 или 9.5.4 закрывает вопрос полностью, а ревизия прав не даст повторить сценарий с другой стороны.
Ссылки
- https://discuss.elastic.co/t/elasticsearch-8-19-22-9-4-7-9-5-3-security-update-esa-2026-184/390688
- https://discuss.elastic.co/t/elasticsearch-8-19-22-9-4-7-9-5-4-security-update-esa-2026-183/390687
- https://discuss.elastic.co/t/elasticsearch-9-4-7-9-5-4-security-update-esa-2026-182/390686
- https://discuss.elastic.co/t/elasticsearch-8-19-22-9-4-7-9-5-4-security-update-esa-2026-180/390684
- https://discuss.elastic.co/t/elasticsearch-8-19-22-9-4-7-9-5-4-security-update-esa-2026-179/390683
- https://discuss.elastic.co/t/elasticsearch-8-19-22-9-4-7-9-5-4-security-update-esa-2026-176/390682
- https://discuss.elastic.co/t/elasticsearch-8-19-21-9-4-6-9-5-3-security-update-esa-2026-170/390681
