CVE-2026-57215 in RabbitMQ
Summary
by MITRE • 07/10/2026
RabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, RabbitMQ allows foreign bindings to amq.rabbitmq.reply-to destinations because volatile direct-reply-to queues can be accepted at bind and route time but are missing from Khepri-backed deletion checks, leaving persistent route entries after unbind. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 07/10/2026
This vulnerability affects RabbitMQ messaging brokers where foreign bindings to amq.rabbitmq.reply-to destinations can persist indefinitely due to flawed deletion checks in the Khepri backend storage system. The issue manifests when volatile direct-reply-to queues are accepted during bind and route operations but are subsequently excluded from proper cleanup procedures during unbind operations. This creates a scenario where persistent route entries remain in the system even after the corresponding queues have been removed, effectively leaving orphaned binding references that can persist across broker restarts or other operational changes.
The technical flaw stems from an inconsistency in how the Khepri backend handles deletion validation for volatile queues versus persistent ones. During normal queue operations, RabbitMQ creates temporary reply-to queues that are designed to be volatile and should be automatically cleaned up when no longer needed. However, the deletion check mechanism fails to account for these volatile queues during unbind operations, leading to incomplete cleanup of routing table entries. This represents a classic case of improper resource management where temporary resources are not properly disposed of, creating persistent references that can lead to various operational issues including memory leaks, routing inconsistencies, and potential security concerns.
The operational impact of this vulnerability extends beyond simple resource leakage to potentially affect message routing reliability and system stability. When foreign bindings persist after queue removal, they can cause unexpected behavior in message delivery patterns, particularly when the same routing keys are used for different purposes. The vulnerability is especially concerning in environments where dynamic queue creation and destruction occurs frequently, as it can lead to accumulation of stale routing entries over time. These orphaned bindings may also interfere with normal queue management operations and could potentially be exploited by malicious actors to manipulate message routing or create denial-of-service conditions.
The fix implemented in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6 addresses this by ensuring that the Khepri-backed deletion checks properly account for volatile direct-reply-to queues during both bind and unbind operations. This comprehensive fix ensures that all queue types, whether volatile or persistent, are consistently validated during cleanup procedures to prevent orphaned routing entries from persisting in the system. Organizations should prioritize upgrading to these patched versions as soon as possible to eliminate the risk of persistent foreign bindings and maintain proper message broker functionality. The vulnerability aligns with CWE-404, which covers improper resource management, and could potentially be leveraged in attacks that exploit resource exhaustion or routing manipulation as outlined in ATT&CK technique T1587 for resource hijacking.
Security practitioners should monitor their RabbitMQ deployments closely to identify any existing instances of this vulnerability before applying patches. The fix demonstrates proper implementation of resource lifecycle management principles, ensuring that all temporary resources are appropriately tracked and cleaned up regardless of their type or status during system operations. This vulnerability serves as a reminder of the importance of comprehensive testing for edge cases in distributed messaging systems where temporary and persistent resources interact, particularly in complex routing scenarios involving reply-to mechanisms.