Advisory · CVE-2026-86345
389-ds-base StartTLS flaw can make a failed LDAP login look successful
389-ds-base keeps plaintext bytes buffered across a StartTLS upgrade, letting an on-path attacker inject an LDAP message whose response a client mistakes for a successful bind.
- Vendor
- Red Hat
- Product
- 389 Directory Server (389-ds-base)
- Identifier / CWE
- CVE-2026-86345
CWE-923 - Action timing
- Immediate
Explain it like I’m five
When a client upgrades a plain LDAP connection to encrypted StartTLS, the server forgets to throw away plaintext bytes already sitting in the pipe. An attacker positioned on the network can slip in a forged reply, and the client mistakes it for the answer to its own login attempt, so a failed login looks successful.
- 01On-path position
The attacker sits between an LDAP client and the server on the network segment while a StartTLS negotiation begins.
- 02Plaintext bytes survive the upgrade
Bytes the client sent before the TLS upgrade stay buffered server-side instead of being discarded when encryption starts.
- 03Injected message processed
The attacker injects a crafted LDAP message that the server processes after the upgrade; its response carries a messageID matching the client's pending operation.
- 04Failed bind reads as success
The client application, such as a PAM module, receives the forged response in place of its own result and treats a failed authentication as successful.
What happened
Red Hat disclosed CVE-2026-86345 on October 2, 2026, and scores it CVSS 9.0 (v3.1, scope changed). The flaw is in 389-ds-base, the directory server behind Red Hat Directory Server 11, 12, and 13 and the 389-ds packages in Red Hat Enterprise Linux 8, 9, and 10.
When a client negotiates StartTLS on port 389, the server does not discard plaintext bytes already buffered from the connection. An on-path attacker can inject a crafted LDAP message that is processed after the TLS upgrade; because of a messageID collision, the client receives the injected response in place of the answer to its own pending operation. A client application can therefore treat a failed bind as a successful one.
Red Hat rates the overall product impact Moderate rather than Critical: exploitation needs an active on-path position at the moment StartTLS is negotiated, the server itself gains the attacker nothing, and the security impact lands in downstream client applications that trust the bind result. Red Hat had not listed fixed packages on its CVE page at disclosure.
What to do
- Inventory 389-ds deployments and every LDAP client, PAM stack, and application that authenticates with StartTLS on port 389.
- Prefer LDAPS on port 636, which has no cleartext prefix to inject into; disable StartTLS on port 389 where clients can be moved.
- Apply Red Hat errata for 389-ds-base as soon as fixed packages are published for your Directory Server or RHEL stream.
- Treat the network path between LDAP clients and servers as a trust boundary; audit for rogue proxies, unexpected relays, and spoofed endpoints on those segments.
- Review authentication logs for successful binds that coincide with network anomalies or client reports of strange login behavior.
Management note
The 9.0 score overstates how easy this is: it needs a live man-in-the-middle at a precise moment, and it compromises the client’s login decision rather than the directory itself. Still, any authentication path that crosses an untrusted network over StartTLS should move to LDAPS now rather than waiting on the patch.