CVE-2026-67219

Analyzed Analyzed - Analysis Complete

Memory Exhaustion via Arbitrary Weight Binding in RabbitMQ

Publication date: 2026-09-23

Last updated on: 2026-10-19

Assigner: GitHub, Inc.

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.

CVSS Scores

EPSS Scores

Probability:
Percentile:

Meta Information

Published

2026-09-23

Last Modified

2026-10-19

Generated

2026-11-08

AI Q&A

2026-09-24

EPSS Evaluated

2026-11-07

NVD

CVE-2026-67219

Affected Vendors & Products

Vendor	Product	Version / Range
broadcom	rabbitmq_server	From 3.13.0 (inc) to 3.13.15 (exc)
broadcom	rabbitmq_server	From 4.0.0 (inc) to 4.0.20 (exc)
broadcom	rabbitmq_server	From 4.1.0 (inc) to 4.1.11 (exc)
broadcom	rabbitmq_server	From 4.2.0 (inc) to 4.2.6 (exc)

Helpful Resources

Exploitability

CWE

KEV

CWE ID	Description
CWE-770	The product allocates a reusable resource or group of resources on behalf of an actor without imposing any intended restrictions on the size or number of resources that can be allocated.

Attack-Flow Graph

Executive Summary

This vulnerability in RabbitMQ involves the add_binding/3 function parsing a routing key as an integer weight. When a large integer is used, it creates an excessively large list stored in the exchange's Khepri record. This list is replicated across all cluster nodes and persists after restarts, consuming significant memory.

Detection Guidance

Check if the rabbitmq_consistent_hash_exchange plugin is enabled by running: rabbitmq-plugins list | grep consistent_hash. Inspect exchange bindings for unusually large routing key values using rabbitmqctl list_bindings. Monitor disk usage spikes on RabbitMQ nodes as a potential indicator.

Impact Analysis

An attacker with write permissions on a consistent-hash exchange and read on a queue could exploit this to allocate massive memory on all cluster nodes, causing denial of service or system crashes. A single binding with weight 100000000 consumes ~800 MB per node.

Compliance Impact

This vulnerability could lead to denial-of-service conditions by consuming excessive memory, potentially disrupting system availability. For GDPR, this may impact availability of personal data processing systems. For HIPAA, it could affect the integrity and availability of protected health information systems.

Mitigation Strategies

Upgrade RabbitMQ to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, or 4.3.0 or later. Disable the rabbitmq_consistent_hash_exchange plugin if not needed. Restrict write permissions on consistent-hash exchanges and review binding permissions.

Hi! I’m here to help you understand CVE-2026-67219. Ask me anything about the vulnerability, its impact, or mitigation strategies.

0/70

EPSS Chart

Security Radar

News mentioning this vulnerability

Loading related security news...