CVE-2026-86345: 389-ds-base: 389-ds-base: starttls plaintext-buffer retention allows on-path attacker to forge an ldap client's authentication result
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.
Other sources
A flaw was found in 389-ds-base. When a client negotiates StartTLS, the server (starttlsioenable() in starttlsextop.c) replaces the connection's underlying socket with a TLS-wrapped one but does not discard or invalidate plaintext bytes already buffered from the socket (cbufferbytes/cbufferoffset in connection.c), which are otherwise only reset on a BER parse error or after a fresh read -- neither of which occurs during the StartTLS transport switch. An on-path (man-in-the-middle) attacker can place a second LDAP message in the same TCP segment as the client's StartTLS request; after the server switches to TLS, it parses this smuggled message out of the stale plaintext buffer (openldapreadfunction() in connection.c serves bytes from cbuffer regardless of which underlying descriptor is active) and writes the response inside the new TLS session. By stamping the smuggled message with the messageID the client's next operation (its bind) will use, the attacker's smuggled BindResponse (e.g. an anonymous bind, which always succeeds) is delivered to the client in place of the real bind response, which the connection's turbo-mode single-operation guard does not catch because the smuggled bytes are not yet a tracked Operation object. This causes the client to believe an authentication attempt succeeded when the directory actually rejected it. The default configuration is affected (nsslapd-connection-buffer defaults on; nsslapd-minssf defaults to 0); no misconfiguration is required. Independently reproduced against the real, shipping 389-ds-base-2.6.1-6.el96 build: a wrong-password LDAP bind is forged into a reported success, and separately, using a custom PAM test harness exercising the real pamauthenticate/pamacctmgmt/pamopensession lifecycle against real libldap, a full PAM login session is opened for an existing account with a definitively wrong password. Server-side, 389-ds-base itself suffers no privilege escalation or data exfiltration -- the attacker's own smuggled operation runs anonymous and the client's own subsequent (failing) bind resets the connection to anonymous immediately after. The impact is realized entirely in client-side applications that trust the LDAP bind result (e.g. PAM/nss-pam-ldapd), and the affected clients are not required to have any particular parsing flaw of their own -- both a smuggled BindRequest (any LDAP client) and, per a related but separately-reported OpenLDAP client issue, a smuggled SearchRequest are viable. StartTLS on port 389 is affected; ldaps:// (636) has no cleartext prefix and is not affected.
— Red Hat
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Compensating control
Use LDAPS (ldaps://) on port 636 instead of StartTLS on port 389; LDAPS has no cleartext prefix and is not affected.
Event History
Frequently Asked Questions
What access does an attacker need to exploit this issue?
The attacker must be able to act on-path between an LDAP client and the server during StartTLS negotiation. No prior privileges or user interaction are indicated, but the attacker must inject a crafted LDAP message into the same TCP segment as the client's StartTLS request.
Which client behavior creates the most direct risk?
Clients that use StartTLS and have a pending LDAP operation, particularly an authentication bind, can be targeted. The injected message can collide with the pending operation's messageID so that its response is delivered where the client expects its own response.
What is the practical security impact for an application using LDAP authentication?
An application may interpret a failed LDAP bind attempt as successful. This can allow authentication to be forged from the client's perspective, with high potential impact to confidentiality, integrity, and availability.
How can an affected server behavior be identified without relying on a version number?
The vulnerable behavior is retaining plaintext connection-buffer bytes across the StartTLS transport switch and parsing them after TLS is enabled. The supplied data identifies the relevant implementation as start_tls_io_enable() in start_tls_extop.c and the connection buffer state in connection.c.
Does the supplied information provide a fixed version or workaround?
No fixed version, configuration workaround, or mitigation is included in the supplied data.