CVE-2026-67411 is a high severity (CVSS 7.1) authorization flaw in RabbitMQ MQTT. Behind a trusted PROXY protocol frontend, the broker can lose the real client address and treat the frontend as loopback, bypassing loopback_users. Fixed in 3.13.18, 4.0.23, 4.1.14, 4.2.9 and 4.3.3.
What's affected
The record says RabbitMQ from 3.13.0 until 3.13.18, 4.0.23, 4.1.14, 4.2.9 and 4.3.3 is affected, and lists those as the fixed versions. I could not retrieve a dedicated advisory page. The 4.2.9 release notes list an MQTT entry about more correct peer host detection when Proxy Protocol is enabled, which fits the description, but they do not name the CVE, so confirm against the project's advisory.
The scenario is specific: native MQTT or MQTT over WebSocket, behind a trusted PROXY protocol frontend, and a loopback restricted account such as the default guest user.
The record is clear that password authentication is not bypassed. The attacker needs valid credentials for the restricted account. What fails is the source address restriction on top of them.
How to check if you're exposed
rabbitmqctl version
rabbitmq-diagnostics server_version
Run these on each node. In containers, run them with docker exec or kubectl exec against the broker pod, and also check the image tag you deploy. Mixed version clusters during a rolling upgrade are common, so check every node, not just one.
Then check the two settings involved. Look for the PROXY protocol listener options for MQTT and for loopback_users:
grep -rn "proxy_protocol\|loopback_users" /etc/rabbitmq/
If proxy protocol is off for MQTT, or no account depends on loopback_users, the described scenario does not apply. If both are present, treat the broker as in scope and upgrade.
A quicker route for a whole project is the free in-browser dependency scan at Gold. Paste a manifest or lockfile and it matches each dependency against known CVEs, including ones pulled in indirectly.
What to do now
- Upgrade to 3.13.18, 4.0.23, 4.1.14, 4.2.9 or 4.3.3 or later on your line.
- Do not rely on loopback_users as your only control. Remove or change the default guest credentials on any broker that is reachable through a frontend.
- Create named accounts with strong passwords and give each only the permissions it needs.
- Keep the PROXY protocol trust limited to your own load balancer addresses.
- Review connection logs for the restricted account connecting from unexpected places.
Reachability analysis helps with ordering the work. Knowing whether your code actually calls the affected path tells you which services to patch first.
Why it matters
The class is CWE-863, incorrect authorization. The loopback rule only works if the broker knows the real peer address. When the proxy supplied address was dropped before the check, the broker saw its own frontend and the connection looked local.
This is a common failure when a service moves behind a load balancer. Controls that depend on a source address are quietly weakened by the proxy unless the address is carried through every code path. The record does not mark this CVE as known exploited.
Quick check
Does this let someone log in without a password?
No. The record says it does not bypass password authentication, only the source address restriction for a loopback restricted account.
Do I need a PROXY protocol frontend to be affected?
The record describes the issue only in that setup, with MQTT or MQTT over WebSocket.
Sources
- https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.2.9
- Record: NVD entry for CVE-2026-67411 (score 7.1, HIGH)
Last reviewed: 18 October 2026.
