RabbitMQ CVE-2026-67219

Requires the rabbitmq_consistent_hash_exchange plugin to be enabled (not enabled by default) AND an authenticated user holding write permission on a consistent-hash exchange plus read permission on a target queue - i.e. standard binding permissions, not administrative rights. Exploitation is limited by these two factors: the plugin must be active, and the attacker must already possess a low-privilege account with binding rights on that exchange type. Where the plugin is disabled or untrusted users lack binding permissions on consistent-hash exchanges, the vulnerability is not reachable. The impact is amplified because the malicious binding is persisted to Khepri, replicated to all cluster nodes, and reloaded on restart, so it cannot be remediated by a simple broker restart.

This is a genuine but bounded operational risk - a denial-of-service, not a compromise. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:L/UI:N) with VA:H and CWE-770 (Uncontrolled Resource Allocation) is internally consistent with the description: a network-reachable, low-privilege authenticated user can trivially exhaust memory. No EPSS score, no CISA KEV listing, and no public exploit are present in the input, so exploitation status is 'no public exploit identified at time of analysis' - this is not a widespread-exploitation emergency. The AT:P (Attack Requirements: Present) reflects that the attacker must already hold specific binding permissions AND the rabbitmq_consistent_hash_exchange plugin must be enabled, which meaningfully narrows the affected population and correctly keeps the score at 6.0 (medium) rather than higher. The distinguishing aggravator versus RabbitMQ's atom-exhaustion DoS siblings is PERSISTENCE: the oversized integer list is written to the Khepri metadata store, replicated to every cluster node, and reloaded on restart - so a single malicious binding survives reboots and cannot be cleared by simply restarting the broker, raising remediation cost. There is no confidentiality or integrity impact (VC:N/VI:N). Net: prioritize patching where the consistent-hash exchange plugin is enabled and untrusted tenants hold binding permissions; deprioritize where the plugin is disabled (default).

An authenticated tenant with write permission on a consistent-hash exchange and read permission on a queue creates a single binding whose routing key (interpreted as the hash-ring weight) is set to a very large integer such as 100000000. The broker calls lists:seq/2 to allocate a list of that many integers (~800 MB), persists it to Khepri, and replicates it to every node, causing cluster-wide memory exhaustion that survives restarts. No public PoC is referenced, but the technique is fully described in the GitHub advisory and requires only standard binding operations.