Описание
Consistent-hash exchange unbounded weight
Origin
This vulnerability was identified by Team RabbitMQ and/or other teams at Broadcom, not via a responsible disclosure from an external researcher.
Source references
deps/rabbitmq_consistent_hash_exchange/src/rabbit_exchange_type_consistent_hash.erl:158 · Unbounded Memory Allocation
Impact
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.
Description
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.
Exploit scenario
channel.queue_bind(queue='q', exchange='hash-ex', routing_key='500000000'). Broker calls lists:seq(0, 499999999) → ~4 GB list. All cluster nodes attempt to replicate it. Nodes OOM or become unresponsive.
Preconditions
- rabbitmq_consistent_hash_exchange plugin enabled
- write permission on a consistent-hash exchange + read on a queue (standard binding perms)
CVSS
CVSS v4.0: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N (6.0, Moderate). Fixed in 3.13.15, 4.0.20, 4.1.11, 4.2.6, 4.3.0.
Пакеты
rabbitmq
>= 3.13.0, < 3.13.15
3.13.15
rabbitmq
>= 4.0.0, < 4.0.20
4.0.20
rabbitmq
>= 4.1.0, < 4.1.11
4.1.11
rabbitmq
>= 4.2.0, < 4.2.6
4.2.6