CVE-2026-66080 in RabbitMQ
Summary
by MITRE • 09/24/2026
RabbitMQ is a messaging and streaming broker. Prior to versions 4.1.11, 4.2.6, and 4.3.0, validate_partitions only checks that the requested partition count is at least 1, with no upper bound. A large count such as lists:seq(0, 500000000) allocates roughly 8GB. Preconditions include The rabbitmq_stream_management plugin must be enabled. The caller needs the management tag and access to the target vhost.. This issue is fixed in versions 4.1.11, 4.2.6, and 4.3.0.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
The vulnerability identified in RabbitMQ messaging brokers prior to versions 4.1.11, 4.2.6, and 4.3.0 represents a critical resource exhaustion flaw within the stream management subsystem. Specifically, the validate_partitions function responsible for verifying partition counts during stream creation or modification operations lacks an upper bound constraint on the requested number of partitions. While the implementation correctly ensures that the count is at least one to prevent invalid negative values, it fails to impose any maximum limit on positive integers provided by the caller. This oversight allows a malicious actor with sufficient privileges to request an excessively large partition count, such as five hundred million partitions via constructs like lists:seq(0, 500000000). The immediate operational consequence of this action is significant memory allocation pressure, where the system attempts to reserve approximately eight gigabytes of RAM for internal data structures associated with these non-existent or partially initialized partitions. This uncontrolled resource consumption can lead to severe performance degradation, service instability, or complete denial of service as the broker's memory usage spikes uncontrollably, potentially causing out-of-memory errors and process termination across the cluster nodes involved in handling the request.
From a security architecture perspective, this flaw is classified under CWE-789: Memory Allocation with Excessive Size Value, which describes situations where software allocates more memory than intended or necessary due to insufficient validation of input parameters. The vulnerability requires specific preconditions to be exploitable, notably that the rabbitmq_stream_management plugin must be enabled on the target broker instance. Furthermore, access is restricted by authentication and authorization mechanisms; the attacker must possess valid credentials with the management tag and have explicit permissions to interact with the targeted virtual host. Despite these prerequisites, the ease of triggering a massive memory allocation from an authenticated user highlights a significant gap in input validation logic within the administrative API surface area. This aligns with ATT&CK technique T1496: Resource Hijacking, where adversaries leverage legitimate system resources to disrupt availability or consume computational capacity for malicious purposes such as cryptomining or denial of service attacks against critical infrastructure components.
The impact extends beyond simple memory consumption, potentially affecting the stability of the entire RabbitMQ cluster if the node handling the request becomes unresponsive due to resource exhaustion. In clustered environments, this can trigger failover mechanisms that may further strain other nodes, leading to a cascading failure scenario. The lack of an upper bound also complicates monitoring and alerting efforts, as standard thresholds for memory usage might not account for such sudden, massive allocations triggered by legitimate-looking administrative commands. This makes detection through conventional means difficult without deep inspection of the specific API calls being made and their parameters.
To mitigate this vulnerability, organizations running affected versions must upgrade immediately to RabbitMQ version 4.1.11, 4.2.6, or 4.3.0, where the validate_partitions function has been patched to enforce appropriate upper limits on partition counts. Until upgrading is feasible, administrators should implement strict network-level access controls to restrict management API endpoints to trusted IP addresses and ensure that only highly privileged users have access to these interfaces. Additionally, deploying Web Application Firewalls or custom middleware that inspects HTTP requests for unusually large integer values in stream creation parameters can provide an additional layer of defense against exploitation attempts. Regular auditing of user permissions is also recommended to minimize the attack surface by ensuring that management tags are granted only to those who absolutely require them, thereby reducing the risk of insider threats or compromised accounts being used to trigger this resource exhaustion flaw.