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.

A heap buffer overflow exists in 389 Directory Server's audit log password masking feature. The createmaskedentrystring() function (auditlog.c:109) uses strcpy to write a fixed 24-byte mask string into a precisely-sized heap buffer from slapientry2str(). When a password value is shorter than 23 characters, the copy overflows past the allocated buffer boundary.

Trigger conditions require non-default configuration: audit logging enabled AND either passwordStorageScheme=CLEAR (explicitly discouraged) or a compromised replication peer sending short cleartext passwords via replicated ADD (replop bypasses password hashing).

Introduced by commit bfeaa8d (Issue 6884, July 2025) and backported to RHEL 9.6 (RHEL-109954) and RHEL 10 (RHEL-107035). Not present in RHEL 7, RHEL 8, or RHEL 9.0-9.5.

Production testing: heap corruption confirmed in audit log output on live server; ASan PoC confirms overflow. Production binaries may absorb overflow in allocator padding without immediate crash.

Advisory: 389-ds-campaign-2026-04/006-Auditlog-Heap-Overflow/advisory.md. Source: PSIRTSUPT-7600 (Ian Murphy, Red Hat Product Security).

Ludwig Krispenz from Red Hat reported that there is a configuration switch to prevent writing unhashed passwords into the changelogs. Unfortunately if the switch is turned on the attribute unhashed#user#password is not written to the changelog, but the hashing of the attribute value itself is also bypassed.

Versions affected are 389 versions 1.3.1 and later, this means RHEL7.0 and later and Fedora20 and later.

The severity seems to be limited, since: - the option is not widely known and advertised and only available in a recent version - the access to the userpassword attribute is usually protected by acis not to be readable

Statement:

This issue did not affect the versions of 389-ds-base as shipped with Red Hat Enterprise Linux 6.

It was found that the 389 Directory Server did not properly restrict access to entries when the 'nsslapd-allow-anonymous-access' configuration setting is set to 'rootdse'. An anonymous user could connect to the LDAP database and, if the search scope is set to BASE, obtain access to information outside of the rootDSE. The 'rootdse' option exists to provide anonymous access to the rootDSE but no other entries in the directory. An administrator could believe that directory entries are being restricted with this option enabled, however the information provided would be the same as if 'nsslapd-allow-anonymous-access' were set to 'on'.

ACI's are still properly evaluated despite this flaw, so this can easily be mitigated by removing the anonymous read ACL.

The acllashandlegroupentry function in servers/plugins/acl/acllas.c in 389 Directory Server before 1.2.10 does not properly handled access control instructions (ACIs) that use certificate groups, which allows remote authenticated LDAP users with a certificate group to cause a denial of service (infinite loop and CPU consumption) by binding to the server.

389 Directory Server before 1.2.7.1 (aka Red Hat Directory Server 8.2) and HP-UX Directory Server before B.08.10.03, when audit logging is enabled, logs the Directory Manager password (nsslapd-rootpw) in cleartext when changing cn=config:nsslapd-rootpw, which might allow local users to obtain sensitive information by reading the log.

It was discovered that Red Hat Directory Server and Fedora Directory Server is prone to a temporary denial of service attack (high CPU usage) via crafted LDAP search patterns. LDAP search patterns are internally translated to regular expressions. If the regular expression is matched against specially crafted record already stored in the LDAP, it may cause regular expression NFA to iterate over large amount of states, causing one slapd thread to occupy CPU for excessive amount of time.

Additionally, due to a current design of the regular expression handling code, only one slapd thread can execute regular expression NFA code at the time. Because of that, during the processing of such CPU intensive search request, all other search requests using patterns are blocked.

Affected version: Red Hat Directory Server 7.1 and 8 Fedora Directory Server 1.1.1