RabbitMQ CVE-2026-67419

Requires an authenticated RabbitMQ account (PR:L) holding permissions to bind a queue to a TOPIC exchange and to publish messages to it on a virtual host. The specific trigger is a binding key with two or more consecutive '#' multi-segment wildcards, which the vendor fix explicitly guards (bookkeeping only engages when Hashes >= 2); a single '#' cannot cause the combinatorial re-visits. Exploitation is limited by the need for valid credentials with configure/write rights and affects broker versions prior to 4.3.5; there is no user-interaction or non-default-plugin requirement, and topic exchanges are a standard routing feature, so the main gate is authentication rather than an unusual deployment mode. Impact is availability-only (routing disruption for all co-tenants), with no data disclosure or modification.

This is a genuine but conditional denial-of-service issue, not a critical priority. The CVSS 4.0 vector (7.1, AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:H) correctly models a pure availability impact with no confidentiality or integrity effect, requiring only low privileges and no user interaction - consistent with the CWE-407 (algorithmic complexity) root cause. Signals do NOT indicate widespread exploitation: no EPSS score, no CISA KEV listing, and no public exploit code are provided, so this is 'no public exploit identified at time of analysis' rather than an actively-exploited flaw. The commit diff confirms the technical mechanism (unmemoized trie traversal with two or more '#' edges causing combinatorial state re-visits), so the vulnerability itself is well-substantiated by vendor source. The 'Information Disclosure' tag directly CONTRADICTS the CVSS vector (VC:N/VI:N), and the 'Microsoft' vendor tag is wrong - RabbitMQ is an open-source Broadcom/VMware/Pivotal project. Real-world risk is moderate: exploitation needs an authenticated broker user with rights to bind to and publish on a topic exchange, but topic exchanges are a common default routing pattern, making this more reachable than RabbitMQ's plugin-gated or OAuth-gated DoS siblings.

An authenticated tenant with configure/write permissions on a virtual host declares a queue and binds it to a topic exchange using a binding key containing consecutive '#' wildcard segments, then publishes messages to that exchange. Each publish forces the topic matcher to redundantly re-visit the same trie-node/routing-key-suffix states without memoization, exploding CPU and memory usage and stalling message routing for all tenants sharing the broker. No public proof-of-concept is provided, but the vendor commit clearly documents the combinatorial blow-up, making a working trigger straightforward to construct.