CVE-2026-18651
ŚrednieCVSS 5.4Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 7 - wyżej niż 7% wszystkich znanych CVE
Streszczenie
389 Directory Server zawiera podatność w uwierzytelnianiu SASL PLAIN. Serwer instaluje poświadczenia bind na poziomie połączenia przed sprawdzeniem blokady konta. Jeśli konto jest zablokowane, bind jest zgłaszany jako nieudany, ale stan uwierzytelnienia na połączeniu nie jest cofany. Klient z prawidłowymi danymi dla zablokowanego konta może nadal korzystać z tego połączenia z uprawnieniami tego konta.
Ocena ryzyka
Atakujący z prawidłowymi danymi uwierzytelniającymi dla zablokowanego konta może ominąć kontrolę blokady konta i uzyskać nieautoryzowany dostęp do usług katalogowych.
Rekomendacja
Należy zaktualizować 389 Directory Server do wersji, w której podatność została naprawiona, oraz rozważyć dodatkowe mechanizmy kontroli dostępu.
Inne podatności w 389 Directory Server
Zobacz wszystkie- CVE-2015-1854Wysokie
Serwer katalogowy 389 w wersjach przed 1.3.3.10 pozwala atakującym na obejście zamierzonych ograniczeń dostępu oraz modyfikację wpisów katalogowych za pomocą spreparowanego wywołania ldapmodrdn.
- CVE-2016-5416Wysokie
Serwer katalogowy 389 w systemach Red Hat Enterprise Linux 6 i 7 umożliwia zdalnym atakującym odczyt domyślnych instrukcji kontroli dostępu.
- CVE-2016-4992Wysokie
Serwer katalogowy 389 w systemach Red Hat Enterprise Linux 6 i 7 umożliwia zdalnym atakującym wnioskowanie o istnieniu obiektów komponentów RDN.
- CVE-2016-0741Wysokie
W 389 Directory Server (wcześniej Fedora Directory Server) w wersjach 1.3.4.x przed 1.3.4.7 występuje podatność, która pozwala zdalnym atakującym na spowodowanie odmowy usługi poprzez wykorzystanie nienormalnie zamkniętego połączenia, co prowadzi do nieskończonej pętli i blokowania połączeń.
- CVE-2015-3230Wysokie
Serwer katalogowy 389 (wcześniej Fedora Directory Server) przed wersją 1.3.3.12 nie egzekwuje preferencji nsSSL3Ciphers podczas tworzenia sslSocket, co pozwala zdalnym atakującym na wykorzystanie wyłączonego szyfru.
- CVE-2016-5405Krytyczne
Serwer katalogowy 389 w systemach Red Hat Enterprise Linux (Desktop, HPC Node, Server, Workstation) w wersjach 6 i 7 umożliwia zdalnym atakującym uzyskanie haseł użytkowników.
- CVE-2026-19404Średnie
W 389 Directory Server znaleziono usterkę. Operacje rozszerzone CleanAllRUV i Abort CleanAllRUV (utrzymanie replikacji) nie wykonują żadnej kontroli autoryzacji, co pozwala nieuwierzytelnionemu zdalnemu atakującemu na ich wywołanie, gdy nsslapd-allow-anonymous-access jest włączone (domyślnie), lub dowolnemu uwierzytelnionemu użytkownikowi z niskimi uprawnieniami w przeciwnym razie. Umożliwia to usunięcie identyfikatora repliki z metadanych replikacji, przeczyszczenie rekordów changelogu i przerwanie czyszczenia inicjowanego przez administratora, co może pozostawić replikację niespójną lub niedostępną.
- CVE-2026-15722Wysokie
W 389 Directory Server (389-ds-base) znaleziono przepełnienie bufora stosu w funkcji get_ruvelement_from_berval() w repl5_ruv.c. Zdalny nieuwierzytelniony atakujący może wysłać spreparowane żądanie StartNSDS50ReplicationRequest z polem replica ID zawierającym więcej niż 16 cyfr, powodując przepełnienie i awarię serwera LDAP.
- CVE-2026-11770Wysokie
W 389 Directory Server znaleziono podatność, w której nieuwierzytelniony zdalny atakujący może wstrzyknąć filtry wyszukiwania LDAP do operacji CleanAllRUV. Ponieważ zapytanie jest wykonywane z podwyższonymi uprawnieniami, atakujący może wydobyć poufne metadane konfiguracji serwera, w tym DN-y replikacji i informacje o schemacie haseł.
- CVE-2026-15041Niskie
W 389 Directory Server funkcja weryfikacji haseł PBKDF2-SHA256 używa standardowego memcmp() zamiast funkcji porównania o stałym czasie. Umożliwia to zdalnemu atakującemu potencjalne odtworzenie części informacji o skrócie poprzez pomiar czasu odpowiedzi na żądania LDAP bind.
Oryginalny opis (angielski, źródło NVD)
A flaw was found in 389 Directory Server. During SASL PLAIN authentication, the server installs connection-level bind credentials before performing the account-lock check. If the account is subsequently found to be locked, the bind is reported as failed to the client, but the already-installed authenticated state on the connection is not reverted. A client that supplies valid credentials for an account that has been administratively locked can continue to use the same connection with that account's privileges, defeating account lock as an access-revocation control.