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.

A flaw was found in the SASL I/O layer of 389 Directory Server (389-ds-base). In sasliostartpacket(), the 4-byte wrapped-record length read from the wire is validated only against an upper bound (the check added for CVE-2026-11774). When a SASL-authenticated attacker sends a wrapped record with a wire length of 0 (or 1 or 2), the resulting encryptedbuffercount (4, 5, or 6 after adding sizeof(uint32t)) is less than encryptedbufferoffset (7, the header bytes already consumed). The unsigned subtraction in saslioreadpacket() then underflows to approximately 0xFFFFFFFD, and PRRecv is requested to read roughly 4 GiB into the 1024-byte encryptedbuffer allocated in saslioinitbuffers(). This causes a heap buffer overflow with attacker-controlled length and content. The vulnerability requires authentication via a SASL bind with integrity protection (SSF > 0). This is a distinct defect from CVE-2026-11774, which only guards against lengths near UINT32MAX; the lower-end case is not covered and the vulnerability persists at HEAD.

A flaw was found in the SASL I/O layer of 389 Directory Server (389-ds-base). In sasliostartpacket(), the 4-byte wrapped-record length read from the wire is validated only against an upper bound (the check added for CVE-2026-11774). When a SASL-authenticated attacker sends a wrapped record with a wire length of 0 (or 1 or 2), the resulting encryptedbuffercount (4, 5, or 6 after adding sizeof(uint32t)) is less than encryptedbufferoffset (7, the header bytes already consumed). The unsigned subtraction in saslioreadpacket() then underflows to approximately 0xFFFFFFFD, and PRRecv is requested to read roughly 4 GiB into the 1024-byte encryptedbuffer allocated in saslioinitbuffers(). This causes a heap buffer overflow with attacker-controlled length and content. The vulnerability requires authentication via a SASL bind with integrity protection (SSF > 0). This is a distinct defect from CVE-2026-11774, which only guards against lengths near UINT32MAX; the lower-end case is not covered and the vulnerability persists at HEAD.

A flaw was found in 389 Directory Server. The opsharedsearch function in opshared.c does not check for a NULL backend pointer when reusing a paged-results slot in the bename (USEONEBACKEND control) code path. An unauthenticated client can exploit this by sending two SEARCH requests on the same connection: the first names a non-existent backend via the USEONEBACKEND control with a Simple Paged Results (SPR) empty cookie, storing NULL as the backend in a paged-results slot; the second names a valid backend with an SPR cookie referencing that slot, causing the server to retrieve the stored NULL and call slapibeRlock(NULL), which dereferences the NULL pointer and crashes the ns-slapd process. This is reachable pre-authentication because control and paged-results processing runs before search authorization. Paged results and anonymous access are both enabled by default.

389-ds-base security assessment finding 021 (2026-04-22).

Pre-auth LDAP filter injection in CleanAllRUV status-check extop (OID 2.16.840.1.113730.3.6.8). Handler multisupplierextopcleanruvcheckstatus() in replextop.c passes attacker-supplied filter unsanitized to internal cn=config search with replication plugin identity. No auth checks (unlike other replication extops).

With default nsslapd-allow-anonymous-access: on, anonymous bind suffices. Boolean oracle extracts 31 cn=config attributes (replication bind DN, password storage scheme, paths, ACI keywords). Password hashes not extractable via substring.

PoC confirmed: RHEL 7 (389-ds-base-1.3.11.1-5.el79), Fedora 42 (389-ds-base-3.1.4-6.fc42).

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (7.5). Red Hat impact: Moderate. CWE-90, CWE-306, CWE-20.

A flaw was found in 389 Directory Server (389-ds-base). The getruvelementfromberval() function in ldap/servers/plugins/replication/repl5ruv.c copies digit characters from a network-supplied RUV berval into a fixed 16-byte stack buffer (ridbuff[RIDSTRSIZE]) without bounds checking the loop counter. A remote unauthenticated attacker can crash the ns-slapd process by sending a crafted StartNSDS50ReplicationRequest LDAP extended operation (OID 2.16.840.1.113730.3.5.12) containing more than 16 consecutive digit characters in the replica ID field. The overflow occurs during payload decoding in decodestartreplextop(), before the replicaisupdatedn() authorization check runs, making it exploitable without credentials on default configurations where anonymous access is enabled. On production builds with stack protectors, the impact is limited to denial of service (process abort). The vulnerable code path is: decodestartreplextop() -> decoderuv() -> ruvinitfrombervals() -> getruvelementfromberval().

