CVE-2026-67223: RabbitMQ: LDAP DN injection via unescaped substitution
RabbitMQ is a messaging and streaming broker. The advisory establishes affected 3.13, 4.0, 4.1, 4.2, and 4.3 maintenance lines but contains conflicting first-fixed versions for the 3.13, 4.0, and 4.1 lines. fill/2 substitutes ${username} into userdnpattern without RFC 4514 DN escaping, allowing a crafted username to alter the LDAP bind DN and potentially select a different directory entry. Exploitation requires rabbitmqauthbackendldap with a userdnpattern containing ${username}, a directory layout in which the injected suffix resolves usefully, and a password valid for the resulting DN. The advisory body identifies 3.13.15, 4.0.20, 4.1.11, 4.2.9, and 4.3.3 as fixed, while structured metadata identifies 3.13.18, 4.0.23, 4.1.14, 4.2.9, and 4.3.3. No fixed-version assertion is certifiable until a curator resolves this conflict.
Other sources
RabbitMQ: LDAP DN injection via unescaped substitution
— Microsoft
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.13.7-10
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Exposure requires RabbitMQ to use rabbitmq_auth_backend_ldap and to configure user_dn_pattern with the ${username} placeholder. Deployments without that LDAP authentication configuration are not described as affected.
What must an attacker have to exploit it?
The attacker needs a crafted username that changes the resulting LDAP bind DN, a directory layout where the injected suffix resolves to a useful entry, and a valid password for that resulting DN. The issue does not by itself bypass password validation.
How can I assess whether our LDAP configuration is at risk?
Inspect the RabbitMQ LDAP authentication configuration for user_dn_pattern values containing ${username}. Then determine whether special DN characters in a supplied username could alter the intended bind DN into another resolvable directory entry.
Can a fixed version be selected confidently from the advisory?
No. The advisory body and structured metadata disagree for the 3.13, 4.0, and 4.1 maintenance lines; only 4.2.9 and 4.3.3 are consistent between both sources. The version conflict must be resolved before asserting a fixed version for the other lines.