Rabbitmq server: RabbitMQ is a messaging and streaming broker. (CVE-2026-67219)

The vulnerability in RabbitMQ's consistent-hash exchange plugin involves the add_binding/3 function parsing the routing key as an integer weight N without an upper bound check. The function computes ring positions using lists:seq(NextN0, NextN0 + N - 1), allocating a list of N integers. Since validate_binding/2 only checks that N >= 1 and does not limit the upper bound, a user with appropriate permissions can specify a very large weight, causing the broker to allocate and persist a large list in the exchange's Khepri record cluster-wide. This can lead to significant memory consumption (~800 MB per node for weight 100000000) and resource exhaustion. The vulnerability requires the rabbitmq_consistent_hash_exchange plugin to be enabled and specific permissions. It is fixed in RabbitMQ versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.

An attacker with write permission on a consistent-hash exchange and read permission on a queue can cause the RabbitMQ broker to allocate excessive memory on all cluster nodes by creating a binding with a very large routing key weight. This can lead to resource exhaustion, degraded performance, or denial of service. The allocated data persists across restarts, increasing the impact duration. No direct code execution or data leakage is described.

Upgrade RabbitMQ to version 3.13.15, 4.0.20, 4.1.11, 4.2.6, or 4.3.0 or later, where this issue is fixed. Ensure the rabbitmq_consistent_hash_exchange plugin is updated accordingly. Restrict permissions to prevent untrusted users from having write access to consistent-hash exchanges and read access to queues. Patch status is confirmed fixed in the specified versions.