A flaw was found in 389-ds-base. A remote, authenticated attacker could exploit a vulnerability in the Simple Authentication and Security Layer (SASL) UNBIND process. By sending a specially crafted request, the attacker can cause a connection to stall, leading to resource exhaustion and a Denial of Service (DoS) for the server.

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 in the aclpnormalizeacltxt() function of aclparse.c. A malformed ACI (Access Control Instruction) string can trigger heap-buffer-overflow writes and reads during ACI parsing. The function fails to validate that the ACI keyword has sufficient length after whitespace stripping, leading to a 1-byte out-of-bounds write and subsequent out-of-bounds reads. An authenticated user with write access to the aci attribute could send a crafted ACI value to silently corrupt heap memory in the directory server process.

Three related heap buffer overflow bugs were found in the aclpnormalizeacltxt() function in ldap/servers/plugins/acl/aclparse.c of 389 Directory Server. The function is called during ACI (Access Control Instruction) parsing via aclparse() -> aclpparseaci() -> aclpsanitycheckacltxt() -> aclpnormalizeacltxt().

The root cause is that aclpnormalizeacltxt() blindly assumes the ACI string after whitespace stripping still has at least 3 characters (the "aci" or "acl" keyword), without any bounds check. The assert(s) on line 850 only checks for NULL, not for an empty or too-short string, and asserts are compiled out in release builds (NDEBUG).

The three bugs are:

1. Out-of-bounds WRITE (1 byte): On line 852, (s + 2) = 'l' writes one byte past the heap buffer when the string is too short after whitespace stripping.

2. Out-of-bounds READ (strchr): On line 856, strchr(aclstr, ';') reads past the buffer because the NUL terminator was clobbered or the string lacks a semicolon.

3. Out-of-bounds READ (strdup): On line 866, slapichstrdup(aclName) reads past the buffer in strdup for the same root cause.

To trigger the vulnerability, an attacker needs write access to the 'aci' attribute on a directory entry. In the default modern configuration (389-ds-base 2.x / RHDS 12), only the Directory Manager can write ACIs. However, in older deployments or those using common ACI patterns with negated targetattr rules (e.g., targetattr!="userPassword") or wildcards (targetattr=""), any authenticated user may be able to write to the 'aci' attribute.

ASAN is not enabled in production release builds (the spec file defaults to %bcond asan 0 / %global useasan 0). In production binaries, the heap corruption is silent — the 1-byte write corrupts adjacent heap memory without a deterministic crash, and the OOB reads silently read garbage from adjacent heap allocations. The practical impact in production builds is likely negligible, making this primarily a hardening issue.

The 1-byte write primitive is not controllable (fixed value 'l'/0x6C at fixed offset +2 from a small allocation) and is not realistically weaponizable for code execution.

Upstream fix: https://github.com/389ds/389-ds-base/pull/7542 Upstream issue: https://github.com/389ds/389-ds-base/issues/7541

A flaw was found in 389 Directory Server. The dereference control plugin does not check for allocation failure before using a BER structure, allowing an unauthenticated remote attacker to crash the LDAP server when the system is under memory pressure.

A type confusion bug in extophandleldapssotokenrequest() (extendop.c) passes a stack pointer (&rc) to berprintf with format 'i' which expects an integer. The low 32 bits of a stack address are encoded into every SSO token LDAP extended operation response.

