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

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.9, 1.3.8.1, 1.3.6.15 did not properly handle long search filters with characters needing escapes, possibly leading to buffer overflows. A remote, unauthenticated attacker could potentially use this flaw to make ns-slapd crash via a specially crafted LDAP request, thus resulting in 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.

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.