CVE-2026-76560: 389-ds-base: 389-ds: anonymous ldap client can defeat selfdn aci bind-rule checks via empty bind dn
389 Directory Server's SELFDN ACI bind-rule evaluator (ldap/servers/plugins/acl/acllas.c) compares a client's bind DN against a stored attribute value using a plain string comparison. An anonymous LDAP bind has an empty-string client DN, and 389-ds's own DN syntax validator (ldap/servers/plugins/syntaxes/dn.c) accepts zero-length attribute values as valid. As a result, any ACI written as userattr="X#SELFDN", where attribute X can legitimately hold an empty value, is satisfied by an anonymous client with no authentication of any kind.
This was originally reported (PSIRTSUPT-21812) as part of a FreeIPA-specific admin-takeover chain, but independently reproduced standalone against plain 389-ds-base (389-ds-base-3.2.2-2.fc44) with zero FreeIPA schema, plugins, or ACIs present: a minimal test ACI (allow (add) userattr = "owner#SELFDN") was defeated by an anonymous bind with owner: set to an empty value, while a control case (non-empty, non-matching value) was correctly refused. This confirms the defect is general to the ACI evaluation engine, not specific to any consuming application.
Any 389-ds/RHDS deployment that defines a SELFDN-based ACI on an attribute permitted to hold an empty value is affected. Reported and confirmed as part of the PSIRTSUPT-21812 investigation; see linked Jira ticket for full technical writeup and reproduction evidence.
Other sources
A flaw was found in 389 Directory Server. The SELFDN ACI bind-rule evaluator incorrectly matches an anonymous LDAP client's empty bind DN against an empty stored attribute value, allowing an unauthenticated client to satisfy access control checks intended to require a matching authenticated identity. This can allow an anonymous LDAP client to perform an operation, such as adding or modifying a directory entry, that a SELFDN-based ACI intended to restrict to a specific authenticated user.
— MITRE
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed?
Deployments are exposed if they use a SELFDN-based ACI such as userattr="X#SELFDN" and the referenced attribute can legitimately contain an empty value. The issue affects the 389-ds/RHDS ACI evaluation engine and is not limited to FreeIPA-based deployments.
What does an attacker need to exploit this?
An attacker only needs network access to LDAP and the ability to perform an anonymous bind. No authentication or user interaction is required when a relevant SELFDN ACI references an attribute holding an empty value.
How can administrators identify potentially affected access controls?
Review ACIs for SELFDN user-attribute bind rules, including patterns of the form userattr="X#SELFDN". For each referenced attribute, determine whether empty values are permitted and whether entries protected by that ACI contain an empty value.