CVE-2026-67219 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.0, add_binding/3 parses the routing key as an integer weight N and computes ring positions with lists:seq(NextN0, NextN0 + N - 1). validate_binding/2 only checks N >= 1 , no upper bound. The resulting list is stored in the exchange's Khepri record, replicated cluster-wide, and reloaded on restart. A user with write permission on a consistent-hash exchange and read on a queue can create a binding whose routing key (the hash-ring weight) is an arbitrarily large integer. The broker allocates a list of that many integers via lists:seq/2 and persists it to Khepri across all cluster nodes , a single binding with weight 100000000 allocates ~800 MB on every node and survives restarts. Preconditions include rabbitmq_consistent_hash_exchange plugin enabled write permission on a consistent-hash exchange + read on a queue (standard binding perms). This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.
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 in RabbitMQ messaging broker software represents a critical resource exhaustion flaw rooted in the implementation of the consistent hash exchange plugin. This component is designed to distribute messages across queues based on hashed routing keys, utilizing a ring topology where bindings are assigned weights that determine their proportionate share of traffic. The core technical deficiency lies within the add_binding/3 function and its interaction with validate_binding/2. Specifically, while the validation logic ensures that the weight N associated with a binding is greater than or equal to one, it fails to enforce any upper bound on this integer value. Consequently, an attacker possessing write permissions on a consistent-hash exchange and read access to at least one queue can construct a malicious binding where the routing key serves as an arbitrarily large integer representing the hash-ring weight. This lack of input validation allows for the creation of bindings with weights that far exceed reasonable operational limits, directly triggering excessive memory allocation during the construction of the internal data structures used to manage the ring topology.
The operational impact of this flaw is severe and manifests primarily through catastrophic resource consumption leading to service denial. When a binding with an excessively large weight such as one hundred million is created, the broker invokes lists:seq/2 to generate a list containing that many integers representing positions on the hash ring. This operation results in the allocation of approximately eight hundred megabytes of memory per cluster node for a single binding entry. Because RabbitMQ operates typically as a clustered system, this excessive memory footprint is replicated across all nodes within the cluster via the Khepri record persistence mechanism. The situation is exacerbated by the fact that these bindings are persisted to disk and reloaded upon service restarts. This means that even if the broker process were restarted or recovered from an outage, the malicious binding would persist, causing immediate memory exhaustion again before any administrative intervention could remove it. The cumulative effect across a multi-node cluster can lead to total system instability, out-of-memory errors, and complete unavailability of messaging services for all connected clients.
From a security classification perspective, this vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, as the application fails to properly control the allocation and maintenance of resources based on external input. Furthermore, it relates closely to CWE-789, Memory Allocation with Excessive Size Value, due to the direct consequence of passing an unbounded integer into a sequence generation function that allocates memory proportional to its argument. In terms of attack vectors within the MITRE ATT&CK framework, this flaw facilitates Denial-of-Service attacks by enabling adversaries to exhaust system resources through crafted API calls or message bindings rather than exploiting code execution flaws. The precondition for exploitation is relatively standard in many enterprise deployments where users are granted write access to exchanges and read access to queues for application functionality, making the attack surface broad unless strict permission policies are enforced.
Mitigation strategies must focus on both immediate remediation and long-term architectural hardening. The primary and most effective solution is to upgrade RabbitMQ to version 3.13.15 or later, including versions 4.0.20, 4.1.11, 4.2.6, and 4.3.0, where the validation logic has been corrected to enforce appropriate upper bounds on binding weights. For environments that cannot immediately upgrade, administrators should implement strict access control policies by limiting write permissions on consistent-hash exchanges only to trusted administrative accounts or application services with verified input sanitization capabilities. Additionally, deploying network-level firewalls or API gateways in front of the RabbitMQ management interface can help filter out requests containing unusually large integer values before they reach the broker logic. Monitoring tools should also be configured to alert on sudden spikes in memory usage associated with specific exchange bindings, allowing for rapid detection and removal of malicious configurations before total system failure occurs.