RabbitMQ under threat: two access control failures expose OAuth secrets and allow you to take control of the broker

Miggo security researchers have discovered and reported two access control failures in RabbitMQ that affect versions from line 3.13.0 and that, together, can put at risk the confidentiality and isolation of business messaging infrastructure tenants. One of the failures allows an unauthenticated attacker to recover the OAuth secret from the broker, which in settings configured to use that secret can result in obtaining an administrator's token and, therefore, in total control over tails, messages, users and the broker's configuration. The other defect allows any authenticated user to list queues and exchanges in a virtual foreign host and to consult message counters and consumers without respecting the permissions.

The presence of an obsolete and accessible HTTP endpoint that returns sensitive information highlights a classic failure: an administrative route that does not apply the same authorisation as other critical points. The exposure of a secret OAuth is especially serious because it turns an information leak into a full attack capacity by exchanging the secret for valid credentials. In multi-tenant environments, in public clouds or when the management interface (by default in port 15672) is accessible from unreliable networks, the risk is multiplied.

RabbitMQ has published corrections in branches 4.3.0, 4.2.6, 4.1.11, 4.0.20 and 3.1.15 to solve these problems, and the maintainers have simultaneously addressed other critical vulnerabilities related to TLS authentication and JWKS validation that could allow JWTs to be accepted by an AitM attacker. It is essential to review and implement official updates; the security page and the project version notes are the starting point for checking versions and patches: https: / / www.rabbitmq.com / security.html and the management plugin documentation describing the port and endpoints involved: https: / / www.rabbitmq.com / management.html.

If it is not possible to park immediately, there are urgent mitigation measures that reduce the exposure window. Rotate the OAuth secret associated with the management.oauth _ client _ secret in any installation whose management interface is accessible from unreliable networks; a committed secret must be invalidated in a preventive manner. Limit access to the management interface (port 15672) by firewall rules or network segmentation, and consider specifically blocking the vulnerable route (e.g. WAF rules that deny GET / api / auth) until the patch is applied. Separate customers by virtual hosts and apply strict access controls by virtual host to contain the affected surface.

In addition to technical mitigation, it is recommended to audit the logs and look for signs of abuse: issuance of unusual administrative tokens, connections from external IP addresses to the usual range and unexpected administrative operations in queues and exchanges. If suspicious activity is detected, proceed to the revocation of affected credentials, the rotation of secrets and, if necessary, the restoration from backups performed prior to intrusion. For details on CVE inputs and severity, see the NIST vulnerability database: CVE-2026-57219 and CVE-2026-57221.

From an operational risk perspective, these failures remember that messaging brokers are not just data transit components: contain metadata and credentials that, if exposed, allow side movements and persistent control within the infrastructure. Development and operation teams should treat the management interfaces with the same rigour as the public-exposed APIs: strong authentication, consistent authorization in all endpoints and minimization of the blast radius through segmentation and less privileged principles.

For managers who manage cloud or multi-tenant environments, the combination of errors - the leakage of secret and information reading between tenants - is particularly worrying because it facilitates the escalation from legitimate access to a tenant to the taking of control of the entire broker. Review network access policies, apply mutual authentication controls (mTLS) where appropriate, and monitor JWKS responses and certificate settings after applying updates to fix newly reported TLS / JWKS vulnerabilities.

Finally, maintain an update cadence and safety tests: incorporate administrative endpoints scans in regular evaluations, perform penetration tests focused on the management of the broker and document response procedures for the rotation of secrets and restoration after commitment. The combination of immediate patch, temporary mitigation and organizational changes in how administrative interfaces are exposed and protected will significantly reduce the likelihood of vulnerabilities such as these resulting in serious incidents.