RabbitMQ sob ameaça: duas falhas de controle de acesso expõem segredos OAuth e permitem tomar o controle do corretor

Pesquisadores de segurança de Miggo descobriram e relataram duas falhas de controle de acesso em RabbitMQ que afetam versões a partir da linha 3.13.0 e que, em conjunto, podem colocar em risco a confidencialidade e o isolamento entre inquilinos de infraestrutura de mensagens empresariais. Um dos erros permite que um atacante não autenticado recupere o segredo OAuth do corretor, o que em ambientes configurados para usar esse segredo pode derivar na obtenção de um token de administrador e, portanto, em controle total sobre filas, mensagens, usuários e a configuração do corretor. O outro defeito permite a qualquer usuário autenticado enumerar filas e exchanges em um virtual host alheio e consultar contadores de mensagens e consumidores sem respeitar as permissões.

A presença de um endpoint HTTP obsoleto e acessível que devolve informações sensíveis destaca uma falha clássica: uma rota administrativa que não aplica a mesma autorização que o resto de pontos críticos. A exposição de um segredo OAuth é especialmente grave porque converte uma fuga de informações em capacidade de ataque pleno através do intercâmbio do segredo por credenciais válidas. Em ambientes multi-tenant, em nuvens públicas ou quando a interface de gestão (por defeito no porto 15672) está acessível de redes não confiáveis, o risco se multiplica.

RabbitMQ publicou correcções nos ramos 4.3.0, 4.2.6, 4.1.11, 4.0.20 e 3.13.15 para resolver estes problemas, e os mantenedores abordaram simultaneamente outras vulnerabilidades críticas relacionadas com a autenticação TLS e a validação de JWKS que poderiam permitir a aceitação de JWTs forjados por um atacante em posição AitM. É imprescindível rever e aplicar as actualizações oficiais; a página de segurança e as notas da versão do projeto são o ponto de partida para verificar versões e adesivos: https://www.rabbitmq.com/security.html e documentação do plugin de gestão que descreve o porto e endpoints envolvidos: https://www.rabbitmq.com/management.html.

Se não for possível corrigir imediatamente, existem medidas de mitigação urgentes que reduzem a janela de exposição. Rotee o segredo OAuth associado ao management.oauth_client_secret Em qualquer instalação cuja interface de gestão seja acessível a partir de redes não confiáveis; um segredo comprometido deve ser invalidado de forma preventiva. Limite o acesso à interface de gestão (porto 15672) através de regras de firewall ou segmentação de rede, e considere bloquear especificamente a rota vulnerável (por exemplo, através de regras WAF que denieguen GET /api/auth) até que o adesivo seja aplicado. Separe os clientes através de hosts virtual e aplique controles de acesso estritos por virtual host para conter a superfície afetada.

Além das mitigações técnicas, é recomendável auditar os logs e buscar sinais de abuso: emissão de tokens administrativos incomuns, conexões desde endereços IP externos ao intervalo habitual e operações administrativas inesperadas em filas e exchanges. Se a actividade suspeita for detectada, procede à revogação de credenciais afectadas, à rotação de segredos e, se necessário, à restauração de apoios realizados antes da intrusão. Para detalhes sobre os itens CVE e gravidade, você pode consultar a base de dados de vulnerabilidade do NIST: CVE-2026-57219 e CVE-2026-57221.

De uma perspectiva de risco operacional, essas falhas lembram que os corretores de mensagens não são apenas componentes de trânsito de dados: contêm meta- dados e credenciais que, se exposto, permitem movimentos laterais e controle persistente dentro da infraestrutura. As equipes de desenvolvimento e operações devem tratar as interfaces de gestão com o mesmo rigor que as APIs expostas ao público: autenticação forte, autorização coerente em todos os endpoints e minimização do blast radius mediante segmentação e princípios de menor privilégio.

Para os administradores que gerem ambientes cloud ou multi-tenant, a combinação de erros (fuga de segredo e leitura de informações entre tenants) é especialmente preocupante porque facilita a escalada desde o acesso legítimo a um tenant até a tomada de controle do corretor inteiro. Revise as políticas de acesso à rede, aplique controlos de autenticação mútua (mTLS) se for caso disso, e monitorize as respostas JWKS e a configuração de certificados após a aplicação de actualizações que permitam às vulnerabilidades TLS/JWKS recentemente relatadas.

Finalmente, mantenha uma cadência de atualização e testes de segurança: incorpore digitalização de endpoints administrativos em avaliações periódicas, execute testes de penetração centrados na gestão do corretor e documente procedimentos de resposta para rotação de segredos e restauração após compromisso. A combinação de adesivos imediatos, atenuações temporárias e alterações organizacionais na forma como as interfaces administrativas são expostas e protegidas reduzirá significativamente a probabilidade de vulnerabilidades como estas deriven em incidentes graves.