Специалисты компании Miggo обнаружили в брокере сообщений RabbitMQ две уязвимости, связанные с проверкой прав доступа. Обе существуют с начала 2024 года и затрагивают все релизы линейки 3.13.0 и новее — то есть проблема жила в продукте почти два года, прежде чем о ней рассказали публично. По данным исследователей, никаких следов реальной эксплуатации до раскрытия информации найдено не было, что скорее везение, чем заслуга защитных механизмов.
Первая и самая опасная дыра получила идентификатор CVE-2026-57219 с оценкой по CVSS 8.7. Суть проста до неприличия: устаревшая конечная точка HTTP API GET /api/auth отдаёт данные без какой-либо проверки авторизации. В Miggo объяснили это так: «Проверка авторизации на этом эндпоинте была жёстко зашита так, чтобы всегда пропускать запрос — в отличие от любого другого чувствительного управляющего эндпоинта». Иначе говоря, разработчики забыли (или не удосужились) поставить сюда тот же барьер, что стоит на остальных административных путях.
Проблема касается тех инсталляций, где настроен OAuth 2 через параметр конфигурации management.oauth_client_secret. Стоит атакующему отправить один-единственный запрос — и он получает в руки клиентский секрет. Дальше дело техники: секрет обменивается на административный токен, и злоумышленник получает полный контроль над брокером — над каждым сообщением, каждой очередью, каждым пользователем и всеми настройками системы. В Miggo сформулировали это без обиняков: уязвимость «раскрывает конфиденциальный OAuth-секрет брокера неаутентифицированному атакующему за один запрос — это прямой путь к полному захвату брокера в тех конфигурациях, где используется этот секрет».
Наибольший риск возникает там, где управляющий порт доступен из недоверенной сети — в облачных и мультитенантных развёртываниях, либо в тех случаях, когда веб-интерфейс управления по недосмотру администраторов оказался открыт наружу, в интернет. Такие ситуации встречаются чаще, чем принято думать: панель управления часто настраивают «на скорую руку» и забывают закрыть к ней доступ извне.
Вторая уязвимость, CVE-2026-57221, получила оценку CVSS 5.3 — заметно ниже, но тоже неприятная штука. Здесь отсутствует проверка авторизации иного рода: любой аутентифицированный пользователь, имеющий возможность подключиться к виртуальному хосту, способен перечислить все названия очередей и обменников в этом хосте, а заодно прочитать количество сообщений в очередях и число подключённых потребителей. Причём это происходит вне зависимости от того, какие права реально выданы конкретному пользователю — система просто не сверяется с разрешениями. По сути, это утечка метаданных между арендаторами: чужие данные вроде бы напрямую не читаются, но структура и активность соседней инфраструктуры становится видна как на ладони.
Обе дыры закрыты в версиях 4.3.0, 4.2.6, 4.1.11, 4.0.20 и 3.13.15. Тем, кто использует RabbitMQ с OAuth-конфигурацией и не успел обновиться, стоит в первую очередь ротировать секрет клиента OAuth — особенно если управляющий интерфейс хоть теоретически достижим из интернета. Порт 15672, на котором висит панель управления, лучше вообще держать закрытым для внешних сетей: ограничение доступа к нему снимает значительную часть риска даже на непропатченных инсталляциях. Отдельная рекомендация — разделять арендаторов по виртуальным хостам и не полагаться на общую конфигурацию как на достаточную изоляцию. Там, где обновление пока невозможно, помогут firewall-правила, блокирующие обращение к уязвимому эндпоинту.
Раскрытие этих двух проблем совпало по времени с исправлением ещё двух критических уязвимостей в RabbitMQ, о которых сообщили сами разработчики проекта. Одна касается обхода TLS-аутентификации клиента и получила оценку 9.1 по CVSS — практически максимум по шкале серьёзности. Вторая — уязвимость подделки JWKS (JSON Web Key Set) с оценкой 9.2, эксплуатируемая через позицию атакующего посередине (adversary-in-the-middle). Смысл атаки в том, что злоумышленник, перехвативший трафик между брокером и сервером ключей, подделывает ответ JWKS, и брокер начинает принимать произвольные JWT-токены как легитимные — фактически открывая дверь кому угодно.
Совокупность этих четырёх находок рисует не самую приятную картину: механизмы авторизации в RabbitMQ за последние пару лет проверялись не так тщательно, как хотелось бы разработчикам систем на его основе. Для компаний, использующих этот брокер в качестве связующего звена между микросервисами, обновление до последних версий сейчас выглядит не рекомендацией, а насущной необходимостью — особенно если управляющий интерфейс когда-либо был доступен извне периметра.
Изображение носит иллюстративный характер
Первая и самая опасная дыра получила идентификатор CVE-2026-57219 с оценкой по CVSS 8.7. Суть проста до неприличия: устаревшая конечная точка HTTP API GET /api/auth отдаёт данные без какой-либо проверки авторизации. В Miggo объяснили это так: «Проверка авторизации на этом эндпоинте была жёстко зашита так, чтобы всегда пропускать запрос — в отличие от любого другого чувствительного управляющего эндпоинта». Иначе говоря, разработчики забыли (или не удосужились) поставить сюда тот же барьер, что стоит на остальных административных путях.
Проблема касается тех инсталляций, где настроен OAuth 2 через параметр конфигурации management.oauth_client_secret. Стоит атакующему отправить один-единственный запрос — и он получает в руки клиентский секрет. Дальше дело техники: секрет обменивается на административный токен, и злоумышленник получает полный контроль над брокером — над каждым сообщением, каждой очередью, каждым пользователем и всеми настройками системы. В Miggo сформулировали это без обиняков: уязвимость «раскрывает конфиденциальный OAuth-секрет брокера неаутентифицированному атакующему за один запрос — это прямой путь к полному захвату брокера в тех конфигурациях, где используется этот секрет».
Наибольший риск возникает там, где управляющий порт доступен из недоверенной сети — в облачных и мультитенантных развёртываниях, либо в тех случаях, когда веб-интерфейс управления по недосмотру администраторов оказался открыт наружу, в интернет. Такие ситуации встречаются чаще, чем принято думать: панель управления часто настраивают «на скорую руку» и забывают закрыть к ней доступ извне.
Вторая уязвимость, CVE-2026-57221, получила оценку CVSS 5.3 — заметно ниже, но тоже неприятная штука. Здесь отсутствует проверка авторизации иного рода: любой аутентифицированный пользователь, имеющий возможность подключиться к виртуальному хосту, способен перечислить все названия очередей и обменников в этом хосте, а заодно прочитать количество сообщений в очередях и число подключённых потребителей. Причём это происходит вне зависимости от того, какие права реально выданы конкретному пользователю — система просто не сверяется с разрешениями. По сути, это утечка метаданных между арендаторами: чужие данные вроде бы напрямую не читаются, но структура и активность соседней инфраструктуры становится видна как на ладони.
Обе дыры закрыты в версиях 4.3.0, 4.2.6, 4.1.11, 4.0.20 и 3.13.15. Тем, кто использует RabbitMQ с OAuth-конфигурацией и не успел обновиться, стоит в первую очередь ротировать секрет клиента OAuth — особенно если управляющий интерфейс хоть теоретически достижим из интернета. Порт 15672, на котором висит панель управления, лучше вообще держать закрытым для внешних сетей: ограничение доступа к нему снимает значительную часть риска даже на непропатченных инсталляциях. Отдельная рекомендация — разделять арендаторов по виртуальным хостам и не полагаться на общую конфигурацию как на достаточную изоляцию. Там, где обновление пока невозможно, помогут firewall-правила, блокирующие обращение к уязвимому эндпоинту.
Раскрытие этих двух проблем совпало по времени с исправлением ещё двух критических уязвимостей в RabbitMQ, о которых сообщили сами разработчики проекта. Одна касается обхода TLS-аутентификации клиента и получила оценку 9.1 по CVSS — практически максимум по шкале серьёзности. Вторая — уязвимость подделки JWKS (JSON Web Key Set) с оценкой 9.2, эксплуатируемая через позицию атакующего посередине (adversary-in-the-middle). Смысл атаки в том, что злоумышленник, перехвативший трафик между брокером и сервером ключей, подделывает ответ JWKS, и брокер начинает принимать произвольные JWT-токены как легитимные — фактически открывая дверь кому угодно.
Совокупность этих четырёх находок рисует не самую приятную картину: механизмы авторизации в RabbitMQ за последние пару лет проверялись не так тщательно, как хотелось бы разработчикам систем на его основе. Для компаний, использующих этот брокер в качестве связующего звена между микросервисами, обновление до последних версий сейчас выглядит не рекомендацией, а насущной необходимостью — особенно если управляющий интерфейс когда-либо был доступен извне периметра.