Na Kapitanie niejednokrotnie pisaliśmy o systemach Identity and Access Management, zarówno w kontekście ich roli w organizacji, jak i podatności oraz błędów związanych z mechanizmami zarządzania dostępem. W jednym z wcześniejszych materiałów wyjaśnialiśmy między innymi różnice pomiędzy Identity Management i Access Management, a przy innej okazji opisywaliśmy podatność w Google Cloud Run związaną z niewłaściwym użyciem IAM.

Autor: 5 min czytania

Keycloak jest właśnie rozwiązaniem z obszaru IAM. To otwartoźródłowa platforma wykorzystywana do centralnego zarządzania uwierzytelnianiem i dostępem użytkowników. Obsługuje między innymi SSO, MFA, resetowanie haseł oraz integrację z LDAP i Active Directory.

W sierpniu 2026 roku pojawiły się informacje o krytycznej podatności w Keycloak, oznaczonej jako CVE-2026-18963. Luka ta dotyczy mechanizmu reset-credentials i pozwala nieuwierzytelnionemu atakującemu ominąć etap wymagający potwierdzenia resetu hasła za pomocą linku przesłanego e-mailem, a następnie przejść do ustawienia nowych poświadczeń dla konta ofiary. Red Hat ocenił podatność na 9.1 w skali CVSS 3.1.

Jak działa reset hasła w Keycloak?

W standardowym scenariuszu użytkownik wybiera funkcję Forgot password, podaje login lub adres e-mail, a Keycloak rozpoczyna proces odzyskiwania konta.

System wysyła wiadomość zawierającą link pozwalający potwierdzić żądanie. Dopiero po poprawnym przejściu tej weryfikacji użytkownik powinien otrzymać możliwość ustawienia nowego hasła.

W uproszczeniu cały proces wygląda więc następująco:

Forgot password → żądanie resetu → wiadomość e-mail → potwierdzenie linku → ustawienie nowego hasła

Kluczowe znaczenie ma tutaj kontrola stanu procesu. Keycloak musi wiedzieć, że użytkownik rzeczywiście przeszedł wymagane wcześniejsze etapy, zanim dopuści go do zmiany poświadczeń. W przypadku CVE-2026-18963 właśnie ten element okazał się wadliwy.

Red Hat wskazuje, że przyczyną podatności jest nieprawidłowa walidacja stanu w procesie reset-credentials. Odpowiednio przygotowane żądanie może pozwolić nieuwierzytelnionemu atakującemu na przejście do etapu zmiany hasła bez wcześniejszego potwierdzenia żądania za pomocą linku przesłanego e-mailem.

Nie chodzi więc o przechwycenie wiadomości, złamanie tokenu resetującego ani uzyskanie dostępu do skrzynki pocztowej ofiary. Problem znajduje się po stronie logiki serwera i sposobu, w jaki Keycloak sprawdza, czy kolejne etapy procesu zostały rzeczywiście wykonane.

Właśnie z tego powodu podatność ma tak wysoki poziom krytyczności. Atak może zostać przeprowadzony zdalnie, bez wcześniejszego uwierzytelnienia i bez interakcji użytkownika. W przypadku powodzenia atakujący jest w stanie ustawić nowe poświadczenia dla wybranego konta i przejąć nad nim kontrolę.

Jakie mogą być skutki?

Znaczenie skutecznego wykorzystania CVE-2026-18963 zależy przede wszystkim od uprawnień przejętego użytkownika. Jeżeli Keycloak pełni rolę centralnego dostawcy uwierzytelniania dla wielu usług, jedno konto może zapewniać dostęp do większej części środowiska. Szczególnie poważny scenariusz dotyczy kont uprzywilejowanych, posiadających dostęp administracyjny do aplikacji lub innych elementów infrastruktury.

Nie należy również automatycznie zakładać, że obecność drugiego składnika uwierzytelniania całkowicie eliminuje skutki podatności. Zachowanie procesu odzyskiwania poświadczeń zależy od konfiguracji Reset Credentials flow oraz wymaganych akcji skonfigurowanych w danym realmie. W praktyce oznacza to, że wpływ CVE-2026-18963 może różnić się pomiędzy środowiskami.

Poprawione wersje

Poprawki dla CVE-2026-18963 zostały opublikowane zarówno dla Red Hat Build of Keycloak, jak i upstreamowego Keycloak.

Wśród wydań zawierających poprawkę znajdują się między innymi:

  • Red Hat Build of Keycloak 26.4.15
  • Red Hat Build of Keycloak 26.6.6
  • Keycloak 26.7.2

W informacji o wydaniu Keycloak 26.7.2 poprawka została opisana jako CVE-2026-18963 Unauthenticated account takeover via reset-credentials flow bypass.

Podsumowanie

CVE-2026-18963 jest dobrym przykładem podatności, która nie wynika z przełamania kryptografii ani błędu w samym mechanizmie generowania tokenu resetującego. Problem pojawia się wcześniej – w logice procesu i sposobie, w jaki system weryfikuje, czy użytkownik rzeczywiście przeszedł wszystkie wymagane etapy odzyskiwania konta.

W efekcie atakujący może ominąć etap potwierdzenia resetu hasła i przejść do ustawienia nowych poświadczeń. W przypadku systemu takiego jak Keycloak, który może znajdować się w centralnym punkcie infrastruktury uwierzytelniania, skutki przejęcia pojedynczego konta mogą wykraczać daleko poza jedną aplikację.