CVE-2026-67411: RabbitMQ: Web MQTT with PROXY Protocol enabled: a loopback-only user permission bypass
RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.18, 4.0.23, 4.1.14, 4.2.9, and 4.3.3, native MQTT and MQTT over WebSocket behind a trusted PROXY Protocol frontend could lose the proxy-derived client address before the MQTT authentication path checked loopbackusers, causing the frontend-to-broker address to be treated as loopback. An attacker who can reach the trusted frontend and has valid credentials for a loopback-restricted account can therefore bypass the source-address restriction; the issue does not bypass password authentication. This issue is fixed in versions 3.13.18, 4.0.23, 4.1.14, 4.2.9, and 4.3.3.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 3.13.18 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.0.23 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.1.14 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.2.9 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.3.3
Event History
Frequently Asked Questions
Which deployments are exposed to this bypass?
Affected deployments use native MQTT or MQTT over WebSocket behind a trusted frontend that sends PROXY Protocol information. The relevant RabbitMQ versions are 3.13.0 through 3.13.17 and versions before 4.0.23, 4.1.14, 4.2.9, or 4.3.3 in their respective release lines.
What must an attacker have to exploit the issue?
The attacker must be able to reach the trusted PROXY Protocol frontend and possess valid credentials for an account restricted to loopback access. Password authentication is still required and is not bypassed.
Does this affect a default RabbitMQ setup?
The issue requires a deployment using a trusted PROXY Protocol frontend for MQTT or MQTT over WebSocket, along with a loopback-restricted user account. Deployments without that configuration are not described as affected.
What can be done before upgrading?
Restrict access to the trusted frontend so untrusted clients cannot reach it, and avoid exposing or using loopback-restricted account credentials through MQTT paths behind that frontend. Upgrade to 3.13.18, 4.0.23, 4.1.14, 4.2.9, or 4.3.3 as applicable.