A flaw was found in 389-ds-base. The server does not discard plaintext bytes already buffered from a client connection when negotiating StartTLS, allowing an on-path attacker to inject a crafted LDAP message that is processed after the TLS upgrade and whose response is delivered to the client in place of the client's own pending operation's response, due to messageID collision. This can cause a client application to treat a failed authentication (bind) attempt as successful.
A flaw was found in 389-ds-base. When a client negotiates StartTLS, the server (starttlsioenable() in starttlsextop.c) replaces the connection's underlying socket with a TLS-wrapped one but does not discard or invalidate plaintext bytes already buffered from the socket (cbufferbytes/cbufferoffset in connection.c), which are otherwise only reset on a BER parse error or after a fresh read -- neither of which occurs during the StartTLS transport switch. An on-path (man-in-the-middle) attacker can place a second LDAP message in the same TCP segment as the client's StartTLS request; after the server switches to TLS, it parses this smuggled message out of the stale plaintext buffer (openldapreadfunction() in connection.c serves bytes from cbuffer regardless of which underlying descriptor is active) and writes the response inside the new TLS session. By stamping the smuggled message with the messageID the client's next operation (its bind) will use, the attacker's smuggled BindResponse (e.g. an anonymous bind, which always succeeds) is delivered to the client in place of the real bind response, which the connection's turbo-mode single-operation guard does not catch because the smuggled bytes are not yet a tracked Operation object. This causes the client to believe an authentication attempt succeeded when the directory actually rejected it. The default configuration is affected (nsslapd-connection-buffer defaults on; nsslapd-minssf defaults to 0); no misconfiguration is required. Independently reproduced against the real, shipping 389-ds-base-2.6.1-6.el96 build: a wrong-password LDAP bind is forged into a reported success, and separately, using a custom PAM test harness exercising the real pamauthenticate/pamacctmgmt/pamopensession lifecycle against real libldap, a full PAM login session is opened for an existing account with a definitively wrong password. Server-side, 389-ds-base itself suffers no privilege escalation or data exfiltration -- the attacker's own smuggled operation runs anonymous and the client's own subsequent (failing) bind resets the connection to anonymous immediately after. The impact is realized entirely in client-side applications that trust the LDAP bind result (e.g. PAM/nss-pam-ldapd), and the affected clients are not required to have any particular parsing flaw of their own -- both a smuggled BindRequest (any LDAP client) and, per a related but separately-reported OpenLDAP client issue, a smuggled SearchRequest are viable. StartTLS on port 389 is affected; ldaps:// (636) has no cleartext prefix and is not affected.
A flaw was found in 389-ds-base. An unauthenticated remote attacker can send a complete LDAP operation followed by the first bytes of an incomplete LDAPMessage on the same connection, causing the server to hand that connection to a second worker thread before the first worker's result is flushed. The second worker blocks until nsslapd-ioblocktimeout while holding the connection mutex, preventing delivery of the completed operation's result. Repeating this across a small number of connections proportional to the configured worker-thread pool size exhausts the entire pool under default configuration, denying service to all clients (anonymous and authenticated, plaintext and TLS) for as long as the attacker maintains the connections.
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 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.
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.
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 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.