RabbitMQ EUVD-2026-43022

Requires an authenticated broker connection (CVSS PR:L) with permission to declare bindings within a virtual host shared with the victim's RPC workload, and the deployment must use the direct reply-to pattern via the amq.rabbitmq.reply-to pseudo-destination with the Khepri metadata store. The attacker creates a foreign binding to another connection's volatile direct-reply-to queue, which is accepted at bind/route time but not removed by Khepri deletion checks, leaving a persistent route after unbind. Exploitation is limited by the need for valid credentials, high attack complexity (AC:H - the attacker must contend with the volatile lifecycle and timing of another client's reply-to queue), and the requirement that the target actually uses the direct reply-to RPC pattern in a shared vhost; single-tenant brokers or workloads not using amq.rabbitmq.reply-to are not exposed.

The vendor CVSS 4.0 score is 7.0 (High) with vector AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:H/SI:N/SA:N - network-reachable but requiring low-level authentication (PR:L) and, importantly, high attack complexity (AC:H), with impact limited to confidentiality of the vulnerable system (VC:H) and a subsequent-system confidentiality impact (SC:H), and no integrity or availability impact. This is a confidentiality/authorization-boundary issue (a client reading RPC replies destined for others), not RCE or DoS. No EPSS score, KEV listing, or SSVC decision was supplied, and no POC is referenced - only upstream fix PRs and commits. The AC:H rating and PR:L requirement meaningfully constrain real-world risk: an attacker needs valid broker credentials and must win a timing/route-persistence condition, so this is a targeted lateral-information-disclosure risk in multi-tenant or shared-credential broker deployments rather than a mass-exploitable internet-facing threat. The 'Authentication Bypass' tag is somewhat imprecise - the CWE-863 root cause and PR:L vector indicate an authorization/isolation failure between authenticated clients, not an unauthenticated bypass; treat that tag with caution.

An attacker holding valid broker credentials in a multi-tenant RabbitMQ deployment binds a queue of their own to another client's amq.rabbitmq.reply-to destination; because the volatile route entry is not cleaned up in Khepri's deletion checks, the foreign binding persists and the attacker receives RPC reply messages intended for the legitimate requester, disclosing confidential response data. No public POC is referenced, and the high attack complexity means the attacker must satisfy timing/route-persistence conditions to reliably capture replies.