CVE-2026-18922 w 389 Directory Server to nie proste pominięcie logowania. Problem pojawia się, gdy stan po nieudanej próbie uwierzytelnienia nie zostaje wyczyszczony, a późniejszy, niezależny bind na tym samym połączeniu wykorzystuje pozostawioną identity. Red Hat opisuje wariant wprost: zdalny, nieuwierzytelniony atakujący wysyła SASL PLAIN bind jako cn=Directory Manager z błędnym hasłem, a następnie SASL ANONYMOUS bind na tym samym connection — stale identity (auxiliary property Cyrus SASL) zostaje zainstalowane jako aktywna tożsamość. Efekt: Directory Manager authority bez poprawnych credentials. CVSS 9.8.
Złamana security property
Oczekiwana właściwość to nie „błędne hasło powoduje failure” (ta jest spełniona), lecz: identity z nieudanego attempt nie może wpływać na żaden kolejny attempt na tym samym connection. Gdyby ktoś patrzył tylko na event log pierwszego bindu, uznałby, że control zadziałał — problem ujawnia się w całym lifecycle connection. Dlatego testowanie controls musi obejmować transitions between states, nie pojedyncze request/response. Wariant z SASL ANONYMOUS przesuwa prerequisites z „valid low-priv account required” do „no valid account required” (stąd realne PR:N) — variant analysis zmienił severity bez zmiany root cause.
Deterministyczna mitigation
Red Hat: ograniczyć nsslapd-allowed-sasl-mechanisms do wymaganych i wykluczyć PLAIN. Działa, bo chain potrzebuje pierwszego kroku (failed SASL PLAIN bind jako Directory Manager) — bez PLAIN atakujący nie zasadzi stale identity. To jakościowo inny control niż WAF/rate limiting/monitoring: usuwamy wymagany primitive. Model: affected version: YES, SASL PLAIN: DISABLED, known exploit path: BLOCKED, root cause patched: NO → status: MITIGATED (nie permanent False Positive).
Machine-verifiable i backporty
Weryfikacja nie przez deklarację: odczyt rzeczywistego nsslapd-allowed-sasl-mechanisms na każdym node, runtime test że PLAIN nie jest negocjowany, rewalidacja po zmianach, ochrona przed powrotem PLAIN przez template/config management. Red Hat backportuje — nie używaj upstream_version >= X, lecz vendor advisory + installed RPM NEVRA + product stream (to też ogranicza false positives skanerów porównujących upstream strings).
Compromise assessment
Jeśli serwer był osiągalny dla nieufnych sieci, PLAIN dozwolony i system podatny — warto rozważyć: nietypowe sekwencje failed PLAIN bind → subsequent successful bind na tym samym connection, ANONYMOUS binds poprzedzone próbą Directory Manager, zmiany z Directory Manager authority, nietypowe ACL/entries, tworzenie privileged accounts. Brak takiej sekwencji w krótkich logach nie dowodzi czystości przy ograniczonym retention. Brak potwierdzonej active exploitation — nie zamieniaj Critical na „actively exploited”.
Wniosek
CVE-2026-18922 pokazuje, że authentication vulnerability może istnieć pomiędzy dwoma poprawnie wyglądającymi events. Dojrzały VE modeluje state transitions, connection lifetime i cleanup security-sensitive state: authentication failure jest bezpieczny tylko wtedy, gdy usuwa cały state, który nie powinien przeżyć do kolejnej próby.
Powiązane na blogu
- APITable: fail-open authorization — semantyka stanu bezpieczeństwa
- Impala: integralność finalnej tożsamości — najsłabszy etap auth
Źródła
- Red Hat — CVE-2026-18922 — access.redhat.com
- GitHub Advisory Database — GHSA-pr87-24g5-hphv — github.com/advisories
Nota redakcyjna: stan informacji 8 września 2026. CVE-2026-18922 (389 Directory Server, CVSS 9.8): stale SASL identity po nieudanym bind daje Directory Manager przez kolejny SASL ANONYMOUS. Deterministyczna mitigation: wyłączenie PLAIN w nsslapd-allowed-sasl-mechanisms. Artykuł koncentruje się na testowaniu state transitions i różnicy Mitigated vs Fixed.