CVE-2026-57221: 
RabbitMQ vulnerability analysis and mitigation

CVE-2026-57221 is a missing authorization vulnerability in RabbitMQ's AMQP 0-9-1 protocol handling, allowing authenticated users with minimal permissions to enumerate queue and exchange names and read queue metadata. It affects RabbitMQ versions 3.13.0–3.13.14, 4.0.0–4.0.19, 4.1.0–4.1.10, and 4.2.0–4.2.5. The vulnerability was published on July 10, 2026, with the fix merged on April 14, 2026, and the security advisory published June 24, 2026. It carries a CVSS v3.1 base score of 5.0 (Medium) and a CVSS v4.0 base score of 5.3 (Medium) (GitHub Advisory).

The root cause is CWE-862 (Missing Authorization) in RabbitMQ's AMQP 0-9-1 channel handler (deps/rabbit/src/rabbit_channel.erl). The handlers for queue.declare with passive=true (lines 2461–2474) and exchange.declare with passive=true (lines 2570–2575) explicitly ignore the _AuthzContext and _User parameters — making no calls to check_configure_permitted, check_read_permitted, or check_write_permitted. In contrast, other operations like queue.delete and basic.consume correctly enforce authorization. An attacker only needs a valid AMQP connection to a virtual host (even with empty configure=^$, write=^$, read=^$ permissions) to exploit this by sending passive declare requests for known or guessed queue/exchange names (GitHub Advisory, Fix Commit).

Successful exploitation results in unauthorized information disclosure — specifically, any authenticated user can enumerate all queue and exchange names within a virtual host, read current message counts (revealing processing backlogs and business activity levels), and read consumer counts (revealing which queues are actively processed). In multi-tenant SaaS platforms, shared development environments, or microservice architectures where multiple services share a virtual host with scoped permissions, this enables cross-tenant reconnaissance. There is no integrity or availability impact, and actual message content cannot be read via this vulnerability — basic.get and basic.publish remain properly access-controlled (GitHub Advisory).

A proof-of-concept exploit is publicly available in the official GitHub security advisory, including step-by-step curl commands and a Python script using the pika library that demonstrates the authorization bypass against a live RabbitMQ instance (GitHub Advisory). There is no evidence of in-the-wild exploitation at this time, and no threat actor attribution has been reported. The EPSS score is approximately 0.0027 (low probability of exploitation in the near term). The vulnerability is not listed in the CISA KEV catalog. Exploitation requires authenticated access to the target virtual host, limiting the attack surface to users who already have valid credentials.

1. Obtain credentials: Acquire any valid RabbitMQ user account that has been granted access to a target virtual host — even with completely empty permissions (configure=^$, write=^$, read=^$).
2. Connect via AMQP: Establish an AMQP 0-9-1 connection to the RabbitMQ broker on port 5672 using the low-privilege credentials (e.g., using the Python pika library: pika.BlockingConnection(pika.ConnectionParameters('target', 5672, '/', creds))).
3. Enumerate queues: Issue passive queue.declare requests for known or guessed queue names. The broker returns the queue name, message count, and consumer count without performing authorization checks:

result = ch.queue_declare(queue='target-queue-name', passive=True)
print(result.method.message_count, result.method.consumer_count)

4. Enumerate exchanges: Issue passive exchange.declare requests to confirm the existence of exchanges (e.g., amq.direct, amq.fanout, amq.topic, custom exchange names).
5. Map broker topology: Iterate over candidate names to build a complete map of queue and exchange names, message depths, and consumer activity — revealing internal application architecture and business activity levels.
6. Use for further reconnaissance: Leverage discovered queue/exchange names to identify high-value targets (e.g., orders, payments, transactions) for timing correlation attacks or to inform further exploitation attempts (GitHub Advisory).

• Network: Unusual volume of AMQP queue.declare (passive) or exchange.declare (passive) frames from a single client connection, especially from accounts with minimal permissions; connections from unexpected source IPs using low-privilege accounts.
• Logs: RabbitMQ connection/channel logs showing a low-privilege user (with empty configure/write/read permissions) successfully performing passive declare operations across many queue or exchange names in rapid succession; look for repeated queue.declare passive requests in AMQP debug logs.
• Behavioral: A user account with configure=^$, write=^$, read=^$ permissions successfully connecting and issuing passive declares — this should not succeed on patched versions; any account probing a large number of queue names sequentially without corresponding basic.consume or basic.publish activity.

Upgrade RabbitMQ to one of the patched versions: 3.13.15, 4.0.20, 4.1.11, or 4.2.6 (or later). The fix adds check_configure_permitted calls to the passive queue.declare and exchange.declare handlers; a subsequent refinement (PR #16272) relaxes this to require any permission (read or write) rather than specifically configure, to avoid breaking applications that use passive declares for existence checks without configure rights. As interim mitigations, restrict network access to the RabbitMQ AMQP port (5672) to trusted hosts only, and enforce strict authentication policies limiting which users can connect to virtual hosts. Note that upgrading may be a breaking change for applications relying on passive declares without configure permissions — review user permission sets before upgrading (GitHub Advisory, Fix PR).

The vulnerability received notable media coverage shortly after public disclosure, with articles from SecurityWeek, The Hacker News, CSO Online, SC World, and GBHackers covering the issue in the context of broader RabbitMQ security flaws (SecurityWeek, The Hacker News). Security researcher Liad Miggo (Miggo Security) was credited as the reporter, and Miggo published a detailed blog post describing the vulnerability as part of a broader set of RabbitMQ flaws enabling broker takeover (Miggo Blog). Community reaction on the GitHub pull request was mixed — several users noted the fix was a breaking change for Spring-based applications using @RabbitListener annotations, which internally perform passive declares without configure permissions; the RabbitMQ team subsequently issued a follow-up fix (PR #16272) to require only any permission rather than specifically configure permission for passive declares (Fix PR).