IT SBIT Services
Schneeberger
DEEN
CVE tracker

389-ds-base: StartTLS buffer retention allows forged LDAP bind results

CVE-2026-86345Critical 9.0

← All vulnerabilities

Summary

The LDAP server 389-ds-base (Red Hat Directory Server) keeps plaintext data buffered before a StartTLS upgrade. An on-path attacker can inject a crafted LDAP message that is processed after the TLS upgrade, so the client receives a forged response in place of its own bind response (message ID collision). This can make a client application treat a failed authentication as successful. Exploitation requires an active man-in-the-middle position on the network path during StartTLS negotiation; the server itself is not compromised.

Affected

  • Red Hat Directory Server 11, 12 and 13 (per Red Hat CVE record: affected)
  • Red Hat Enterprise Linux 8, 9 and 10 (per Red Hat CVE record: affected)
  • Red Hat Enterprise Linux 6 and 7: status unknown
  • Other distributions package 389-ds-base; affected versions are not fully confirmed

Fixed in

  • Red Hat: Unknown. No fixed Red Hat errata confirmed in the sources reviewed.
  • Upstream: fix tracked as issue 7921 and backported to the 2.8, 3.0, 3.1 and 3.2 branches; exact release numbers not confirmed.
  • Debian (unverified): 2.3.1+dfsg1-1+deb12u1, 3.1.2+dfsg1-1+deb13u1, 3.3.1-3.
  • openSUSE Tumbleweed: 389-ds-3.3.1+28b6d8afc-1.1 (as reported).

Workaround

  • Disable StartTLS on port 389 and require ldaps:// (port 636) instead.
  • No configuration-only mitigation fully closes the issue on port 389 while StartTLS remains enabled.

Exploitation

  • CISA SSVC: exploitation none, automatable no, technical impact total.
  • Not recorded as actively exploited in the CISA KEV catalog (not independently verified).
  • No public exploit code confirmed. The reporter claims reproduction, including a forged bind result on a shipping build.

Our recommendation

  • Patch 389-ds-base as soon as your distribution provides a fixed build; check your vendor advisories.
  • Until patched, stop using StartTLS on port 389 and require LDAPS (636) for all clients.
  • Keep directory servers off untrusted networks and segment them from guest and shared Wi-Fi.
  • Do not treat a bind result as proof of a valid login unless the channel is secured.
  • Monitor for unexpected authentication successes and review LDAP client logs.

Public exploits

PoC-in-GitHub, Metasploit and Exploit-DB list nothing for this CVE.

Research sources

Researched and written up in English and German by an AI (Claude by Anthropic) based on NVD, CISA, EPSS and the sources listed. The vendor information is authoritative. Researched on 31 Oct 2026, 08:18.

Original description (NVD)

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.

NVD references (2)

Sources

The tracker combines official, freely usable data sources – updated continuously:

This product uses data from the NVD API but is not endorsed or certified by the NVD. EPSS data © FIRST.org.

Affected? We can help.

We check whether your systems are affected, install updates and close the gap – continuously with the System Health Checker if you wish.

Get in touchRSS feed