{"id":"AZL-105759","summary":"CVE-2026-67219 affecting package rabbitmq-server 3.13.7-9","details":"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 \u003e= 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.","modified":"2026-10-06T05:33:34Z","published":"2026-09-23T21:17:00Z","upstream":["CVE-2026-67219"],"references":[{"type":"WEB","url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67219"}],"affected":[{"package":{"name":"rabbitmq-server","ecosystem":"Azure Linux:3","purl":"pkg:rpm/azure-linux/rabbitmq-server"},"ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"3.13.7-9"}]}],"database_specific":{"source":"https://github.com/microsoft/AzureLinuxVulnerabilityData/blob/main/osv/AZL-105759.json"}}],"schema_version":"1.9.0"}