CVE-2026-18651
MediumCVSS 5.4Exploitation Probability (EPSS)
Low risk7th percentile - higher than 7% of all known CVEs
Summary
389 Directory Server has a vulnerability in SASL PLAIN authentication. The server installs connection-level bind credentials before performing the account-lock check. If the account is locked, the bind is reported as failed, but the authenticated state on the connection is not reverted. A client with valid credentials for a locked account can continue to use the connection with that account's privileges.
Risk Assessment
An attacker with valid credentials for a locked account can bypass account lock controls and gain unauthorized access to directory services.
Recommendation
Update 389 Directory Server to a version where the vulnerability is fixed, and consider additional access control mechanisms.
Other vulnerabilities in 389 Directory Server
See all- CVE-2015-1854High
389 Directory Server before 1.3.3.10 allows attackers to bypass intended access restrictions and modify directory entries via a crafted ldapmodrdn call.
- CVE-2016-5416High
389 Directory Server in Red Hat Enterprise Linux 6 and 7 allows remote attackers to read the default Access Control Instructions.
- CVE-2016-4992High
The 389 Directory Server in Red Hat Enterprise Linux 6 and 7 allows remote attackers to infer the existence of RDN component objects.
- CVE-2016-0741High
In 389 Directory Server (formerly Fedora Directory Server) versions 1.3.4.x before 1.3.4.7, a vulnerability allows remote attackers to cause a denial of service through an abnormally closed connection, leading to an infinite loop and connection blocking.
- CVE-2015-3230High
389 Directory Server (formerly Fedora Directory Server) before version 1.3.3.12 does not enforce the nsSSL3Ciphers preference when creating an sslSocket, allowing remote attackers to use a disabled cipher.
- CVE-2026-18922Critical
In 389 Directory Server, during SASL PLAIN authentication, a stale identity carried in a Cyrus SASL auxiliary property from a prior failed bind attempt can be installed on a connection following a subsequent, unrelated successful bind, regardless of which SASL mechanism completes that second bind. An attacker can send a SASL PLAIN bind as cn=Directory Manager with an incorrect password, then complete a SASL ANONYMOUS bind on the same connection, causing the server to grant Directory Manager authority without any valid credentials. A variant using a valid low-privileged account's own successful bind instead of an anonymous one is also possible.
- CVE-2016-5405Critical
The 389 Directory Server in Red Hat Enterprise Linux (Desktop, HPC Node, Server, Workstation) versions 6 and 7 allows remote attackers to obtain user passwords.
- CVE-2026-18453High
A missing NULL pointer check in the paged results handling of op_shared_search in 389 Directory Server. An unauthenticated remote attacker can crash the LDAP server by sending a crafted sequence of search requests using the USE_ONE_BACKEND control, resulting in denial of service.
- CVE-2026-18355High
A heap buffer overflow in the SASL I/O layer of 389 Directory Server. In sasl_io_start_packet(), the wrapped-record length is only validated against an upper bound. A small wire length causes an unsigned underflow, leading to a read of about 4 GiB into a 1024-byte heap buffer. A remote authenticated attacker after a successful SASL bind with integrity protection can cause denial of service or potentially remote code execution.
- CVE-2026-76560High
A flaw in 389 Directory Server in the SELFDN ACI bind-rule evaluator. An anonymous LDAP client's empty bind DN is incorrectly matched against an empty stored attribute value, allowing an unauthenticated client to satisfy access control checks intended for authenticated identities. This can allow anonymous clients to perform operations like adding or modifying entries that should be restricted to specific authenticated users.
Original NVD description (English source)
A flaw was found in 389 Directory Server. During SASL PLAIN authentication, the server installs connection-level bind credentials before performing the account-lock check. If the account is subsequently found to be locked, the bind is reported as failed to the client, but the already-installed authenticated state on the connection is not reverted. A client that supplies valid credentials for an account that has been administratively locked can continue to use the same connection with that account's privileges, defeating account lock as an access-revocation control.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS

