CVE-2026-61837 Overview
RabbitMQ exposes complete binding topology to any authenticated AMQP 1.0 user through the management GET /bindings endpoint without enforcing resource-level permission checks. The vulnerability affects RabbitMQ versions from 4.0.0 up to the patched releases 4.3.3, 4.2.9, 4.1.14, and 4.0.23. The rabbit_amqp_management handler ignores the authenticated user context when enumerating bindings. Any client that can open a management link pair, including accounts without the management, monitoring, policymaker, or administrator tag, can enumerate source exchanges, destination queues or exchanges, routing keys, and binding arguments within accessible virtual hosts. This is a missing authorization issue tracked under [CWE-285].
Critical Impact
Low-privilege AMQP 1.0 users can enumerate the complete routing topology of any virtual host they can connect to, leaking confidential architecture details that assist lateral movement and targeted message interception.
Affected Products
- RabbitMQ 4.0.0 through 4.0.22
- RabbitMQ 4.1.0 through 4.1.13
- RabbitMQ 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2
Discovery Timeline
- 2026-09-25 - CVE-2026-61837 published to NVD
- 2026-09-29 - Last updated in NVD database
Technical Details for CVE-2026-61837
Vulnerability Analysis
The flaw resides in the AMQP 1.0 HTTP-over-AMQP management endpoint implemented in rabbit_amqp_management. Sibling operations in the same module invoke check_resource_access/* and binding_checks/* before returning data. The GET /bindings handler omits these checks entirely. An authenticated AMQP 1.0 client sends a management request specifying an arbitrary source exchange and destination queue or exchange. The handler returns the full binding list for the requested pair without validating the caller's permissions on either resource. The result is an authorization gap that reveals routing topology to any account with virtual host access.
Root Cause
The root cause is a missing authorization check [CWE-285]. The handle_http_req/8 path for GET /bindings did not call the permission helpers used by other handlers in the module. The authenticated User record was accepted but never consulted when assembling the response.
Attack Vector
An attacker needs valid AMQP 1.0 credentials with permission to connect to a virtual host. No management role is required. The attacker opens a management link pair and issues GET /bindings requests enumerating candidate exchange and queue pairs. Returned data includes routing keys and binding arguments, exposing message flow design.
// Patch excerpt - deps/rabbit/src/rabbit_amqp_management.erl
-ifdef(TEST).
-export([check_routing_arg/5,
check_alternate_exchange/4,
- check_dead_letter_exchange/4]).
+ check_dead_letter_exchange/4,
+ handle_http_req/8]).
-endif.
-type permission_caches() :: {rabbit_amqp_session:permission_cache(),
Source: RabbitMQ Commit 341e3f2
// Patch excerpt - deps/rabbitmq_amqp_client/src/rabbitmq_amqp_client.erl
unbind_exchange/5,
delete_exchange/2,
+ %% binding operations
+ list_bindings/4,
+
set_token/2
]).
Source: RabbitMQ Commit b94004d
Detection Methods for CVE-2026-61837
Indicators of Compromise
- Unexpected AMQP 1.0 management link pairs opened by accounts lacking a management tag.
- High-volume GET /bindings requests from a single connection enumerating multiple exchange and queue pairs.
- Access patterns originating from low-privilege application service accounts that typically only publish or consume messages.
Detection Strategies
- Enable RabbitMQ connection and channel logging and correlate AMQP 1.0 management operations with the authenticated user tag.
- Alert when accounts without management, monitoring, policymaker, or administrator tags issue management endpoint calls.
- Baseline normal management API usage per application identity and flag deviations.
Monitoring Recommendations
- Forward RabbitMQ broker logs to a central SIEM for authorization-anomaly correlation.
- Monitor the rabbit_amqp_management subsystem for repeated GET /bindings requests across virtual hosts.
- Review HTTP management access logs (GET /api/bindings) alongside AMQP 1.0 activity for parallel reconnaissance.
How to Mitigate CVE-2026-61837
Immediate Actions Required
- Upgrade RabbitMQ to version 4.3.3, 4.2.9, 4.1.14, or 4.0.23 depending on your deployed branch.
- Audit AMQP 1.0 user accounts and remove unused or over-permissioned credentials.
- Restrict virtual host access to the minimum set of users required for message operations.
Patch Information
Fixed releases are available at RabbitMQ Release v4.3.3 and RabbitMQ Release v4.2.9. Review the full technical write-up in the RabbitMQ Security Advisory GHSA-w9hf-476r-443x. The fix adds a handle_http_req/8 permission check aligning GET /bindings behavior with the other binding operations in rabbit_amqp_management.
Workarounds
- Disable the AMQP 1.0 plugin where it is not required by application workloads.
- Segment virtual hosts so that application identities cannot connect to vhosts containing sensitive routing topology.
- Enforce TLS and network-layer ACLs to limit which hosts can reach the AMQP 1.0 management endpoint.
# Disable the AMQP 1.0 plugin as a temporary mitigation
rabbitmq-plugins disable rabbitmq_amqp1_0
# Verify active plugins
rabbitmq-plugins list -e
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

