CVE-2026-57216: RabbitMQ Server Auth Bypass Vulnerability

CVE-2026-57216 Overview

CVE-2026-57216 is an authentication bypass vulnerability [CWE-287] in RabbitMQ affecting AMQP 0-9-1, AMQP 1.0, and Stream Protocol listeners. The flaw allows loopback-restricted accounts, including the default guest user, to authenticate from remote networks when traffic traverses a trusted PROXY-protocol path to a loopback-bound backend listener. The loopback check evaluates the listener-side socket address instead of the real client source address, defeating the localhost-only restriction. Broadcom's RabbitMQ Server is affected in versions prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6.

Critical Impact
Remote attackers can authenticate as the guest account across a network boundary, gaining full broker access to publish, consume, and administer messaging infrastructure.

Affected Products

Broadcom RabbitMQ Server versions prior to 3.13.15
Broadcom RabbitMQ Server 4.0.x prior to 4.0.20 and 4.1.x prior to 4.1.11
Broadcom RabbitMQ Server 4.2.x prior to 4.2.6

Discovery Timeline

2026-07-10 - CVE-2026-57216 published to NVD
2026-07-13 - Last updated in NVD database

Technical Details for CVE-2026-57216

Vulnerability Analysis

RabbitMQ enforces a loopback-only restriction for certain accounts, most notably the default guest user, to prevent remote authentication with well-known credentials. The check is performed inside the connection reader modules rabbit_reader.erl and rabbit_amqp_reader.erl, which historically resolved the client address from the listener socket via sockname/1. When RabbitMQ sits behind a load balancer or proxy that speaks the PROXY protocol and the backend listener is bound to 127.0.0.1, the socket-derived address always resolves to a loopback value even though the real client is remote. Authentication for guest therefore succeeds from any network endpoint that can reach the trusted PROXY-protocol path.

Root Cause

The loopback determination used the listener-side socket address rather than the parsed PROXY-protocol peer address. Once a connection is accepted on a loopback-bound listener, sockname/1 returns a loopback address regardless of the true origin. This causes rabbit_access_control:check_user_loopback/2 to incorrectly classify remote sessions as local.

Attack Vector

An attacker who can send AMQP 0-9-1, AMQP 1.0, or Stream Protocol traffic through a PROXY-protocol-fronted ingress to a loopback-bound RabbitMQ listener authenticates as guest with the default password. This yields message publish and consume rights and, depending on permissions, virtual host administration. Exploitation requires no user interaction and no prior privileges.

text

// Patch: use peername/1 instead of sockname/1 for loopback checks
 vhost(_) ->
     application:get_env(rabbit, default_vhost, <<"/">>).

-check_user_loopback(#v1{connection = #v1_connection{user = #user{username = Username}},
-                        sock = Socket} = State) ->
-    case rabbit_access_control:check_user_loopback(Username, Socket) of
+check_user_loopback(#v1{connection = #v1_connection{user = #user{username = Username},
+                                                    peer_host = PeerHost}} = State) ->
+    case rabbit_access_control:check_user_loopback(Username, PeerHost) of
         ok ->
             ok;
         not_allowed ->

Source: rabbitmq-server commit 7273c9e

Detection Methods for CVE-2026-57216

Indicators of Compromise

Successful authentication events for the guest user originating from connections that traversed a PROXY-protocol listener.
Connection log entries in rabbit_reader showing a remote RemoteAddress while the loopback check succeeded.
Unexpected creation of exchanges, queues, bindings, or users by the guest principal.

Detection Strategies

Query broker logs and audit events for authentications by loopback-restricted accounts on listeners fronted by PROXY-protocol proxies.
Correlate RabbitMQ connection metadata with upstream proxy access logs to identify remote peers that reached AMQP or Stream endpoints.
Alert on any use of default credentials such as guest/guest in production environments.

Monitoring Recommendations

Ingest RabbitMQ authentication, connection, and management logs into Singularity Data Lake using OCSF normalization for cross-source correlation.
Build detections that flag guest account activity from non-loopback peer IPs surfaced by PROXY-protocol parsing.
Monitor broker administrative changes and unusual message flow patterns that follow anomalous authentication events.

How to Mitigate CVE-2026-57216

Immediate Actions Required

Upgrade RabbitMQ to 3.13.15, 4.0.20, 4.1.11, or 4.2.6 or later, matching your deployed branch.
Rotate or disable the default guest user and any other loopback-restricted accounts, and set a strong password if the account must remain.
Audit RabbitMQ listener bindings and remove unnecessary PROXY-protocol trust from loopback-bound endpoints.

Patch Information

Broadcom fixed the issue in RabbitMQ Server 3.13.15, 4.0.20, 4.1.11, and 4.2.6. The corrective change is tracked in GitHub Security Advisory GHSA-36m6-588r-vqcw and applied via pull request #15936 and pull request #15940. The patch replaces the listener-side sockname/1 lookup with the PROXY-protocol-aware peer_host value when performing the loopback check.

Workarounds

Delete the guest user or restrict it with a non-default password and no permissions on production virtual hosts.
Bind AMQP and Stream listeners to specific interfaces and disable PROXY-protocol acceptance on loopback listeners until patched.
Enforce network segmentation so that only trusted proxies and application clients can reach broker ports.

bash

# Remove the default guest account on an unpatched broker
rabbitmqctl delete_user guest

# Or restrict guest to loopback with a strong password and no vhost access
rabbitmqctl change_password guest "$(openssl rand -base64 32)"
rabbitmqctl clear_permissions -p / guest

# Verify installed version meets the fixed release
rabbitmqctl version