Origin

This vulnerability was identified by Team RabbitMQ and/or other teams at Broadcom, not via a responsible disclosure from an external researcher.

Source references

deps/rabbitmq_auth_backend_ldap/src/rabbit_auth_backend_ldap_util.erl:15 · LDAP Injection

Impact

When user_dn_pattern interpolates the username into a DN string (e.g. cn=${username},ou=users,dc=corp), special characters in the username (',', '=', '+', '<', '>', '#', ';', '\') are not escaped. The verifier refuted the original LDAP-filter-injection claim (eldap uses structured equalityMatch, not string filters), leaving only DN-suffix injection: a username like 'alice,ou=admins' shifts the bind DN into a different OU, potentially matching a different (more privileged) LDAP entry.

Description

fill/2 performs literal string substitution of ${username} without applying RFC 4514 DN escaping. The resulting DN is used for the LDAP simple-bind. eldap's search filters are built structurally so filter injection is not possible, but the bind DN itself is attacker-influenced.

Exploit scenario

user_dn_pattern = 'cn=${username},ou=restricted,dc=corp'. Attacker logs in with username 'victim,ou=privileged' and victim's password (or empty password if the ou=privileged entry permits anonymous bind). Bind DN becomes 'cn=victim,ou=privileged,ou=restricted,dc=corp' — depending on directory layout this may resolve to a different, more-privileged entry.

Preconditions

• rabbitmq_auth_backend_ldap enabled with user_dn_pattern containing ${username}
• Directory layout where DN-suffix injection resolves to a useful entry
• Attacker knows/guesses a password valid for the injected DN

CVSS

CVSS v4.0: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N (6.3, Moderate). Fixed in 3.13.15, 4.0.20, 4.1.11, 4.2.9, 4.3.3.