Раскрыты две уязвимости в RabbitMQ: получение полного доступ к брокеру через OAuth-секрет

RabbitMQ

Исследователи из компании Miggo Security с помощью автоматизированной системы VulnHunter обнаружили две уязвимости контроля доступа в открытом брокере сообщений RabbitMQ, который используется примерно в 8% всех контейнеров, запущенных сегодня. Обе проблемы присутствуют в кодовой базе начиная с версии 3.13.0, выпущенной в начале 2024 года, и устраняются в новых патчах. Наибольшую опасность представляет уязвимость CVE-2026-57219 (CVSS v4.0 8.7), которая позволяет неаутентифицированному злоумышленнику получить OAuth-секрет клиента - confidential secret, используемый при настройке провайдеров идентификации вроде Auth0, Entra ID, Keycloak или UAA. При наличии секрета атакующий может обменять его на токен администратора и полностью захватить контроль над очередями, сообщениями, пользователями и конфигурацией брокера.

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

Корень проблемы - в устаревшем конечном пути GET /api/auth, который возвращал OAuth-конфигурацию любому обратившемуся без аутентификации. В файле rabbit_mgmt_wm_auth.erl колбэк is_authorized/2 был жёстко закодирован на возврат true, что полностью отключало проверку прав доступа. Для эксплуатации злоумышленнику достаточно иметь сетевой доступ к порту 15672, чтобы запросить секрет, а затем с его помощью получить от провайдера идентификации административный токен. Таким образом, атакующий получает все возможности по управлению брокером.

Вторая уязвимость, CVE-2026-57221, имеет более низкую оценку серьёзности - 5.3 по шкале CVSS v4.0, но также представляет существенную угрозу для мультитенантных сред. Она позволяет любому аутентифицированному пользователю, даже с нулевыми правами, перечислять очереди и обменники (exchanges) в рамках виртуального хоста, а также считывать статистику по количеству сообщений и потребителей. Ошибка локализована в файле rabbit_channel.erl: операция "passive declare" - проверка существования очереди или обменника без их создания - не содержала проверки разрешений, в отличие от аналогичных операций, таких как queue.delete или basic.publish. В результате пользователь с минимальными правами может получить информацию о схеме именования, объёме сообщений и деловой активности других арендаторов, которые используют общий виртуальный хост.

В отчёте Miggo подчёркивается, что обе уязвимости относятся к классу "inconsistency bugs" - несоответствий в реализации механизмов авторизации, когда часть операций проверяет права, а часть - нет. Подобные проблемы особенно опасны в крупных мультитенантных развёртываниях, где одно приложение RabbitMQ обслуживает множество изолированных клиентов. Разведка метаданных очередей может быть использована для планирования целевых атак.

Обе уязвимости устранены в версиях RabbitMQ 4.3.0, 4.2.6, 4.1.11, 4.0.20 и 3.13.15. Разработчики рекомендуют немедленно обновить брокер до одной из этих версий. Для CVE-2026-57219 патч удаляет уязвимый конечный путь, однако уже скомпрометированный OAuth-секрет не становится недействительным автоматически - требуется его ротация. В качестве временной меры Miggo опубликовала WAF-правило, блокирующее доступ к эндпоинту GET /api/auth. Для второй уязвимости такой обходной защиты не существует - единственный постоянный способ устранения - установка обновлённой версии.

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

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

Ссылки

Комментарии: 0