CVE-2026-67219

MEDIUMCVSS 6/10EPSS 0.26%

Last modified

CVE-2026-67219 is a medium-severity vulnerability rated 6/10 on the CVSS scale. 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). EPSS estimates a 0.26% chance of exploitation in the next 30 days.

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.

Metrics

Weakness Enumeration

Affected Software

Source: CNA advisory (CVE.org). NVD analysis pending.

VendorProductVersions
rabbitmqrabbitmq-server>= 3.13.0, < 3.13.15; >= 4.0.0, < 4.0.20; >= 4.1.0, < 4.1.11; >= 4.2.0, < 4.2.6

References

Timeline

Published
Last Modified
Status
Awaiting Analysis

Frequently Asked Questions

What is CVE-2026-67219?
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.
How severe is CVE-2026-67219?
CVE-2026-67219 has a CVSS score of 6/10 (MEDIUM severity). The EPSS model estimates a 0.26% probability of exploitation in the next 30 days.
How do I fix CVE-2026-67219?
Check the vendor references and advisories linked above for patched versions and mitigation guidance. You can also run a Strix scan to test if your systems are affected.

How Strix Helps

Related CVEs from 2026

Are you affected by CVE-2026-67219?

Run a free Strix scan to check your systems for this vulnerability.

Scan your code now

Source: NVD / NIST