CVE-2026-86345

Vendor solution

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.

Red Hat statement

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.

Red Hat mitigation

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.