Vulnerabilidades críticas em versões recentes do RabbitMQ (CVE-2026-57219 e CVE-2026-57221) permitem que atores não autenticados obtenham segredos de configuração para assumir o controle total do broker e que usuários autenticados leiam metadados de filas pertencentes a outros inquilinos.
| Componente | RabbitMQ (Plugin de Gerenciamento HTTP e Configuração OAuth 2) |
| Vetor | Requisição HTTP não autenticada para endpoint obsoleto (GET /api/auth) e consulta insuficiente de autorização em usuários autenticados conectados a hosts virtuais. |
| Impacto | Exposição do segredo do cliente OAuth (management.oauth_client_secret), possibilitando a geração de tokens de administrador e tomada de controle total do broker; além de vazamento de metadados de filas de outros locatários em ambientes multi-inquilino. |
| Prioridade | Aplicação imediata das correções (versões 4.3.0, 4.2.6, 4.1.11, 4.0.20 e 3.13.15) e rotação obrigatória de segredos OAuth expostos. |
Duas falhas significativas de controle de acesso foram identificadas no RabbitMQ, um message broker amplamente utilizado em infraestruturas corporativas de mensageria. As vulnerabilidades, rastreadas como CVE-2026-57219 e CVE-2026-57221, comprometem a isolamento entre locatários e a integridade da autenticação em instalações que utilizam OAuth 2.0. A falha mais crítica, avaliada com pontuação CVSS de 8.7, reside em um endpoint de API HTTP obsoleto que inadvertidamente vaza credenciais confidenciais de configuração para atacantes não autenticados. A segunda vulnerabilidade, com pontuação 5.3, permite que qualquer usuário autenticado contorne as verificações de permissão para acessar informações sensíveis sobre filas e trocas de outros inquilinos no mesmo host virtual.
As deficiências de segurança estão presentes na base de código desde o início de 2024, impactando todas as linhas de lançamento do RabbitMQ a partir da versão 3.13.0. A natureza dessas falhas representa um risco elevado para ambientes de nuvem e configurações multi-inquilino, onde a segregação de dados e o isolamento de administradores são requisitos fundamentais. Provedores de serviços e equipes de DevOps que gerenciam clusters RabbitMQ expostos à internet ou compartilhados entre diferentes departamentos devem priorizar a correção, pois a exploração bem-sucedida pode resultar na comprometimento completo da infraestrutura de mensagens e na movimentação lateral dentro da rede corporativa.
A CVE-2026-57219 explora um comportamento inseguro no endpoint GET /api/auth, uma rota legada que deveria estar desativada ou restrita. A análise técnica revela que a verificação de autorização para este endpoint específico estava codificada (hard-coded) para permitir sempre a solicitação, diferindo de todos os outros endpoints sensíveis de gerenciamento que exigem autenticação rigorosa. Em instalações onde o RabbitMQ está configurado para usar OAuth 2.0 com a chave management.oauth_client_secret, uma única requisição HTTP não autenticada a esse endpoint faz com que o servidor retorne o segredo do cliente OAuth em texto plano. Com esse segredo em mãos, um atacante pode interagir diretamente com o provedor de identidade para trocar a credencial por um token de acesso de administrador, obtendo assim controle total sobre cada mensagem, fila, usuário e configuração do broker.
Já a CVE-2026-57221 aborda uma quebra de isolamento em nível de aplicação. Em um fluxo normal, um usuário conectado a um host virtual deveria ter permissão restrita apenas aos recursos que lhe foram atribuídos. No entanto, a falha permite que qualquer usuário capaz de estabelecer uma conexão autenticada com o host virtual execute chamadas de API para enumerar todos os nomes de filas e trocas, além de ler contagens de mensagens e consumidores. A ausência de uma verificação de permissão adequada nessas rotas de listagem expõe a topologia da infraestrutura de mensagens de outros locatários. Embora o conteúdo das mensagens não seja necessariamente acessível sem permissões adicionais, a exposição desses metadados permite que o atacante mapeie o sistema, identifique alvos de alto valor e-planeie movimentos subsequentes, violando a expectativa de segregação de ambientes compartilhados.
As vulnerabilidades afetam especificamente as versões do RabbitMQ 3.13.0 e posteriores, abrangendo releases modernos que implementam o plugin de gerenciamento e suporte a OAuth 2.0. O impacto é severo em ambiente onde a porta de gerenciamento (padrão 15672) é acessível a partir de redes não confiáveis, como a internet pública ou redes de nuvem com múltiplos locatários. Configurações que utilizam o mecanismo de autenticação via OAuth 2.0, especificamente aquelas que definem o management.oauth_client_secret para integração com provedores de identidade externos, são as mais suscetíveis à CVE-2026-57219, pois é a presença desse segredo que viabiliza a escalada de privilégios.
No que diz respeito à CVE-2026-57221, qualquer instalação que suporte múltiplos usuários ou projetos no mesmo cluster RabbitMQ (hosts virtuais distintos) está em risco. Isso inclui plataformas de integração contínua (CI/CD), sistemas de processamento de eventos e arquiteturas de microsserviços onde a separação lógica de dados depende estritamente dos controles de acesso do message broker.
- Versões do RabbitMQ 3.13.0 até 4.3.0 (antes da correção).
- Instâncias com a porta de gerenciamento 15672 exposta à internet ou a redes internas amplas.
- Ambientes multi-inquilino que compartilham o mesmo broker RabbitMQ.
- Configurações que utilizam
management.oauth_client_secretpara autenticação do plugin de gerenciamento.
A detecção de tentativas de exploração da CVE-2026-57219 deve focar no monitoramento de acessos anômalos ao endpoint obsoleto. Administradores devem auditar os logs de acesso do servidor web embutido no RabbitMQ (normalmente localizados em logs de gerenciamento ou HTTP access logs) em busca de requisições GET /api/auth. Em um cenário operacional saudável, esse endpoint não deve ser acionado. A presença de requisições bem-sucedidas (código HTTP 200) para esse caminho, especialmente originadas de IPs externos ou não reconhecidos, é um indicador forte de atividade de reconhecimento ou exploração. Além disso, a verificação de logs OAuth pode revelar a emissão de tokens de administrador para clientes desconhecidos ou em momentos atípicos.
Para a CVE-2026-57221, a investigação deve centrar-se nos padrões de acesso a recursos de listagem. Recomenda-se correlacionar os logs de autenticação do RabbitMQ com as solicitações de API que retornam listas completas de filas e trocas. Se um usuário com permissões restritas for registrado realizando essas operações em escopos que não lhe pertencem, isso confirma a falha de isolamento. Monitoradores de segurança devem configurar alertas para operações de enumeração em massa (mass enumeration) que não correspondam ao perfil de acesso habitual de serviços ou usuários legítimos.
- Vigiar logs de acesso HTTP por requisições para
GET /api/auth. - Auditar logs do provedor de identidade (IdP) buscando trocas de tokens usando o segredo do cliente.
- Monitorar usuários de baixo privilégio executando chamadas de API que listam todas as filas e exchanges do host virtual.
- Verificar exposição da porta 15672 em varreduras de rede internas e externas.
A resposta primária para essas vulnerabilidades é a atualização imediata do software para as versões corrigidas lançadas pelos mantenedores: 4.3.0, 4.2.6, 4.1.11, 4.0.20 ou 3.13.15. Essas versões removem o endpoint vulnerável e corrigem a verificação de autorização para as consultas de listagem. É crucial ressaltar que apenas aplicar o patch não é suficiente para ambientes que podem ter sido comprometidos anteriormente. Em decorrência da possibilidade de vazamento de credenciais, é mandatório rotacionar o management.oauth_client_secret imediatamente após a atualização, especialmente se a interface de gerenciamento era acessível via internet. A rotação invalida qualquer segredo que possa ter sido extraído por atacantes antes da correção ser aplicada.
Como medida de defesa em profundidade, a equipe de segurança deve garantir que a porta de gerenciamento (15672) nunca seja exposta a redes não confiáveis. O acesso deve ser estritamente limitado a IPs de gerenciamento ou redes privadas via regras de firewall ou grupos de segurança na nuvem. A segregação de locatários deve ser reforçada através do uso de hosts virtuais distintos e, preferencialmente, clusters separados para isolamento crítico. Até que a correção possa ser aplicada, a implementação de regras de firewall para bloquear o tráfego direcionado ao endpoint vulnerável /api/auth em instâncias não corrigidas pode servir como uma medida de contenção temporária, embora a atualização do software permaneça sendo a única solução definitiva.
- Atualizar para RabbitMQ versões 4.3.0, 4.2.6, 4.1.11, 4.0.20 ou 3.13.15.
- Rotacionar imediatamente o segredo do cliente OAuth (
management.oauth_client_secret) após o patch. - Restringir o acesso à porta 15672 (interface de gerenciamento) a IPs confiáveis.
- Implementar regras de firewall para bloquear acesso externo aos endpoints de gerenciamento.
0 Comentários