CVE-2026-66075 in RabbitMQ
Summary
by MITRE • 09/24/2026
RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1, is_authorized/2 for the /federation-links/.../restart route uses is_authorized_monitor (accepts the monitoring tag), while allowed_methods permits DELETE and delete_resource/2 triggers rabbit_federation_link_sup:restart. There is no per-method elevation check and no comment marking it intentional. A read-only monitoring user can restart any federation link , a state-changing operation that disrupts message flow. Preconditions include rabbitmq_federation + rabbitmq_federation_management plugins enabled Attacker has credentials with the monitoring tag. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified involves a critical authorization bypass within the RabbitMQ messaging broker, specifically affecting versions prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1. This flaw resides in the handling of federation link restart operations via the REST API endpoint /federation-links/.../restart. The core technical issue stems from a mismatch between the authorization check performed by the is_authorized_monitor function and the actual permissions required for the operation. While the allowed_methods configuration explicitly permits DELETE actions, which trigger the rabbit_federation_link_sup:restart process, the system incorrectly relies on is_authorized_monitor to validate access. This monitoring-oriented authentication mechanism typically grants access based solely on the presence of a monitoring tag in user credentials, rather than verifying specific administrative or management privileges required for state-changing operations.
This architectural oversight results in a significant privilege escalation scenario where users possessing only read-only monitoring tags can execute destructive actions. Specifically, an attacker with valid credentials tagged as monitor is able to invoke the restart function on any federation link within the RabbitMQ cluster. This capability bypasses intended access controls because there is no per-method elevation check implemented for this specific route, nor was there a code comment indicating that such broad permissions were intentional. The absence of these safeguards allows low-privilege accounts to perform administrative tasks that should be restricted to higher-level administrators or dedicated management users with appropriate delete_resource privileges.
The operational impact of this vulnerability is severe due to the nature of federation links in RabbitMQ deployments. Federation links are responsible for propagating messages between different RabbitMQ clusters, ensuring high availability and data distribution across distributed systems. By restarting these links, an authenticated monitoring user can effectively disrupt message flow, causing temporary or prolonged service outages depending on the configuration and recovery mechanisms in place. This denial of service capability undermines the reliability guarantees provided by the messaging broker and can lead to significant business disruption, particularly in environments where real-time data synchronization is critical for application functionality.
From a classification perspective, this vulnerability aligns with CWE-269 Improper Privilege Management, as it allows an actor to perform actions beyond their intended permissions level. It also maps to MITRE ATT&CK technique T1078 Valid Accounts, where the attacker leverages legitimate credentials that have been misconfigured or overly permissive within the application's authorization logic. The flaw represents a failure in enforcing least privilege principles by allowing monitoring-level access to trigger administrative state changes without additional verification steps.
To mitigate this risk, organizations must upgrade RabbitMQ to version 3.13.15, 4.0.20, 4.1.11, 4.2.6, or later, where the authorization logic has been corrected to properly distinguish between monitoring and administrative operations. In addition to upgrading, administrators should review user configurations to ensure that users with monitoring tags do not possess unnecessary delete_resource permissions unless explicitly required for their role. Implementing strict separation of duties by assigning distinct roles for monitoring versus administration can further reduce the attack surface. Regular auditing of API endpoint access controls and ensuring that state-changing operations require elevated privileges are essential practices for maintaining robust security posture in RabbitMQ deployments.