Any authenticated non-administrator user can extract partial stack address information. SSO token feature enabled by default with auto-generated secret (Issue #1797). PoC confirmed on Fedora 42: INTEGER=0x8e7faed8 leaked. Reduces stack ASLR entropy but is not a full bypass.

A flaw was found in 389 Directory Server. The PBKDF2-SHA256 password storage plugin does not enforce an upper bound on the iteration count extracted from stored password hashes. A privileged attacker who can modify a user's password hash can cause excessive CPU consumption during authentication, resulting in denial of service.

An integer overflow flaw was found in the SASL I/O layer of 389 Directory Server (389-ds-base). In sasliostartpacket(), adding sizeof(uint32t) to a crafted SASL packet length prefix of 0xFFFFFFFC causes unsigned wraparound to zero, bypassing the nsslapd-maxsasliosize limit and leading to a heap buffer overflow of up to approximately 2 megabytes of attacker-controlled data. After a successful SASL bind with integrity protection (SSF > 0), a remote attacker can cause a Denial of Service (DoS) or achieve Remote Code Execution (RCE). In FreeIPA and Red Hat Identity Management deployments, any domain user with a valid Kerberos ticket, enrolled host, or service account can trigger this vulnerability over the network. This flaw is independent of CVE-2025-14905, which patched schema.c only and did not modify saslio.c.

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 heap buffer overflow flaw was found in the SASL I/O layer of 389 Directory Server (389-ds-base). After a successful SASL bind with integrity protection (SSF > 0), an authenticated attacker can send a specially crafted oversized LDAP UNBIND packet that is copied into a 512-byte heap receive buffer without a bounds check in sasliorecv() in saslio.c. This allows up to approximately 2 megabytes of attacker-controlled data to overflow the buffer, causing a denial of service (server crash). In FreeIPA and Red Hat Identity Management deployments, any domain user with a valid Kerberos ticket, any enrolled host, or any service account can trigger this vulnerability over the network after authenticating via GSSAPI. The vulnerable code path has existed since approximately 2013 (389-ds-base 1.3.2) and was not addressed by the CVE-2025-14905 fix, which patched a separate heap overflow in schema.c only.

A flaw was found in 389-ds-base. The getldapmessagecontrolsext() function in the LDAP server does not enforce an upper bound on the number of controls per LDAP message. A remote, unauthenticated attacker can send a specially crafted LDAP request containing hundreds of thousands of minimal controls within the default maximum BER message size (2 MB), causing excessive CPU consumption and heap allocation on the server. Under concurrent exploitation, this leads to significant latency degradation, worker thread starvation, or out-of-memory termination, resulting in a denial of service.

A vulnerability was found in 389-ds-base (389 Directory Server). The function getldapmessagecontrolsext() in ldap/servers/slapd/control.c parses the optional LDAP v3 Controls field via a decode loop that allocates one LDAPControl struct per control element and grows the pointer list with repeated reallocations, but does not enforce a hard upper bound on the number of controls per message.

Under the default nsslapd-maxbersize of 2097152 (2 MB), a remote unauthenticated client can encode hundreds of thousands of minimal non-critical controls in a single LDAP request, forcing attacker-amplified CPU time and heap allocation. The control parsing occurs pre-authentication (e.g., during Bind request processing at bind.c:227), meaning no credentials are required to trigger the vulnerability.

Concurrency testing shows that with 4 concurrent 400000-controls Bind requests, heavy requests frequently exceed a 10-second client-side timeout, and independent small probes see latency spikes (baseline p50 ~3ms to stress p50 ~45ms). Sustained pressure can cause worker starvation or OOM termination.

This vulnerability is classified as CWE-770 (Allocation of Resources Without Limits or Throttling), similar in pattern to CVE-2019-10171 in 389-ds-base.

Upstream repository: https://github.com/389ds/389-ds-base Callsite: ldap/servers/slapd/control.c, function getldapmessagecontrolsext(), line 382-383 Bind entry: ldap/servers/slapd/bind.c, line 227 Confirmed at commit: 761452f79c30bbfd0d6756c4a8ed39549fde5717

Reported by: Oleh Konko of 1seal.org (security) Original report: PSIRTSUPT-6092

A flaw was found in 389-ds-base. The problem occurs when issuing a Modify DN LDAP operation through the ldap protocol (using a TCP-IP or Unix socket as defined in the LDAP RFC https://datatracker.ietf.org/doc/html/rfc4511#section-4.9) If it moves an ldap entry in the DIT at the same time that a failing operation impacts its parent entry.

A denial of service vulnerability was found in 389-ds-base ldap server. This issue may allow an authenticated user to cause a server crash or hang while authenticating with an user having a malformed userPassword. By default only the administrator may directly add hashed password that can trigger the issue. But if nsslapd-allow-hashed-passwords config parameter is turned on, any user can trigger the issue.

The problem is triggered by adding a password to an user using the hashed format (with a hash value too long for the specified hash scheme) Then later on when trying to authenticate on that user its triggers the buffer overflow

By default, only administrators are allowed to add hashed passwords but there is a configuration parameter (nsslapd-allow-hashed-passwords) allowing any users to add hashed passwords and potentially trigger the DoS.

This vulnerability affects versions: >= 1.3.7.2

A vulnerability was found in 389-ds-base : the deref plugin is checking for either READ or SEARCH permission for dereferencing an attribute. This means that the SEARCH permission is sufficient to display an attribute via the plugin.

This is relevant in particular in IdM/IPA environment, where a default ACI ("Search existence of password and kerberos keys") in set. This leads to dereferencing able to display userPassword content or any users.

A vulnerability in 389-ds-base was found that allows to bypass limitations for compare and read operations specified by Access Control Instructions.

When having LDAP sub-tree with some existing objects and having BIND DN which have no privileges over objects inside the sub-tree, unprivileged user can send LDAP ADD operation specifying an object in (supposedly) inaccessible sub-tree. The returned error messages discloses the information when the queried object exists having the specified value. Attacker can use this flaw to guess values of RDN component by repeating the above process.

Upstream commit:

https://github.com/389ds/389-ds-base/commit/0b932d4b926d46ac5060f02617330dc444e06da1

Andrew Kerr reported that a 389 replica would crash when an empty modify request is sent to it. This can only happen if the 389 server is built with mozldap (not OpenLDAP) and the modify operation is replicated or the server set 'cn=config nsslapd-lastmod: off'.

389 on Fedora 14 and later, as well as Red Hat Enterprise Linux 6, use OpenLDAP, not mozldap, and are thus unaffected. This flaw does not affect Red Hat Directory Server 8.2.

This flaw was caused by the fix for bug #305131 which allowed empty modify operations to proceed through the code.