RabbitMQ bajo amenaza: dos fallos de control de acceso exponen secretos OAuth y permiten tomar el control del broker

Investigadores de seguridad de Miggo han descubierto y reportado dos fallos de control de acceso en RabbitMQ que afectan a versiones a partir de la línea 3.13.0 y que, en conjunto, pueden poner en riesgo la confidencialidad y el aislamiento entre inquilinos de infraestructuras de mensajería empresariales. Uno de los fallos permite que un atacante no autenticado recupere el secreto OAuth del broker, lo que en entornos configurados para usar ese secreto puede derivar en la obtención de un token de administrador y, por tanto, en control total sobre colas, mensajes, usuarios y la configuración del broker. El otro defecto permite a cualquier usuario autenticado enumerar colas y exchanges en un virtual host ajeno y consultar contadores de mensajes y consumidores sin respetar los permisos.

La presencia de un endpoint HTTP obsoleto y accesible que devuelve información sensible subraya una falla clásica: una ruta administrativa que no aplica la misma autorización que el resto de puntos críticos. La exposición de un secreto OAuth es especialmente grave porque convierte una fuga de información en capacidad de ataque pleno mediante el intercambio del secreto por credenciales válidas. En entornos multi-tenant, en nubes públicas o cuando la interfaz de gestión (por defecto en el puerto 15672) está accesible desde redes no confiables, el riesgo se multiplica.

RabbitMQ ha publicado correcciones en las ramas 4.3.0, 4.2.6, 4.1.11, 4.0.20 y 3.13.15 para resolver estos problemas, y los mantenedores han abordado simultáneamente otras vulnerabilidades críticas relacionadas con la autenticación TLS y la validación de JWKS que podrían permitir la aceptación de JWTs forjados por un atacante en posición AitM. Es imprescindible revisar y aplicar las actualizaciones oficiales; la página de seguridad y las notas de la versión del proyecto son el punto de partida para verificar versiones y parches: https://www.rabbitmq.com/security.html y la documentación del plugin de gestión que describe el puerto y endpoints implicados: https://www.rabbitmq.com/management.html.

Si no es posible parchear de inmediato, existen medidas de mitigación urgentes que reducen la ventana de exposición. Rotee el secreto OAuth asociado al management.oauth_client_secret en cualquier instalación cuya interfaz de gestión sea accesible desde redes no confiables; un secreto comprometido debe invalidarse de forma preventiva. Limite el acceso a la interfaz de gestión (puerto 15672) mediante reglas de firewall o segmentación de red, y considere bloquear específicamente la ruta vulnerable (por ejemplo mediante reglas WAF que denieguen GET /api/auth) hasta que se aplique el parche. Separe a los clientes mediante virtual hosts y aplique controles de acceso estrictos por virtual host para contener la superficie afectada.

Además de las mitigaciones técnicas, es recomendable auditar los logs y buscar señales de abuso: emisión de tokens administrativos inusuales, conexiones desde direcciones IP externas al rango habitual y operaciones administrativas inesperadas en colas y exchanges. Si se detecta actividad sospechosa, proceda a la revocación de credenciales afectadas, la rotación de secretos y, de ser necesario, a la restauración desde respaldos realizados antes de la intrusión. Para detalles sobre las entradas CVE y la severidad, puede consultarse la base de datos de vulnerabilidades del NIST: CVE-2026-57219 y CVE-2026-57221.

Desde una perspectiva de riesgo operativo, estas fallas recuerdan que los brokers de mensajería no son solo componentes de tránsito de datos: contienen metadatos y credenciales que, si se exponen, permiten movimientos laterales y control persistente dentro de la infraestructura. Los equipos de desarrollo y operaciones deben tratar las interfaces de gestión con el mismo rigor que las API expuestas al público: autenticación fuerte, autorización coherente en todos los endpoints y minimización del blast radius mediante segmentación y principios de menor privilegio.

Para los administradores que gestionan entornos cloud o multi-tenant, la combinación de errores —fuga de secreto y lectura de información entre tenants— es especialmente preocupante porque facilita la escalada desde acceso legítimo a un tenant hasta la toma de control del broker entero. Revise las políticas de acceso a la red, aplique controles de autenticación mutua (mTLS) cuando proceda, y monitorice las respuestas JWKS y la configuración de certificados tras aplicar actualizaciones que arreglen las vulnerabilidades TLS/JWKS recientemente reportadas.

Finalmente, mantenga una cadencia de actualización y pruebas de seguridad: incorpore escaneos de endpoints administrativos en evaluaciones periódicas, ejecute pruebas de penetración centradas en la gestión del broker y documente procedimientos de respuesta para rotación de secretos y restauración tras compromiso. La combinación de parche inmediato, mitigaciones temporales y cambios organizativos en cómo se exponen y protegen las interfaces administrativas reducirá de forma significativa la probabilidad de que vulnerabilidades como estas deriven en incidentes graves.