CVE-2026-86345: 389-ds-base StartTLS plaintext buffer injection

CVE-2026-86345 · Severity: critical · CVSS 9 · Published 2026-10-02

389-ds-base is an open-source LDAP directory server used for authentication and identity management in enterprise environments. The server fails to discard buffered plaintext data when upgrading a connection to TLS during StartTLS negotiation, allowing an attacker positioned between a client and server to inject a crafted LDAP message. An attacker can exploit this to forge a successful authentication response, causing a client application (such as a PAM module) to incorrectly treat a failed login as successful and grant unauthorized access.

Technologies: Red Hat 389-Ds-Base. Vendors: Red Hat.

Quick answers

Is CVE-2026-86345 exploited in the wild?
No. Junglewise Threat Intelligence has no report of CVE-2026-86345 being exploited in the wild.
How severe is CVE-2026-86345?
Critical severity, with a CVSS score of 9, published 2 October 2026.
Which products and versions are affected?
Red Hat 389-Ds-Base <UNKNOWN>.
Is there a fix for CVE-2026-86345?
No fixed version is recorded yet. Disable StartTLS on port 389 and require ldaps:// (port 636) instead, which does not have a cleartext prefix that can be injected into.</anigation> <parameter name="timeline">[{"kind":"disclosed","at":"2026-10-02"},{"kind":"other","at":"2026-10-02","note":"Red Hat rates as Moderate despite CVSS 9.0 score due to required on-path positioning and lack of arbitrary code execution"}] If you run it, Junglewise drafts a mitigation that fits your setup and applies it once you approve, with senior security engineers behind it.
How is CVE-2026-86345 attacked?
It is attacked from the adjacent network, in a hosted service.
Am I affected by CVE-2026-86345?
Check whether you run Red Hat 389-Ds-Base at an affected version. Junglewise does that check for you around the clock: connect your code, cloud and domains, and it matches new vulnerabilities like this one against what you actually run and tells you when one reaches you.

How to fix

Disable StartTLS on port 389 and require ldaps:// (port 636) instead, which does not have a cleartext prefix that can be injected into.</anigation> <parameter name="timeline">[{"kind":"disclosed","at":"2026-10-02"},{"kind":"other","at":"2026-10-02","note":"Red Hat rates as Moderate despite CVSS 9.0 score due to required on-path positioning and lack of arbitrary code execution"}]

Technical details

The vulnerability exists in the StartTLS negotiation flow where buffered plaintext bytes from the client connection are not discarded before the TLS upgrade occurs. An on-path (man-in-the-middle) attacker can inject a crafted LDAP message that, after the TLS upgrade, gets processed and its response delivered to the client via messageID collision, causing the client to receive a forged bind response. Exploitation requires active network positioning between client and server at the moment of StartTLS negotiation, and the impact is limited to downstream client-side applications that incorrectly treat the forged response as legitimate; the 389-ds-base server itself is not compromised.

Affected products

  • Red Hat 389-ds-base <UNKNOWN>

References

This page as Markdown. Free to reuse under CC BY 4.0 with a link back.