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.

The ldaputf8prev() function in 389 Directory Server unconditionally reads up to 6 bytes before a heap allocation because it lacks a lower-bound parameter. This API design flaw has existed since the Mozilla LDAP C SDK import and was symptomatically patched twice without fixing the root cause. Twenty call sites remain vulnerable to 1-6 byte heap over-reads.

Cannot be triggered via standard LDAP wire protocol (BER filters parsed separately), but internal callers processing attacker-influenced data (plugin configuration, ACI definitions, replication) are affected. ASan confirmed on aarch64; no crash on production binaries.

The SMD5 password storage plugin in 389 Directory Server computes salt length by subtracting MD5LENGTH (16) from the decoded hash length using unsigned 32-bit arithmetic. When the stored hash is shorter than 16 bytes, the subtraction wraps to approximately 4GB. PK11DigestOp() then reads from a small stack buffer into unmapped memory, crashing ns-slapd with SIGSEGV.

An attacker with Directory Manager privileges plants a crafted SMD5 hash; any subsequent BIND triggers instant crash. Missed variant of CVE-2024-5953 which patched md5pwd.c and pbkdf2pwd.c but not smd5pwd.c.

Present since smd5pwd.c creation (~2005). PoC confirmed on Fedora 42 production binary.

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).

Two heap buffer overflow vulnerabilities exist in 389 Directory Server schema serialization code. Both are incomplete-fix variants of CVE-2025-14905: the ocsuperior (SUP) field length is omitted from buffer size calculations in readschemadse() and schemaoctostring(), but the field is still written via strcat().

Variant 1 (readschemadse, schema.c:1765): triggered during schema DSE reads; overflow at SUP >= ~248 bytes. Variant 2 (schemaoctostring, schema.c:5151): triggered during schema replication comparison; overflow at SUP >= ~62 bytes.

An attacker with Directory Manager privileges can crash the server. In replication topologies, a compromised supplier can push malicious schema to consumers. RCE is not feasible on x8664 due to ASCII-only overflow content.

Parent CVE: CVE-2025-14905 (fixed schemaattrenumcallback only). Advisory: 389-ds-campaign-2026-04/001-002-Schema-Heap-Overflow/advisory.md. Source: PSIRTSUPT-7600 (Ian Murphy, Red Hat Product Security).

A vulnerability was found in the ds-389-base server, specifically in the schema.c file which was then verified as exploitable in the running server. There is a heap buffer overflow that can be exploited to execute a DoS and potential RCE. The vulnerability is possible through the function schemaattrenumcallback, the code calculates size by summing the lengths of alias strings but fails to account for the formatting characters added during printing. It relies on a static "magic number" of 256 to absorb this overhead. When the number of aliases is large enough, the cumulative overhead of 3 bytes per alias exceeds the 256-byte margin, leading to a heap overflow.

Moderate: redhat-ds:11 security and bug fix update

Moderate: redhat-ds:11 security and bug fix update

Important: redhat-ds:11 security and bug fix update

Important: redhat-ds:11 security update

Moderate: redhat-ds:11 security, bug fix, and enhancement update

Moderate: redhat-ds:11 security, bug fix, and enhancement update

A flaw was found In 389-ds-base. When the Content Synchronization plugin is enabled, an authenticated user can reach a NULL pointer dereference using a specially crafted query. This flaw allows an authenticated attacker to cause a denial of service. This CVE is assigned against an incomplete fix of CVE-2021-3514.

An access control bypass vulnerability found in 389-ds-base. That mishandling of the filter that would yield incorrect results, but as that has progressed, can be determined that it actually is an access control bypass. This may allow any remote unauthenticated 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.

a user whose password was expired was still allowed to access the database as if the password was not expired. Once a password is expired, and "grace logins" have been used up, the account is basically supposed to be locked out and should not be allowed to perform any privileged action.

A vulnerability was discovered in the 389 Directory Server that allows an unauthenticated attacker with network access to the LDAP port to cause a denial of service. The denial of service is triggered by a single message sent over a TCP connection, no bind or other authentication is required. The message triggers a segmentation fault that results in slapd crashing.

A double-free was found in the way 389-ds-base handles virtual attributes context in persistent searches. An attacker could send a series of search requests, forcing the server to behave unexpectedly, and crash.

A flaw was found in 389-ds-base. If an asterisk is imported as password hashes, either accidentally or maliciously, then instead of being inactive, any password will successfully match during authentication. This flaw allows an attacker to successfully authenticate as a user whose password was disabled.

When binding against a DN during authentication, the reply from 389-ds-base will be different whether the DN exists or not. This can be used by an unauthenticated attacker to check the existence of an entry in the LDAP database.

A flaw was found in the 'deref' plugin of 389-ds-base where it could use the 'search' permission to display attribute values. In some configurations, this could allow an authenticated attacker to view private attributes, such as password hashes.

It was found that the fix for CVE-2018-14648 in 389-ds-base, versions 1.4.0.x before 1.4.0.17, was incorrectly applied in RHEL 7.5. An attacker would still be able to provoke excessive CPU consumption leading to a denial of service.

In 389-ds-base up to version 1.4.1.2, requests are handled by workers threads. Each sockets will be waited by the worker for at most 'ioblocktimeout' seconds. However this timeout applies only for un-encrypted requests. Connections using SSL/TLS are not taking this timeout into account during reads, and may hang longer.An unauthenticated attacker could repeatedly create hanging LDAP requests to hang all the workers, resulting in a Denial of Service.

A flaw has been found in 389-ds-base versions 1.4.x.x before 1.4.1.3. When executed in verbose mode, the dscreate and dsconf commands may display sensitive information, such as the Directory Manager password. An attacker, able to see the screen or record the terminal standard error output, could use this flaw to gain sensitive information.

389 Directory Server is vulnerable to search queries with malformed values in the servers/slapd/search.c:dosearch() function. A malicious client could exploit this by sending crafted queries in a loop to cause a denial of service.

A flaw was found in 389-ds-base before version 1.3.8.4-13. The process ns-slapd crashes in deletepasswdPolicy function when persistent search connections are terminated unexpectedly leading to remote denial of service.

A flaw was found in 389-ds-base. The server can be crashed by an anonymous client through a ldapmodify command with a large DN argument potentially causing denial of service.

References:

https://bugzilla.redhat.com/showbug.cgi?id=1614820

389 Directory Server has a flaw that allows users to cause a crash in the LDAP server using ldapsearch with server side sort.

Product Bug:

https://bugzilla.redhat.com/showbug.cgi?id=1607078

389-ds-base before versions 1.3.8.5, 1.4.0.12 is vulnerable to a Cleartext Storage of Sensitive Information. By default, when the Replica and/or retroChangeLog plugins are enabled, 389-ds-base stores passwords in plaintext format in their respective changelog files. An attacker with sufficiently high privileges, such as root or Directory Manager, can query these files in order to retrieve plaintext passwords.

389-ds-base before versions 1.4.0.10, 1.3.8.3 is vulnerable to a race condition in the way 389-ds-base handles persistent search, resulting in a crash if the server is under load. An anonymous attacker could use this flaw to trigger a denial of service.

389-ds-base before version 1.3.6 is vulnerable to an improperly NULL terminated array in the uniquenessentrytoconfig() function in the "attribute uniqueness" plugin of 389 Directory Server. An authenticated, or possibly unauthenticated, attacker could use this flaw to force an out-of-bound heap memory read, possibly triggering a crash of the LDAP service.