A flaw was found in 389 Directory Server. The CleanAllRUV and Abort CleanAllRUV replication-maintenance extended operations perform no authorization check, allowing an unauthenticated remote attacker to invoke them when nsslapd-allow-anonymous-access is enabled (the default), or any authenticated low-privilege user to invoke them otherwise. This allows removal of a replica ID from replication metadata, purging of changelog records, and interruption of administrator-initiated cleanup, which can leave replication inconsistent or unavailable.

A flaw was found in 389 Directory Server (389-ds-base). In idssaslcheckbind(), on a successful SASLOK from the underlying Cyrus SASL library, the connection is marked SASL-complete and bind credentials are installed via bindcredentialssetnolock() before the account-lock check (slapicheckaccountlock()) is performed for non-root binds. If the subsequent lock check determines the account is locked (nsAccountLock: true), the bind is failed and reported to the client, but the already-installed SASL-complete flag and bind credentials are not reverted. A client that already knows the correct password for an account that has since been administratively locked can bind via SASL PLAIN, receive an "account locked" failure response, and continue using the same, already-authenticated TCP connection to perform further LDAP operations as that account -- defeating account lock as an access-revocation control. Setting nsslapd-close-on-failed-bind does not mitigate this. This finding was independently reported by two unrelated parties (OpenAI Security Research and Andrew Rukin of Arenadata) who converged on the identical root cause.

A heap-buffer-overflow flaw was found in 389 Directory Server (389-ds-base). When normalizing a Distinguished Name (DN) that contains a legacy-quoted value encoding a multivalued nested Relative Distinguished Name (RDN), the server can write past the end of a heap allocation while sorting RDN attribute-value pairs. An unauthenticated remote attacker can trigger this condition by sending an LDAP operation whose DN reaches the DN normalization routine, such as a search with a crafted base DN. This can corrupt heap memory and may cause denial of service.

A flaw was found in 389 Directory Server. The PBKDF2-SHA256 password verification function pbkdf2sha256pwcmp() in ldap/servers/plugins/pwdstorage/pbkdf2pwd.c uses standard memcmp() for hash comparison instead of the project's constant-time slapictmemcmp(). Every other password storage scheme in the same plugin uses slapictmemcmp(), which was introduced specifically to prevent timing side-channels (see CVE-2016-5405). This inconsistency allows a remote attacker with network access to the LDAP service to potentially infer partial hash information through repeated timing measurements of LDAP bind attempts. Practical exploitation is extremely difficult due to the PBKDF2 work factor (8192+ iterations, ~2ms computation time) which dominates and masks the nanosecond-level memcmp timing delta.

Valid heap-buffer-overflow in slapidnnormalizeext() -> sortrdnavs() -> rdnavswap() (ldap/servers/slapd/dn.c). Triggered when a DN contains a legacy-quoted value encoding a multivalued nested RDN. On closing quote, nested attribute-value tracking is not finalized; a subsequent separator can leave stale pointers that produce overlapping berval entries. In-place sorting then writes past the heap allocation in rdnavswap(). Reachable pre-auth via any LDAP operation whose DN is normalized (search base DN confirmed). Reproduced on RHEL 9.8 (389-ds-base-2.8.0-7.el98) with reporter PoC. Production behavior (no ASAN/MALLOCCHECK): malformed DN often returns err=34 (Invalid DN syntax); server continues. With MALLOCCHECK=3: general protection fault in libc, ns-slapd terminates.

mishandling of the filter that would yield incorrect results, but as that has progressed, we have determined that it actually is an access control bypass. This may allow any remote un-authenticated user to issue a filter that allows searching for database items they do not have access to, including but not limited to potentially userPassword hashes and other sensitive data.

https://github.com/389ds/389-ds-base/issues/5170