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

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.

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.

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.

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 was found in 389 Directory Server, affecting all versions including upstream 1.4.x. An improper handling of the search feature with an extended filter, when read access on <attributename> is enabled, in SetUnicodeStringFromUTF8 function in collate.c, can lead to out-of-bounds memory operations. This may allow a remote unauthenticated attacker to trigger a server crash, thus resulting in denial of service.

External References:

https://pagure.io/389-ds-base/issue/49545

Upstream Patch:

https://pagure.io/389-ds-base/c/14ce2fe0dfa67405dae

A flaw was found in 389-ds-base 1.3.6.1. Improper handling of a search filter in slapifiltersprintf in slapd/util.c can lead to remote server crash and denial of service.

Upstream patch:

https://pagure.io/389-ds-base/c/6aa2acdc3cad9

Multiple memory leaks in the normalization functionality in 389 Directory Server before 1.2.7.5 allow remote attackers to cause a denial of service (memory consumption) via "badly behaved applications," related to (1) SlapiAttr mishandling in the DN normalization code and (2) pointer mishandling in the syntax normalization code, a different issue than CVE-2011-0019.

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

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

Multiple memory leaks in Red Hat Directory Server 7.1 before SP7, Red Hat Directory Server 8, and Fedora Directory Server 1.1.1 and earlier allow remote attackers to cause a denial of service (memory consumption) via vectors involving (1) the authentication / bind phase and (2) anonymous LDAP search requests.

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

It was discovered that multiple CGI scripts used by Red Hat / Fedora Directory Server did not properly sanitize %-escaped inputs, resulting in a possibility to conduct cross-site scripting (XSS) attacks.

Issue was caused by a flow in an adminutil library that contain common functionality used by multiple CGI scripts, such as affected GET / POST argument parsing.

Issue is know to affect some Administration Express scripts and Directory Server Gateway (DSGW) scripts.

Affected version: Red Hat Directory Server 7.1 Red Hat Directory Server 8 (flaw limited to Administration Express issues, as DSGW component is not shipped) Fedora Directory 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.

A vulnerability in Red Hat Directory Server and the 389 Directory Server was discovered. The code that parses the GER request (gerparsecontrol()) can dereference a NULL pointer. An unauthenticated user able to communicate with the Directory Server could use a crafted search query that would cause the Directory Server to crash.

This issue has been assigned the name CVE-2010-2222.

slapd (aka ns-slapd) in 389 Directory Server before 1.2.8.a2 does not properly manage the ctimelimit field of the connection table element, which allows remote attackers to cause a denial of service (daemon outage) via Simple Paged Results connections, as demonstrated by using multiple processes to replay TCP sessions, a different vulnerability than CVE-2011-0019.

389 Directory Server 1.2.7.5, when built with mozldap, allows remote attackers to cause a denial of service (replica crash) by sending an empty modify request.

It was discovered that 398 / Red Hat Directory Server set LDLIBRARYPATH environment variable to insecure value containing empty path elements in various shell scripts used by DS (e.g. various backup/restore scripts instantiated for each DS instance, as well as the main initialization script). Such LDLIBRARYPATH setting causes ld.so dynamic linker to perform library search relative to the current working directory before searching system library directories. A local attacker able to trick a user running those scripts (usually the root user) to run them while working from an attacker writeable directory could use this flaw to escalate their privileges via specially crated dynamic library.

It was discovered that 389 / Red Hat Directory Server's setup scripts set insecure permissions (0777) on the /var/run/dirsrv directory used to store Directory Server's pid files when multiple Directory Server instances were configured on the system to be run under the different unprivileged users.

A local user could use this flaw to create, remove or replace pid files in this directory, possibly preventing correct start of the Directory Server instances, or causing Directory Server init script to kill arbitrary process during the Directory Server shutdown.

A flaw was found in the way that the Red Hat Directory Server handled simple paged result searches. If an unauthenticated user were able to send multiple simple paged search requests to Directory Server, it could cause the server to crash.

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 1.2.11.15 (aka Red Hat Directory Server before 8.2.11-14) allows remote authenticated users to cause a denial of service (crash) via multiple @ characters in a GER attribute list in a search request.

ns-slapd in 389 Directory Server before 1.3.0.8 allows remote attackers to cause a denial of service (server crash) via a crafted Distinguished Name (DN) in a MOD operation request.

A flaw was found in how Red Hat Directory Server and the 389 Directory Server would handle access controls to certain attributes of an entry. A user with access to the Directory Server could use a series of searches to guess the values of other attributes that they should not be able to see. If a user had access (authenticated or anonymous, depending on whether or not the Directory Server allows anonymous access), they could use this to obtain information that should be restricted due to access controls.

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.

389 Directory Server before 1.3.2.27 and 1.3.3.x before 1.3.3.9 does not properly restrict access to the "cn=changelog" LDAP sub-tree, which allows remote attackers to obtain sensitive information from the changelog via unspecified vectors.

389 Directory Server 1.3.1.x, 1.3.2.x before 1.3.2.27, and 1.3.3.x before 1.3.3.9 stores "unhashed" passwords even when the nsslapd-unhashed-pw-switch option is set to off, which allows remote authenticated users to obtain sensitive information by reading the Changelog.