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 the SASL I/O layer of 389 Directory Server (389-ds-base). In sasliostartpacket(), the 4-byte wrapped-record length read from the wire is validated only against an upper bound (the check added for CVE-2026-11774). When a SASL-authenticated attacker sends a wrapped record with a wire length of 0 (or 1 or 2), the resulting encryptedbuffercount (4, 5, or 6 after adding sizeof(uint32t)) is less than encryptedbufferoffset (7, the header bytes already consumed). The unsigned subtraction in saslioreadpacket() then underflows to approximately 0xFFFFFFFD, and PRRecv is requested to read roughly 4 GiB into the 1024-byte encryptedbuffer allocated in saslioinitbuffers(). This causes a heap buffer overflow with attacker-controlled length and content. The vulnerability requires authentication via a SASL bind with integrity protection (SSF > 0). This is a distinct defect from CVE-2026-11774, which only guards against lengths near UINT32MAX; the lower-end case is not covered and the vulnerability persists at HEAD.
A flaw was found in the SASL I/O layer of 389 Directory Server (389-ds-base). In sasliostartpacket(), the 4-byte wrapped-record length read from the wire is validated only against an upper bound (the check added for CVE-2026-11774). When a SASL-authenticated attacker sends a wrapped record with a wire length of 0 (or 1 or 2), the resulting encryptedbuffercount (4, 5, or 6 after adding sizeof(uint32t)) is less than encryptedbufferoffset (7, the header bytes already consumed). The unsigned subtraction in saslioreadpacket() then underflows to approximately 0xFFFFFFFD, and PRRecv is requested to read roughly 4 GiB into the 1024-byte encryptedbuffer allocated in saslioinitbuffers(). This causes a heap buffer overflow with attacker-controlled length and content. The vulnerability requires authentication via a SASL bind with integrity protection (SSF > 0). This is a distinct defect from CVE-2026-11774, which only guards against lengths near UINT32MAX; the lower-end case is not covered and the vulnerability persists at HEAD.
A flaw was found in 389 Directory Server. The CleanAllRUV and Abort CleanAllRUV replication-maintenance extended operations perform no authorization check, allowing an unauthenticated remote attacker to invoke them when nsslapd-allow-anonymous-access is enabled (the default), or any authenticated low-privilege user to invoke them otherwise. This allows removal of a replica ID from replication metadata, purging of changelog records, and interruption of administrator-initiated cleanup, which can leave replication inconsistent or unavailable.
A heap-buffer-overflow flaw was found in 389 Directory Server (389-ds-base). When normalizing a Distinguished Name (DN) that contains a legacy-quoted value encoding a multivalued nested Relative Distinguished Name (RDN), the server can write past the end of a heap allocation while sorting RDN attribute-value pairs. An unauthenticated remote attacker can trigger this condition by sending an LDAP operation whose DN reaches the DN normalization routine, such as a search with a crafted base DN. This can corrupt heap memory and may cause denial of service.
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 flaw was found in 389 Directory Server (389-ds-base). In idssaslcheckbind(), on a successful SASLOK from the underlying Cyrus SASL library, the connection is marked SASL-complete and bind credentials are installed via bindcredentialssetnolock() before the account-lock check (slapicheckaccountlock()) is performed for non-root binds. If the subsequent lock check determines the account is locked (nsAccountLock: true), the bind is failed and reported to the client, but the already-installed SASL-complete flag and bind credentials are not reverted. A client that already knows the correct password for an account that has since been administratively locked can bind via SASL PLAIN, receive an "account locked" failure response, and continue using the same, already-authenticated TCP connection to perform further LDAP operations as that account -- defeating account lock as an access-revocation control. Setting nsslapd-close-on-failed-bind does not mitigate this. This finding was independently reported by two unrelated parties (OpenAI Security Research and Andrew Rukin of Arenadata) who converged on the identical root cause.