CVE-2026-67419 in RabbitMQinfo

Summary

by MITRE • 09/25/2026

RabbitMQ is a messaging and streaming broker. Prior to 4.3.5, an authenticated user who can bind a queue to a topic exchange and publish to it can use consecutive # segments in a binding key to make both topic matchers revisit the same trie-node and routing-key-suffix states without memoization. The matcher materializes duplicate destinations before deduplication, causing combinatorial CPU work and memory pressure that can disrupt routing for all tenants. This vulnerability is fixed in 4.3.5.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Analysis

by VulDB Data Team • 09/25/2026

RabbitMQ serves as a widely adopted messaging broker facilitating asynchronous communication between distributed systems through message queuing and streaming capabilities. The software relies on complex pattern matching algorithms to route messages from exchanges to queues based on binding keys, particularly when using topic exchanges where wildcards allow for flexible routing rules. A critical flaw exists in the implementation of these topic matchers within versions prior to 4.3.5, specifically affecting how consecutive hash symbols are processed during the binding key evaluation process. This vulnerability represents a significant deviation from expected resource management practices, allowing an authenticated user with permissions to bind queues to topic exchanges and publish messages to exploit this logic error for denial of service purposes.

The technical root cause lies in the traversal mechanism used by the topic matcher when evaluating routing keys against bound patterns. When a binding key contains consecutive hash segments, such as ## or ###, the matching algorithm revisits identical trie nodes and routing-key-suffix states without employing memoization techniques to cache results. In standard implementations, memoization prevents redundant computation by storing previously calculated outcomes for specific state combinations. Without this optimization, the matcher materializes duplicate destination entries before performing deduplication steps. This lack of caching forces the system to perform exhaustive combinatorial calculations on every message publication that triggers these patterns, leading to exponential growth in computational complexity relative to the number of consecutive wildcards and bound queues.

The operational impact of this vulnerability is severe, manifesting as a resource exhaustion attack vector accessible only to authenticated users who possess specific publishing and binding privileges. By crafting messages with routing keys containing multiple consecutive hash symbols, an attacker can trigger massive CPU consumption and significant memory pressure on the RabbitMQ server nodes. This excessive load does not merely affect the targeted tenant or queue but disrupts message routing for all tenants sharing the same broker instance. The resulting performance degradation can lead to increased latency, dropped messages, or complete service unavailability, effectively achieving a denial of service condition against the entire messaging infrastructure rather than just an isolated component.

From a classification perspective, this vulnerability aligns with CWE-787 Out-of-bounds Write in terms of resource allocation inefficiency and more accurately maps to CWE-400 Uncontrolled Resource Consumption due to the combinatorial explosion causing system strain. In the context of the MITRE ATT&CK framework, this behavior corresponds to T1496 Resource Hijacking or potentially T1499 Endpoint Denial of Service, as it involves leveraging legitimate access to exhaust computational resources and disrupt service availability for other users on the same host. The attack requires prior authentication, placing it within the scope of insider threats or compromised credentials rather than remote unauthenticated exploitation.

Mitigation strategies primarily involve upgrading RabbitMQ to version 4.3.5 or later, where the topic matcher logic has been corrected to implement proper memoization and prevent redundant state revisiting during pattern matching. For environments unable to immediately patch, administrators should enforce strict least-privilege access controls to limit which users can bind queues to topic exchanges or publish messages with complex routing keys. Additionally, implementing rate limiting on message publishing rates for high-risk accounts can help mitigate the potential impact of such attacks by throttling the volume of traffic that triggers the combinatorial logic before it causes significant resource exhaustion. Monitoring CPU and memory usage patterns associated with specific user activities can also aid in early detection of exploitation attempts targeting this flaw.

Responsible

GitHub M

Reservation

07/29/2026

Disclosure

09/25/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

very low

Sources

Are you interested in using VulDB?

Download the whitepaper to learn more about our service!