CVE-2026-18651

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.

This flaw lets a user authenticate to an already-locked account (nsAccountLock: true) via SASL PLAIN, using that account's own correct password. The server checks the password before it checks the lock, so the connection becomes authenticated even though the client is told the bind failed. After bind, the user can read and modify what that account was already permitted to touch - no escalation and access beyond it's own rights.

The CVSS score(s) listed for this vulnerability do not reflect the associated product's status, and are included for informational purposes to better understand the severity of this vulnerability.

When locking an account, also rotate its LDAP password. Locking the account alone is not enough: this flaw lets a bind with the account's still-valid password succeed even after it's locked.