GHSA-4r6f-9cpw-f6g6

Описание

Advisory Details

Title: (Web) MQTT PROXY Protocol path bypasses loopback-only user restriction

Description:

RabbitMQ (Web) MQTT loses the PROXY Protocol-derived client address before the MQTT authentication path checks loopback_users. A remote client with valid credentials for a loopback-restricted account can therefore authenticate through a trusted PROXY Protocol frontend because the backend evaluates the frontend's 127.0.0.1 address instead of the original client address.

Workarounds

One or multiple of:

• Override default user's username, use a generated password (a recommended practice)
• Adopt OAuth 2 or x.509 certificates for authentication instead of username/password pairs
• Disable Proxy Protocol use
• Disable the Web MQTT, MQTT plugins

Summary

When rabbitmq_web_mqtt runs behind a trusted TCP frontend with web_mqtt.proxy_protocol = true, Cowboy preserves the original client address in a rabbit_proxy_socket. rabbit_web_mqtt_handler uses that wrapper for connection logging, but unwraps it before invoking rabbit_mqtt_processor:init/4. The processor then derives PeerIp from the raw frontend-to-backend socket and passes 127.0.0.1 to the loopback-user check.

This bypasses the intended restriction for users such as the default guest account. The issue requires a reachable trusted frontend and valid credentials for a loopback-only account; it does not require modifying RabbitMQ configuration, directly reaching the loopback-bound backend, or forging a PROXY header.

Details

The Web MQTT handler receives a proxy-aware socket after Cowboy parses the PROXY header. The helper rabbit_net:socket_ends/2 explicitly returns src_address and src_port from that wrapper:

However, the first MQTT CONNECT is initialized with the raw socket:

unwrap_socket/1 discards the proxy metadata. rabbit_mqtt_processor:init/4 calls rabbit_net:socket_ends(Socket, inbound), then passes the resulting PeerIp into check_user_loopback/2. In a trusted-front-end deployment, that raw socket peer is the local frontend, typically 127.0.0.1.

The result is an authorization-context mismatch:

1. Connection logging reports the real client address from the proxy-aware socket
2. Loopback authorization evaluates the frontend address from the unwrapped socket
3. A non-loopback client with valid guest credentials receives a successful MQTT CONNACK

The direct non-PROXY control confirms that the loopback check itself works: the same credentials and MQTT CONNECT from a non-loopback client receive 20 02 00 05 and the broker logs that guest can only connect via localhost.

PoC

Prerequisites

• RabbitMQ Server version v4.3.2, or another affected version in the range below
• Docker with host networking available for the isolated test environment
• rabbitmq_mqtt and rabbitmq_web_mqtt enabled
• A trusted TCP frontend that owns PROXY header generation
• A Web MQTT backend configured with web_mqtt.proxy_protocol = true
• A valid loopback-restricted account, such as the default guest / guest in a fresh isolated broker

Download these secret Gists into the same exploit directory, preserving the filenames:

Reproduction Steps

1. Check out RabbitMQ Server v4.3.2 and place the downloaded files in llm-enhance/cve-finding/Auth_Bypass/CVE-2026-57216-web-mqtt-exp/

2. Start the isolated primary broker, trusted frontend, and direct control broker:

   sh llm-enhance/cve-finding/Auth_Bypass/CVE-2026-57216-web-mqtt-exp/start_isolated_broker.sh

3. Identify a non-loopback host address and run the Web MQTT verification through the trusted frontend:

   HOST_IP=$(hostname -I | awk '{print $1}') docker run --rm --network bridge -v "$PWD:/workspace" -w /workspace \ -e WEB_MQTT_HOST="$HOST_IP" -e WEB_MQTT_PORT=15686 \ rabbitmq-cve-2026-57216-test \ python3 llm-enhance/cve-finding/Auth_Bypass/CVE-2026-57216-web-mqtt-exp/verification_test_CVE-2026-57216-web-mqtt.py

4. Run the same WebSocket MQTT CONNECT against the direct, non-PROXY control listener:

   docker run --rm --network bridge -v "$PWD:/workspace" -w /workspace \ -e WEB_MQTT_HOST="$HOST_IP" -e WEB_MQTT_PORT=15687 \ rabbitmq-cve-2026-57216-test \ python3 llm-enhance/cve-finding/Auth_Bypass/CVE-2026-57216-web-mqtt-exp/control-direct-nonloopback.py

5. The proxy path should incorrectly return a successful MQTT 3.1.1 CONNACK. The control should return the not-authorized CONNACK.

Log of Evidence

The verification run against the trusted frontend returned:

The frontend and primary broker independently recorded the non-loopback client:

The direct non-PROXY control returned and logged the protected behavior:

Impact

This is an authorization bypass of the loopback-user restriction. A remote attacker who knows valid credentials for a loopback-restricted account can establish a (Web) MQTT session through an affected trusted-PROXY deployment.

The attacker receives the affected account's MQTT-accessible vhost and resource permissions. In a fresh default broker, guest has broad permissions on the default vhost, so the impact can include publishing forged messages, consuming accessible messages, and triggering downstream services that trust those message flows. This does not itself bypass passwords or grant access to separately exposed management HTTP endpoints; those interfaces retain their own listener and authorization checks.

Note that this affects MQTT and MQTT over WebSocket.

Affected products

• Ecosystem: RabbitMQ Server / Erlang
• Package name: rabbitmq-server
• Affected versions: >= 3.13.0, <= 4.3.2
• Patched versions:

Severity

• Severity: Medium
• Vector string: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L

Weaknesses

• CWE: CWE-863: Incorrect Authorization

Occurrences