The vulnerability allows a user with write permissions on a consistent‑hash exchange and read access to a queue to set an arbitrarily large routing‑key weight when adding a binding. The broker accepts any positive integer weight without an upper bound, allocating a list of that many integer positions in memory. A binding weight of 100,000,000 can consume roughly 800 MB per node and survives restarts, leading to memory exhaustion and potential denial of service. This flaw falls under CWE‑770, where insufficient checks on resource usage can degrade availability.

Affected are RabbitMQ Server instances running any version earlier than 3.13.15, 4.0.20, 4.1.11, 4.2.6, or 4.3.0. All deployments that enable the rabbitmq_consistent_hash_exchange plugin and grant a user write permission on a consistent‑hash exchange plus read permission on a queue are vulnerable. The issue is resolved in the aforementioned versions and all subsequent releases.

The CVSS score of 6.0 indicates moderate severity. The EPSS score is unavailable, and the vulnerability is not listed in CISA’s KEV catalog. Exploitation requires that the attacker can create or modify a binding on a consistent‑hash exchange, which can be done via the AMQP protocol or the HTTP management API if the user has the necessary permissions. The lack of an upper bound on the weight argument allows the attacker to cause significant memory usage and interrupt message routing, potentially leading to service disruption in a single node or cluster-wide if the binding is replicated.