Отсутствие аутентификации в Apache ActiveMQ Artemis позволяет удалённо захватить сервер сообщений

В асинхронных системах обмена сообщениями Apache ActiveMQ Artemis и Apache Artemis обнаружена уязвимость, которая даёт удалённому злоумышленнику полный контроль над приложением. Одна из критичных функций брокера выполняется без проверки учётных данных. Поэтому атакующему не нужны ни логин, ни пароль, ни действующая учётная запись. Оценка по CVSS 3.1 составляет 9,8 из 10, по CVSS 2.0 - 10. Оба значения относят проблему к критическому уровню опасности. Сведения внесены в Банк данных угроз безопасности информации (BDU) под номером BDU:2026-16034, уязвимости присвоен идентификатор CVE-2026-57967.

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

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

Формально ошибка описана как отсутствие аутентификации для критичной функции, тип CWE-306. Это уязвимость архитектурного класса. Она заложена не в отдельной строке кода, а в самой логике разграничения доступа. Вектор атаки выглядит так: сетевой доступ, низкая сложность, отсутствие требуемых привилегий, отсутствие взаимодействия с пользователем. Иначе говоря, достаточно дотянуться до сетевого порта брокера, чтобы воспользоваться функцией, которая по замыслу должна быть защищена. Пострадать могут все три свойства системы одновременно: конфиденциальность, целостность и доступность. Это следует из старших значений вектора CVSS, где все три показателя помечены как высокие. Что практически означает полный контроль над брокером. Злоумышленник читает сообщения, то есть получает доступ к содержимому переписки между сервисами. Он подменяет сообщения, и тогда подчинённые системы выполняют чужие указания. Он останавливает обработку очередей, что приводит к отказу в обслуживании уже на стороне бизнес-приложений. Наконец, он может внедрить собственные задачи в очередь и тем самым расширить зону присутствия. Каждое из этих действий по отдельности уже значимо. Вместе они складываются в полную потерю доверия к каналу обмена данными.

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

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

Затронуты две линейки продуктов. Ветка Artemis уязвима в диапазоне версий от 1.0.0 до 2.44.0 включительно. Ветка ActiveMQ Artemis уязвима в диапазоне от 2.50.0 до 2.56.0 включительно. Производитель подтвердил проблему и опубликовал исправление в репозитории проекта. Рекомендации Apache Software Foundation размещены в списке рассылки проекта и в описании правки.

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

Похожие случаи повторяются с заметной регулярностью. Промежуточное ПО обменивается данными внутри доверенного контура, и разработчики иногда полагаются на это обстоятельство вместо явной проверки подлинности. Пока такая логика сохраняется, брокеры сообщений остаются привлекательной целью. Публикация готового эксплойта и почти максимальная оценка по CVSS превращают эту уязвимость в задачу с высоким приоритетом. Организациям, которые держат Artemis или ActiveMQ Artemis в промышленном контуре, стоит рассматривать обновление как срочную работу, а не как плановое мероприятие.

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

Ссылки