CVE-2026-67411: RabbitMQ MQTT Authentication Bypass Flaw

CVE-2026-67411 Overview

CVE-2026-67411 is an authorization bypass vulnerability in RabbitMQ's native MQTT and MQTT-over-WebSocket connection paths when deployed behind a trusted PROXY Protocol frontend. The broker loses the proxy-derived client address before the MQTT authentication path evaluates the loopback_users restriction. As a result, the frontend-to-broker connection address is treated as loopback, allowing an authenticated attacker with valid credentials for a loopback-restricted account to bypass the source-address restriction. The flaw is tracked as CWE-863: Incorrect Authorization. It does not bypass password authentication. Affected releases span RabbitMQ 3.13.0 through the patched versions 3.13.18, 4.0.23, 4.1.14, 4.2.9, and 4.3.3.

Critical Impact

An attacker who can reach the trusted PROXY Protocol frontend and holds valid credentials for a loopback-restricted RabbitMQ account can bypass the source-address restriction and authenticate against the broker as if connecting locally.

Affected Products

• RabbitMQ Server 3.13.0 through 3.13.17
• RabbitMQ Server 4.0.x through 4.0.22, 4.1.x through 4.1.13, 4.2.x through 4.2.8
• RabbitMQ Server 4.3.x through 4.3.2 (native MQTT and MQTT over WebSocket)

Discovery Timeline

• 2026-09-25 - CVE-2026-67411 published to NVD
• 2026-09-28 - Last updated in NVD database

Technical Details for CVE-2026-67411

Vulnerability Analysis

RabbitMQ supports deployments where a trusted frontend terminates TCP or TLS and forwards connections to the broker using the PROXY Protocol. The protocol preserves the original client address so backend services can enforce access controls based on the real source. RabbitMQ exposes a loopback_users configuration that restricts selected accounts (historically the default guest user) to connections originating from 127.0.0.1 or ::1.

In the affected versions, the native MQTT and Web MQTT readers passed the raw backend socket into rabbit_mqtt_processor:init/4 rather than the proxy-aware socket wrapper. When the processor later resolved the connection endpoints to apply authorization checks, it observed the frontend-to-broker address — commonly a loopback or internal address — instead of the real client address carried in the PROXY Protocol header. The loopback_users check therefore evaluated the wrong peer and granted access that should have been denied.

Root Cause

The root cause is an incorrect socket reference inside the MQTT connection initialization path. The reader held a proxy_socket in its state when PROXY Protocol was active, but it invoked rabbit_mqtt_processor:init/4 with the plain socket, discarding the proxy-derived peer information before authorization decisions were made.

Attack Vector

Exploitation requires three preconditions: network reachability to the trusted PROXY Protocol frontend, valid credentials for an account restricted by loopback_users, and MQTT or MQTT-over-WebSocket enabled on the broker. The attacker connects through the frontend, completes the MQTT CONNECT handshake with legitimate credentials, and the broker treats the session as loopback-originated. Password authentication is still enforced.

%% Patched reader logic — deps/rabbitmq_mqtt/src/rabbit_mqtt_reader.erl
%% Pass the proxy-aware socket so the processor resolves the ends from it
InitSocket = case State#state.proxy_socket of
                 undefined -> Socket;
                 ProxySocket -> ProxySocket
             end,
try rabbit_mqtt_processor:init(Packet, InitSocket, ConnName, SendFun) of
    {ok, ProcState1} ->
        ?LOG_INFO("Accepted MQTT connection ~ts for client ID ~ts",
                  [ConnName, rabbit_mqtt_processor:info(client_id, ProcState1)]),

Source: RabbitMQ commit a7528314840c

The companion processor change updates the init/4 type signature to accept either a raw socket or a proxy socket so endpoint resolution uses the correct peer:

-spec init(ConnectPacket :: mqtt_packet(),
-          RawSocket :: rabbit_net:socket(),
+          Socket :: rabbit_net:socket() | rabbit_net:proxy_socket(),
           ConnectionName :: binary(),
           SendFun :: send_fun()) ->
    {ok, state()} | {error, {socket_ends, any()} | reason_code()}.

Source: RabbitMQ commit edbead0eabbd

Detection Methods for CVE-2026-67411

Indicators of Compromise

• MQTT or Web MQTT CONNECT events for loopback-restricted accounts (such as guest) succeeding on connections that transited the PROXY Protocol frontend.
• RabbitMQ connection logs showing accepted MQTT sessions whose broker-side peer address is a loopback or internal frontend address while the account should be loopback-only.
• Unexpected MQTT client IDs or publish/subscribe activity on topics associated with privileged default accounts.

Detection Strategies

• Correlate RabbitMQ ?LOG_INFO("Accepted MQTT connection ...") entries with frontend PROXY Protocol logs to identify MQTT sessions where the real client address differs from the broker-observed peer.
• Alert on any successful MQTT authentication by accounts enumerated in the loopback_users setting when the ingress path includes a non-loopback frontend.
• Compare RabbitMQ server versions across the fleet against the fixed releases (3.13.18, 4.0.23, 4.1.14, 4.2.9, 4.3.3) to surface exposed brokers.

Monitoring Recommendations

• Forward RabbitMQ connection and authentication logs to a central analytics tier and retain PROXY Protocol metadata from the frontend for correlation.
• Monitor credential-use anomalies for loopback-restricted accounts, including first-seen source addresses and off-hours activity.
• Track configuration drift on the loopback_users list and on which listeners have proxy_protocol enabled.

How to Mitigate CVE-2026-67411

Immediate Actions Required

• Upgrade RabbitMQ to 3.13.18, 4.0.23, 4.1.14, 4.2.9, or 4.3.3 depending on the deployed branch.
• Rotate credentials for any account listed in loopback_users, including the default guest account if still enabled.
• Audit MQTT and Web MQTT listener configuration to confirm whether PROXY Protocol is enabled and which upstream frontends are considered trusted.

Patch Information

The fix is delivered in RabbitMQ releases v4.2.9 and v4.3.3, with equivalent backports in 3.13.18, 4.0.23, and 4.1.14. See the RabbitMQ Security Advisory GHSA-4r6f-9cpw-f6g6 for the complete fix matrix. The patch forwards the proxy_socket wrapper into rabbit_mqtt_processor:init/4 so endpoint resolution and the loopback_users check evaluate the real client address.

Workarounds

• Remove sensitive or administrative accounts from loopback_users and instead restrict them via explicit virtual host permissions, firewall rules, or mTLS at the frontend.
• Disable the native MQTT and Web MQTT plugins on brokers that do not require them until the upgrade is deployed.
• Terminate MQTT clients at a frontend that enforces source-address allowlists and strong authentication before forwarding to RabbitMQ.

# Verify installed RabbitMQ version and listener configuration
rabbitmqctl version
rabbitmq-diagnostics listeners

# Inspect loopback_users setting
rabbitmqctl environment | grep -A1 loopback_users

# Example: remove the default guest user from loopback_users enforcement by deleting it
rabbitmqctl delete_user guest