Summary
RabbitMQ contains an authorization bypass in MQTT topic permission expansion when a topic template places {clientid} inside a character class. Because the affected escaping logic does not handle the hyphen character, a low-privileged authenticated MQTT user who controls its client identifier may broaden permitted topic read or write access.
RabbitMQ contains an authorization bypass in MQTT topic permission expansion when a topic template places {clientid} inside a character class. Because the affected escaping logic does not handle the hyphen character, a low-privileged authenticated MQTT user who controls its client identifier may broaden permitted topic read or write access.
Affected context
The issue affects RabbitMQ deployments using MQTT topic permission templates that interpolate a client-controlled {clientid} value inside a regular-expression character class such as [...]. It is relevant when topic authorization relies on the expanded template and the resulting pattern is evaluated without correctly escaping hyphens.
The issue affects RabbitMQ deployments using MQTT topic permission templates that interpolate a client-controlled {clientid} value inside a regular-expression character class such as [...]. It is relevant when topic authorization relies on the expanded template and the resulting pattern is evaluated without correctly escaping hyphens.
Exploit preconditions
- Attack surface: MQTT topic authorization and permission-template expansion
- Required access: An authenticated, low-privileged MQTT account with control over its client identifier
- Trigger point: Evaluation of a topic permission template containing
{clientid}within a character class - Why exploitation is possible: The escaping routine protects several regular-expression metacharacters but omits
-, allowing the client-controlled value to alter the effective authorization pattern
- Attack surface: MQTT topic authorization and permission-template expansion
- Required access: An authenticated, low-privileged MQTT account with control over its client identifier
- Trigger point: Evaluation of a topic permission template containing
{clientid}within a character class - Why exploitation is possible: The escaping routine protects several regular-expression metacharacters but omits
-, allowing the client-controlled value to alter the effective authorization pattern
Why this happens
The underlying bug is incomplete neutralization of user-controlled data before it is embedded in a regular-expression-based authorization rule. A hyphen has special meaning inside a regular-expression character class, where it can define a character range. Omitting that character from the escaping routine allows a crafted client identifier to broaden the topics matched by the permission template. This behavior maps to CWE-862: Missing Authorization, because the resulting rule may grant access beyond the user's intended topic scope.
The underlying bug is incomplete neutralization of user-controlled data before it is embedded in a regular-expression-based authorization rule. A hyphen has special meaning inside a regular-expression character class, where it can define a character range. Omitting that character from the escaping routine allows a crafted client identifier to broaden the topics matched by the permission template. This behavior maps to CWE-862: Missing Authorization, because the resulting rule may grant access beyond the user's intended topic scope.
Potential impact
- An attacker may read MQTT topics outside the intended authorization scope
- An attacker may publish to topics they should not be able to write
- Sensitive messages or telemetry could be disclosed
- Unauthorized clients could alter application inputs or brokered commands
- Downstream systems may process tampered messages
- An attacker may read MQTT topics outside the intended authorization scope
- An attacker may publish to topics they should not be able to write
- Sensitive messages or telemetry could be disclosed
- Unauthorized clients could alter application inputs or brokered commands
- Downstream systems may process tampered messages
General mitigation guidance
Mitigation generally focuses on preventing client-controlled identifiers from changing authorization semantics.
Common defensive patterns include:
- Escape every regular-expression metacharacter, including hyphens in character classes, before interpolating values into permission patterns
- Prefer exact topic matching or structured authorization rules over dynamically assembled regular expressions
- Treat MQTT client identifiers as untrusted input regardless of authentication status
- Apply least-privilege topic permissions with separate, narrowly scoped read and write policies
- Validate permission templates and expanded rules against representative edge-case identifiers before deployment
- Avoid relying on client-controlled values for security boundaries where a server-assigned identifier is practical
Mitigation generally focuses on preventing client-controlled identifiers from changing authorization semantics.
Common defensive patterns include:
- Escape every regular-expression metacharacter, including hyphens in character classes, before interpolating values into permission patterns
- Prefer exact topic matching or structured authorization rules over dynamically assembled regular expressions
- Treat MQTT client identifiers as untrusted input regardless of authentication status
- Apply least-privilege topic permissions with separate, narrowly scoped read and write policies
- Validate permission templates and expanded rules against representative edge-case identifiers before deployment
- Avoid relying on client-controlled values for security boundaries where a server-assigned identifier is practical
How teams detect issues like this
Organizations can look for this class of issue through:
- Static analysis rules that identify regular-expression construction from client-controlled values
- Code review checks for incomplete escaping routines and special handling of characters inside
[...] - Tests using hyphens, backslashes, brackets, and other regular-expression boundary characters in client identifiers
- Authorization regression tests confirming that expanded MQTT permissions cannot match unintended topic names
- Policy enforcement requiring centralized, well-tested authorization libraries instead of ad hoc pattern construction
- Automated security review tools that flag dynamic regular-expression assembly and missing authorization checks
Organizations can look for this class of issue through:
- Static analysis rules that identify regular-expression construction from client-controlled values
- Code review checks for incomplete escaping routines and special handling of characters inside
[...] - Tests using hyphens, backslashes, brackets, and other regular-expression boundary characters in client identifiers
- Authorization regression tests confirming that expanded MQTT permissions cannot match unintended topic names
- Policy enforcement requiring centralized, well-tested authorization libraries instead of ad hoc pattern construction
- Automated security review tools that flag dynamic regular-expression assembly and missing authorization checks
