CVE-2026-86345

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.

This flaw is rated Moderate rather than Critical or Important, despite a CVSS base score of 9.0. Exploitation requires an attacker to hold an active on-path (man-in-the-middle) position on the network segment between an LDAP client and the server at the moment StartTLS is negotiated -- a materially harder precondition than a purely remote, unauthenticated attack, and one that rules out the ease-of-exploitation bar Critical requires. The outcome is also not arbitrary code execution: exploitation causes a client-side application (e.g. a PAM module) to incorrectly treat a failed authentication attempt as successful, granting access through that application's own, legitimate, pre-existing login mechanism rather than through execution of attacker-supplied code. 389-ds-base itself is not compromised by this flaw -- the server suffers no privilege escalation and no data exfiltration beyond what an anonymous bind could already obtain; the security impact is entirely realized in separate, downstream client applications that trust the LDAP bind result.

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.

Disable StartTLS on port 389 and require ldaps:// (port 636) instead, which has no cleartext prefix to inject into. No configuration-only mitigation fully closes the issue on port 389 while StartTLS remains enabled.