Summary
RabbitMQ can incorrectly treat a client connected through a trusted PROXY Protocol frontend as originating from loopback during MQTT authentication. An attacker who can reach that frontend and has valid credentials for an account restricted to loopback clients may bypass the source-address restriction, although password authentication is still required.
RabbitMQ can incorrectly treat a client connected through a trusted PROXY Protocol frontend as originating from loopback during MQTT authentication. An attacker who can reach that frontend and has valid credentials for an account restricted to loopback clients may bypass the source-address restriction, although password authentication is still required.
Affected context
The issue occurs in RabbitMQ deployments using native MQTT or MQTT over WebSocket behind a trusted PROXY Protocol frontend. Under affected conditions, the proxy-derived client address may be lost before the authentication path evaluates loopback restrictions, causing the frontend connection to be interpreted as originating from loopback. The risk depends on exposure of the trusted frontend and the presence of credentials for an account subject to loopback-only access controls.
The issue occurs in RabbitMQ deployments using native MQTT or MQTT over WebSocket behind a trusted PROXY Protocol frontend. Under affected conditions, the proxy-derived client address may be lost before the authentication path evaluates loopback restrictions, causing the frontend connection to be interpreted as originating from loopback. The risk depends on exposure of the trusted frontend and the presence of credentials for an account subject to loopback-only access controls.
Exploit preconditions
- Attack surface: Native MQTT or MQTT over WebSocket exposed through a trusted PROXY Protocol frontend
- Required access: Network access to the trusted frontend and valid credentials for a loopback-restricted account
- Trigger point: MQTT authentication while RabbitMQ evaluates the account's source-address restriction
- Why exploitation is possible: Loss of proxy-derived address information can cause the connection to be treated as loopback, bypassing the intended authorization check
- Attack surface: Native MQTT or MQTT over WebSocket exposed through a trusted PROXY Protocol frontend
- Required access: Network access to the trusted frontend and valid credentials for a loopback-restricted account
- Trigger point: MQTT authentication while RabbitMQ evaluates the account's source-address restriction
- Why exploitation is possible: Loss of proxy-derived address information can cause the connection to be treated as loopback, bypassing the intended authorization check
Why this happens
The underlying bug is an authorization-context integrity failure. RabbitMQ loses or fails to preserve the client address supplied by the trusted proxy before applying the loopback_users restriction. As a result, an address-based authorization decision is made using an incorrect security context. This maps to CWE-863, which covers incorrect authorization of authenticated users.
The underlying bug is an authorization-context integrity failure. RabbitMQ loses or fails to preserve the client address supplied by the trusted proxy before applying the loopback_users restriction. As a result, an address-based authorization decision is made using an incorrect security context. This maps to CWE-863, which covers incorrect authorization of authenticated users.
Potential impact
- An authenticated attacker may access a loopback-restricted RabbitMQ account through the trusted frontend.
- The attacker could perform actions available to that account.
- Message, queue, or streaming resources may be accessed or modified according to the account's permissions.
- Monitoring and isolation assumptions based on source-address restrictions could be weakened.
- An authenticated attacker may access a loopback-restricted RabbitMQ account through the trusted frontend.
- The attacker could perform actions available to that account.
- Message, queue, or streaming resources may be accessed or modified according to the account's permissions.
- Monitoring and isolation assumptions based on source-address restrictions could be weakened.
General mitigation guidance
Mitigation focuses on preserving trustworthy client-address information across
proxy and authentication boundaries and avoiding authorization decisions based
on ambiguous connection metadata.
Common defensive patterns include:
- Ensuring PROXY Protocol is accepted only from explicitly trusted frontend systems.
- Preserving and validating proxy-derived client addresses before source-based authorization is evaluated.
- Using secure-by-default authentication and authorization policies that do not rely solely on loopback restrictions.
- Limiting account permissions through least privilege and separating administrative identities from application credentials.
- Restricting network access to MQTT and WebSocket listeners with segmentation and firewall policy.
- Avoiding shared credentials and rotating credentials when exposure of a restricted account is suspected.
Mitigation focuses on preserving trustworthy client-address information across
proxy and authentication boundaries and avoiding authorization decisions based
on ambiguous connection metadata.
Common defensive patterns include:
- Ensuring PROXY Protocol is accepted only from explicitly trusted frontend systems.
- Preserving and validating proxy-derived client addresses before source-based authorization is evaluated.
- Using secure-by-default authentication and authorization policies that do not rely solely on loopback restrictions.
- Limiting account permissions through least privilege and separating administrative identities from application credentials.
- Restricting network access to MQTT and WebSocket listeners with segmentation and firewall policy.
- Avoiding shared credentials and rotating credentials when exposure of a restricted account is suspected.
How teams detect issues like this
Organizations can look for this class of issue through:
- Integration tests covering MQTT authentication through trusted PROXY Protocol frontends.
- Assertions that the client address used for authorization matches the validated proxy-derived address.
- Code review checks for address metadata being discarded, overwritten, or defaulted before authorization.
- Configuration reviews confirming that PROXY Protocol trust is narrowly scoped to known frontend networks.
- Logs correlating frontend connection addresses, proxy-reported addresses, authentication events, and access to loopback-restricted accounts.
- Policy enforcement that flags broad listener exposure, excessive account permissions, or source-based controls without complementary authorization.
Organizations can look for this class of issue through:
- Integration tests covering MQTT authentication through trusted PROXY Protocol frontends.
- Assertions that the client address used for authorization matches the validated proxy-derived address.
- Code review checks for address metadata being discarded, overwritten, or defaulted before authorization.
- Configuration reviews confirming that PROXY Protocol trust is narrowly scoped to known frontend networks.
- Logs correlating frontend connection addresses, proxy-reported addresses, authentication events, and access to loopback-restricted accounts.
- Policy enforcement that flags broad listener exposure, excessive account permissions, or source-based controls without complementary authorization.
