Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, RabbitMQ incorrectly allows bindings to the special amq.rabbitmq.reply-to destination for volatile direct-reply-to queues. Because deletion checks against the Khepri backend are missing, routes created for these short-lived queues can remain after the queues are removed, creating persistent phantom route entries. An attacker can exploit this flaw to inject a reply channel that stays active after the intended lifetime, potentially intercepting or redirecting responses to messages destined for legitimate consumers.

The affected product is RabbitMQ Server from the vendor rabbitmq. Any installation running a version older than 3.13.15, 4.0.20, 4.1.11, or 4.2.6 is vulnerable. The issue is fixed in releases 3.13.15, 4.0.20, 4.1.11, and 4.2.6.

The CVSS score of 7 indicates high severity, and the EPSS score of less than 1% suggests a very low likelihood of exploitation. The vulnerability is not listed in the CISA KEV catalog. Exploitation would require the ability to create a binding to the amq.rabbitmq.reply-to queue, which is typically protected by authentication and authorization controls. The requirement for such controls is inferred from the fact that binding creation is a privileged operation; if those controls are misconfigured or absent, an attacker could persistently inject a reply channel. The attack is non-local to a specific process and can occur remotely over the network if the broker is exposed.