389-ds-base: StartTLS-Pufferspeicherung erlaubt gefälschte LDAP-Bind-Ergebnisse

Zusammenfassung

Der LDAP-Server 389-ds-base (Red Hat Directory Server) behält vor einem StartTLS-Upgrade im Klartext gepufferte Daten. Ein Angreifer auf dem Netzwerkpfad kann eine manipulierte LDAP-Nachricht einschleusen, die nach dem TLS-Upgrade verarbeitet wird, sodass der Client statt seiner eigenen Bind-Antwort eine gefälschte Antwort erhält (Kollision der Message ID). Dadurch kann eine Client-Anwendung einen fehlgeschlagenen Authentifizierungsversuch als erfolgreich werten. Voraussetzung ist eine aktive Man-in-the-Middle-Position während der StartTLS-Aushandlung; der Server selbst wird nicht kompromittiert.

Betroffen

• Red Hat Directory Server 11, 12 und 13 (laut Red Hat-CVE-Eintrag: betroffen)
• Red Hat Enterprise Linux 8, 9 und 10 (laut Red Hat-CVE-Eintrag: betroffen)
• Red Hat Enterprise Linux 6 und 7: Status unbekannt
• Weitere Distributionen liefern 389-ds-base aus; die betroffenen Versionen sind nicht vollständig bestätigt

Behoben in

• Red Hat: Unbekannt. In den geprüften Quellen ist kein Red Hat-Errata mit Korrektur bestätigt.
• Upstream: Korrektur als Issue 7921 verfolgt und in die Zweige 2.8, 3.0, 3.1 und 3.2 zurückportiert; genaue Release-Nummern nicht bestätigt.
• Debian (nicht verifiziert): 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 (wie gemeldet).

Umgehung

• StartTLS auf Port 389 deaktivieren und stattdessen ldaps:// (Port 636) verlangen.
• Keine reine Konfigurationsmassnahme schliesst die Lücke auf Port 389 vollständig, solange StartTLS aktiviert ist.

Ausnutzung

• CISA SSVC: Exploitation none, Automatable no, Technical Impact total.
• Nicht im CISA-KEV-Katalog als aktiv ausgenutzt verzeichnet (nicht unabhängig verifiziert).
• Kein öffentlicher Exploit-Code bestätigt. Der Melder behauptet eine Reproduktion, einschliesslich eines gefälschten Bind-Ergebnisses auf einem ausgelieferten Build.

Unsere Empfehlung

• 389-ds-base patchen, sobald Ihre Distribution einen korrigierten Build bereitstellt; Sicherheitsmeldungen Ihres Herstellers prüfen.
• Bis zum Patch StartTLS auf Port 389 nicht mehr verwenden und für alle Clients LDAPS (636) verlangen.
• Verzeichnisserver von unvertrauenswürdigen Netzen fernhalten und von Gast- und gemeinsam genutzten WLAN-Netzen segmentieren.
• Ein Bind-Ergebnis nicht als Beweis für einen gültigen Login werten, solange der Kanal nicht gesichert ist.
• Auf unerwartete erfolgreiche Authentifizierungen achten und LDAP-Client-Logs prüfen.

Öffentliche Exploits iAngriffscode ist öffentlich verfügbar (PoC auf GitHub, Metasploit oder Exploit-DB).

In PoC-in-GitHub, Metasploit und Exploit-DB ist für diese CVE nichts verzeichnet.

Quellen der Recherche

• Red Hat CVE record CVE-2026-86345 access.redhat.com
• Red Hat Bugzilla 2529332 bugzilla.redhat.com
• Upstream fix pull request 7947 github.com
• Upstream fix pull request 7945 github.com
• Debian CVE tracker entry (Vulners) vulners.com
• openSUSE Tumbleweed advisory (Vulners PT-2026-132720) vulners.com
• AlmaLinux errata ALSA-2026-36195 errata.almalinux.org
• TheHackerWire CVE-2026-86345 www.thehackerwire.com

Recherchiert und auf Deutsch und Englisch aufbereitet von einer KI (Claude von Anthropic) auf Basis von NVD, CISA, EPSS und den genannten Quellen. Massgebend sind die Angaben des Herstellers. Recherche vom 31.10.2026 08:18.