CVE-2026-66067 in RabbitMQ
Summary
by MITRE • 09/24/2026
RabbitMQ is a messaging and streaming broker. Prior to versions 4.2.7 and 4.3.1, The stream open handler calls only check_vhost_access; it omits the node/vhost/user connection-limit checks that rabbit_reader performs for AMQP. A developer %% FIXME comment at the cited line explicitly acknowledges the gap. No compensating enforcement exists in connection tracking or elsewhere in rabbitmq_stream. An authenticated tenant can fully bypass operator-configured per-user and per-vhost connection caps by connecting via port 5552 instead of 5672. Preconditions include rabbitmq_stream plugin enabled Authenticated stream-protocol credentials Operator relies on per-user/per-vhost connection limits for tenant isolation. This issue is fixed in versions 4.2.7 and 4.3.1.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
RabbitMQ serves as a robust messaging and streaming broker, facilitating communication between distributed systems through various protocols including AMQP and its proprietary stream protocol. The security architecture of RabbitMQ relies heavily on strict access control mechanisms to ensure tenant isolation and resource management within multi-tenant environments. A critical architectural flaw was identified in the implementation of the stream open handler prior to versions 4.2.7 and 4.3.1, where the validation logic for incoming connections diverged significantly from the standard AMQP connection handling procedures. This discrepancy created a security gap that allowed authenticated users to bypass operator-configured constraints on resource usage.
The technical root cause of this vulnerability lies in the specific function calls executed during the stream protocol handshake. When a client initiates a connection via the stream port, typically 5552, the server invokes only the check_vhost_access function to validate permissions. This function verifies whether the authenticated user has permission to access the specified virtual host but fails to enforce additional resource limits. In contrast, the standard AMQP protocol handler, rabbit_reader, performs a more comprehensive set of checks that include verifying node-level, vhost-level, and user-specific connection limits. These limits are crucial for preventing any single tenant from exhausting system resources or disrupting service availability for other tenants by opening an excessive number of connections.
The absence of these limit checks in the stream handler was explicitly acknowledged by developers through a FIXME comment within the source code, indicating that this oversight was known but not yet remediated at the time of release. There were no compensating controls implemented elsewhere in the rabbitmq_stream module or in general connection tracking mechanisms to mitigate this gap. Consequently, an authenticated tenant possessing valid stream-protocol credentials could establish connections without regard for the per-user or per-vhost caps configured by system operators. This bypass effectively nullifies a key operational safeguard designed to maintain stability and fairness among multiple tenants sharing the same RabbitMQ instance.
The operational impact of this vulnerability is significant in environments where connection limits are used as a primary mechanism for tenant isolation and denial-of-service prevention. An attacker or malicious insider could exploit this flaw by opening numerous connections via port 5552, potentially leading to resource exhaustion on the broker node. This could degrade performance for all users connected through standard AMQP ports or even other stream connections if system resources such as file descriptors or memory are depleted. The vulnerability undermines the reliability guarantees provided by RabbitMQ in multi-tenant deployments where strict quota enforcement is required to maintain service level agreements and operational stability.
This issue aligns with CWE Category 284, which covers Improper Access Control, specifically reflecting a failure to enforce proper restrictions on authenticated users regarding resource consumption limits. From an ATT&CK perspective, this vulnerability facilitates lateral movement or persistence by allowing an attacker to bypass security controls that limit their footprint and visibility within the network infrastructure. It represents a classic case of inconsistent enforcement across different interfaces for the same logical entity, where one interface (AMQP) is secured while another (Stream) remains vulnerable due to incomplete implementation of shared security policies.
The vulnerability has been addressed in RabbitMQ versions 4.2.7 and 4.3.1 by ensuring that the stream open handler performs the same comprehensive set of connection limit checks as the AMQP handler. Organizations running affected versions must upgrade immediately to mitigate this risk. In addition to upgrading, administrators should audit their current configurations to ensure that all access control policies are consistently applied across both AMQP and Stream interfaces. Monitoring tools should be configured to detect unusual spikes in connection counts on port 5552 as a defensive measure against exploitation attempts while patching is being implemented.