CVE-2026-67412 in RabbitMQ
Summary
by MITRE • 09/25/2026
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 4.3.3, 4.2.9 , 4.1.14, 4.0.24, and 3.13.18, Federation upstream in RabbitMQ skips vhost authorization allowing cross-vhost message access. what the bug lets you do. A policymaker on one vhost reads and drains messages out of another vhost it has no permission on. With the default ack-mode the source messages are consumed (deleted), not copied. Why that should not 1. Federation validates the upstream URI without any vhost-access Cross-vhost message read/drain from a per-vhost policymaker, breaking vhost tenancy This issue is fixed in versions 4.3.3, 4.2.9 , 4.1.14, 4.0.24, and 3.13.18.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 09/25/2026
RabbitMQ serves as a robust messaging broker facilitating communication between distributed systems through message queuing and streaming capabilities. In versions ranging from 3.13.0 up to specific patched releases including 4.3.3, 4.2.9, 4.1.14, 4.0.24, and 3.13.18, a critical security flaw exists within the Federation plugin architecture. This vulnerability stems from an insufficient validation of access control policies when establishing connections to upstream RabbitMQ nodes via federation links. The core technical deficiency lies in the fact that while the system validates the Uniform Resource Identifier for connectivity purposes, it fails to enforce virtual host level authorization checks during this process. Consequently, the security boundary defined by vhost tenancy is effectively bypassed at the protocol negotiation stage rather than being enforced during message routing or consumption operations.
The operational impact of this flaw allows a policymaker configured on one specific virtual host to read and drain messages from another distinct virtual host for which it possesses no explicit permissions. In standard RabbitMQ deployments, vhosts are designed to provide logical isolation between different tenants or applications sharing the same broker instance. This isolation ensures that data processed in one tenant's environment remains inaccessible to others unless explicitly shared through secure channels. However, due to this authorization bypass, an attacker with access to a federated policy on any single vhost can exploit the federation mechanism to extract sensitive information from unrelated vhosts. The severity of this issue is compounded by the default acknowledgment mode used in many configurations. When messages are consumed rather than copied, they are permanently deleted from the source queue after being read by the unauthorized party. This results not only in a confidentiality breach but also potentially causes data loss for legitimate users who expected those messages to be processed within their own isolated environment.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control and CWE-732 Incorrect Permission Assignment for Critical Resource. The failure to verify user privileges against the specific resource context before allowing access represents a fundamental breakdown in authorization logic. Furthermore, from an adversary behavior standpoint as defined by MITRE ATT&CK, this flaw facilitates Initial Access through legitimate administrative tools or configurations that are then abused for lateral movement and Data Exfiltration. An attacker would likely leverage existing federation setups to pivot across isolated network segments or tenant boundaries without triggering standard access control alerts, thereby maintaining persistence while stealing data undetected.
To mitigate the risks associated with this vulnerability, organizations must immediately upgrade RabbitMQ instances to one of the fixed versions listed above, specifically 4.3.3, 4.2.9, 4.1.14, 4.0.24, or 3.13.18. Until patching is complete, administrators should review federation configurations and restrict upstream URIs to only those vhosts where explicit cross-vhost permissions have been intentionally granted through proper policy definitions rather than relying on the flawed automatic validation logic. Additionally, auditing existing federation links for unexpected connections between unrelated tenants can help identify potential exploitation attempts that may have occurred prior to remediation. Implementing strict network segmentation and monitoring for anomalous message consumption patterns across vhosts provides an additional layer of defense against this type of authorization bypass attack vector.