All vulnerabilities
CVE-2026-67219GHSA-m8pg-4x2h-jvgr

rabbitmq-server: RabbitMQ: Consistent-hash exchange unbounded weight

rabbitmq rabbitmq-server
CVSS
6.0Medium
ExploitationNo known exploitationNot in CISA KEV, which does not prove it is unexploitedCISA KEV
Exploit odds (EPSS)0.30%Chance of exploitation activity in the next 30 days, higher than 21% of CVEs. Scored 23 Oct 2026FIRST EPSS
Fixed inNone listedNo source names a fixed version. Check the vendor advisory below
Published23 Sep 2026Updated 24 Sep 2026CVE List

What fixes it

No source in this snapshot names a fixed version. The vendor advisories under References are the place to check.

Description

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.

Text from CVE List

Affected versions 4

  • rabbitmq-serveraffected: >= 3.13.0, < 3.13.15CVE List
  • rabbitmq-serveraffected: >= 4.0.0, < 4.0.20CVE List
  • rabbitmq-serveraffected: >= 4.1.0, < 4.1.11CVE List
  • rabbitmq-serveraffected: >= 4.2.0, < 4.2.6CVE List

References 3