Специалисты компании Elastic сообщили об обнаружении уязвимости в компоненте Elastic Package Registry (реестр пакетов). Эта проблема получила идентификатор CVE-2026-33467 и оценку 5,9 балла по шкале CVSS v3.1 (средний уровень опасности). Уязвимость затрагивает только самостоятельные развертывания (self-hosted), которые синхронизируют пакеты с вышестоящим источником, и не влияет на публичный реестр Elastic.
Уязвимость CVE-2026-23267
Elastic Package Registry - это хранилище пакетов расширений для стека Elastic (например, для интеграций с различными системами). При самостоятельном развёртывании организации часто забирают пакеты из официального источника через специальный инструмент распространения или прокси-режим. Уязвимость заключается в неверной проверке криптографической подписи пакетов (это ошибка типа CWE-347). Из-за неё атакующий, способный перехватывать или модифицировать сетевой трафик между самостоятельным реестром Elastic Package Registry и его вышестоящим источником, может подменить легитимный пакет на модифицированный. При этом система не заблокирует загрузку такого подменённого пакета, полагая, что подпись верна.
Иными словами, нарушается целостность данных в репозитории. Злоумышленник может внедрить в пакет вредоносный код, который затем будет установлен на серверы Elastic (например, как часть интеграции). Это открывает путь к компрометации системы на этапе доставки обновлений.
Наиболее уязвимы организации, которые используют собственную инфраструктуру для хостинга Elastic Package Registry. Это типично для компаний с повышенными требованиями к изоляции или для тех, кто не может напрямую обращаться к публичному реестру Elastic по соображениям безопасности или политики. Такие самостоятельные реестры обычно синхронизируют пакеты с официальным источником - либо через специальную утилиту (distribution tool), либо в прокси-режиме. Именно в этом канале и возможна атака.
Публичный реестр Elastic по адресу https://epr.elastic.co и все развёртывания, которые получают пакеты напрямую оттуда, не подвержены данной проблеме. Компания Elastic контролирует свою инфраструктуру, и перехват трафика внутри её сети маловероятен.
Для успешной эксплуатации атакующий должен иметь возможность вмешиваться в сетевой трафик между самостоятельным реестром и вышестоящим источником. Это может быть man-in-the-middle-атака в локальной сети, компрометация DNS или маршрутизации, либо контроль над прокси-сервером. В таких условиях злоумышленник может заменить настоящий пакет на свой - с изменённым содержимым, но с сохранением формата, который реестр сочтёт подписанным. Поскольку механизм проверки подписи работает некорректно, система не выдаст ошибку целостности. В результате вредоносный пакет будет импортирован и установлен на серверы Elastic.
Далее возможны различные сценарии: от внедрения бэкдора до сбора конфиденциальной информации из обрабатываемых данных. Учитывая, что Elasticsearch и Kibana часто используются для хранения и анализа критических логов, компрометация интеграционного пакета может иметь серьёзные последствия.
Разработчики уже выпустили исправление в версии Elastic Package Registry 1.38.0. Всем пользователям, эксплуатирующим самостоятельные реестры, рекомендуется немедленно обновить компонент до этой версии. Обновление закрывает дыру в проверке подписи и гарантирует, что подменённые пакеты будут отклоняться.
Помимо обновления, стоит усилить контроль над сетевыми каналами синхронизации. Использование шифрования TLS с взаимной аутентификацией, сегментация сети и мониторинг трафика помогут снизить риск перехвата. Также полезно внедрить автоматическую проверку контрольных сумм пакетов на стороне загрузчика.
Уязвимость CVE-2026-33467 - наглядный пример того, как ошибка в реализации криптографической проверки может свести на нет все усилия по защите цепочки поставок программного обеспечения. Даже если алгоритмы и ключи подписи надёжны, неправильная их верификация создаёт брешь. Для администраторов Elastic важно не только следить за обновлениями самого стека, но и контролировать все вспомогательные компоненты, такие как реестры пакетов.
Хотя оценка критичности средняя, в контексте конкретной инфраструктуры последствия могут быть высокими. Поэтому игнорировать эту проблему не стоит. Elastic уже предоставила патч, и его установка - простой и эффективный способ закрыть уязвимость. Компаниям же, использующим самостоятельные реестры, стоит пересмотреть архитектуру доставки пакетов и, по возможности, минимизировать число промежуточных звеньев между официальным источником и конечной системой.
Ссылки
- https://nvd.nist.gov/vuln/detail/CVE-2026-23267
- https://discuss.elastic.co/t/elastic-package-registry-1-38-0-security-update-esa-2026-27/386081
