RabbitMQ is a messaging broker that uses topics for routing messages between exchanges and queues. In releases prior to 3.13.15, 4.0.21, 4.1.11, and 4.2.6, a flaw in the topic‑authorization logic causes permission checks to be treated as allowed when the Khepri metadata backend interprets an undefined permission result as an explicit allow, thereby letting a user publish or bind to routing keys that should be restricted. This defect is classified as improper authorization checks (CWE‑863) and results in a cross‑tenant isolation bypass that effectively grants an attacker unauthorized access to another tenant’s messaging traffic.

All versions of RabbitMQ Server from the 3.x branch older than 3.13.15 and from the 4.x branch older than 4.0.21, 4.1.11, or 4.2.6 are affected. The attack applies to deployments that use the default Khepri metadata store without an external persistence layer. If a system relies on an embedded or unreliable metadata store, the vulnerability can surface when the store fails to find or load topic permissions. Based on the description, it is inferred that deployments lacking an external persistence layer are especially exposed because metadata‑store failures directly trigger the authorization bypass.

The CVSS score of 7.0 classifies this flaw as high severity. The EPSS score of less than 1% indicates a very low probability of exploitation in the wild, and the vulnerability is not listed in the CISA KEV catalog. Based on the description, it is inferred that an attacker can trigger the authorization bypass by inducing a metadata‑store error—for instance, via a denial‑of‑service attack, misconfiguration, or by corrupting the Khepri data. Once the store error occurs, the attacker can publish to or bind with routing keys belonging to other tenants, leading to data disclosure or service disruption. Despite the low exploitation likelihood, the potential impact on confidentiality, integrity, and availability warrants prompt mitigation.