Podatności Keycloak

W Keycloak, w komponencie keycloak-services, administrator domeny może użyć wildcarda (np. *.example.com) do ograniczenia rejestracji klientów. Z powodu nieprawidłowej walidacji system akceptuje dowolną nazwę hosta kończącą się na dany sufiks domeny, nawet jeśli nie jest to prawowita subdomena. Atakujący kontrolujący odwrotne DNS swojego połączenia może ominąć te ograniczenia i potencjalnie dokonać nieautoryzowanych modyfikacji klientów.

W Keycloak logika oceny polityk grupowych używa prostego sprawdzania prefiksu tekstowego do weryfikacji członkostwa w grupie, zamiast dokładnego dopasowania. Użytkownik należący do grupy o podobnej początkowej nazwie może ominąć zabezpieczenia i uzyskać nieautoryzowany dostęp do funkcji administracyjnych lub chronionych zasobów.

W komponencie RoleContainerResource w Keycloak, punkty końcowe admin REST API oparte na nazwach nie egzekwują prawidłowo kontroli autoryzacji podczas zarządzania rolami złożonymi. Delegowany administrator z uprawnieniami manage-realm może usunąć kluczowe role podrzędne z wbudowanych ról administracyjnych, potencjalnie zakłócając funkcje administracyjne w domenie.

Znaleziono błąd w mechanizmie wymuszania polityki klienta w Keycloak. Problem występuje, gdy system sprawdza członkostwo w grupie na podstawie nazwy zamiast unikalnego identyfikatora. Atakujący z uprawnieniami do zarządzania klientami może ominąć polityki bezpieczeństwa, dołączając do grupy o pasującej nazwie w innej części hierarchii grup, co potencjalnie pozwala na rejestrację lub aktualizację klientów bez przestrzegania wymaganych profili zabezpieczeń.

Keycloak umożliwia zarządzanie dostawcami tożsamości i organizacjami za pomocą API administracyjnego. Odkryto błąd, w którym administrator z uprawnieniami do zarządzania dostawcami tożsamości mógł połączyć nowego dostawcę z organizacją bez wymaganych uprawnień do zarządzania tą organizacją. Może to pozwolić nieautoryzowanemu administratorowi na wpływanie na to, jak użytkownicy logują się do określonych organizacji.

W bibliotece keycloak-services, będącej rdzeniem systemu zarządzania tożsamością i dostępem Keycloak, w punkcie końcowym role-users brakuje sprawdzenia, czy administrator ma uprawnienia do przeglądania poszczególnych użytkowników podczas wyświetlania członków roli. Ograniczony administrator może zobaczyć prywatne informacje, takie jak nazwy i adresy e-mail użytkowników, do których nie powinien mieć dostępu.

W Keycloak Admin REST API, używanym do zarządzania domenami bezpieczeństwa i klientami, podczas przetwarzania żądań dotyczących rotowanych sekretów klienta przechowywanych w bezpiecznym magazynie, delegowany administrator z uprawnieniami tylko do odczytu może pobrać rzeczywisty sekret zamiast symbolu zastępczego magazynu. Dzieje się tak z powodu niewłaściwego egzekwowania granic, co prowadzi do ujawnienia wrażliwych poświadczeń.

W Keycloak znaleziono błąd w endpoint REST default-groups oraz reprezentacji realm. Delegowany administrator z uprawnieniami do przeglądania realm może zobaczyć nazwy i identyfikatory ukrytych domyślnych grup, nawet jeśli nie ma do nich bezpośrednich uprawnień.

W REST API administracyjnym Keycloak wykryto brak autoryzacji podczas usuwania roli podrzędnej z roli złożonej. Delegowany administrator może usunąć uprzywilejowane role, do których nie ma uprawnień, co prowadzi do utraty dostępu dla innych użytkowników i administratorów.

W komponencie keycloak-services, będącym rdzeniem Red Hat Build of Keycloak, wykryto podatność polegającą na braku maskowania poufnych wartości konfiguracyjnych, takich jak tajne klucze reCAPTCHA, podczas ich wyświetlania administratorom z uprawnieniami tylko do odczytu. Może to prowadzić do ujawnienia poświadczeń usług zewnętrznych nieupoważnionym osobom lub w logach administracyjnych.

W Keycloak stwierdzono niekompletną poprawkę dla CVE-2026-9798. Ochrona przed atakami brute-force została dodana do procedury inicjacji CIBA, ale pominięto ją w procedurze wymiany tokenów. Pozwala to atakującemu z ważnymi danymi uwierzytelniającymi klienta uzyskać tokeny dostępu i odświeżania dla zablokowanego konta użytkownika, jeśli żądanie uwierzytelnienia zostało rozpoczęte przed blokadą i zatwierdzone przez użytkownika.

W Keycloak wykryto lukę w mechanizmie Client Policies, która umożliwia ominięcie wymogu uwierzytelniania za pomocą podpisanych asercji JWT. Atakujący posiadający prawidłowe dane logowania klienta może dostarczyć fałszywy, niepodpisany nagłówek asercji, oszukując system, że wymagania polityki zostały spełnione.

W komponencie keycloak-services Red Hat Build of Keycloak kody autoryzacyjne OAuth 2.0 nie są prawidłowo powiązane z klientem, który je pierwotnie zażądał. Atakujący, który przechwyci kod, może go zmodyfikować i zrealizować we własnym kliencie, uzyskując tokeny dostępu dla tożsamości ofiary.

W komponencie zarządzania organizacjami w Keycloak stwierdzono błąd. Delegowany administrator z uprawnieniami do zarządzania organizacjami może utworzyć zaproszenie dla nieistniejącego adresu e-mail, a następnie pobrać tajny link rejestracyjny bezpośrednio przez API. Używając tego linku, administrator może utworzyć nowe konta użytkowników i dodać je do organizacji bez wymaganych uprawnień do zarządzania użytkownikami ani dostępu do zaproszonego konta e-mail. Pozwala to administratorowi ominąć granice bezpieczeństwa i dodać nieautoryzowanych członków do organizacji.

W komponencie keycloak-services Keycloaka wykryto podatność polegającą na nieprawidłowej walidacji podczas aktualizacji dostawcy tożsamości OIDC przez delegowanego administratora. Gdy administrator używa maskowanej wartości zastępczej dla sekretu klienta, Keycloak ponownie wykorzystuje istniejący prawdziwy sekret, nawet jeśli zmieniono wrażliwe pola, takie jak URL tokena. Umożliwia to atakującemu przekierowanie i przechwycenie sekretu.

W Keycloak wykryto podatność w funkcji wyszukiwania grup w API administracyjnym. Gdy włączone są szczegółowe uprawnienia administracyjne (FGAP v2), delegowany administrator może ominąć ograniczenia dostępu i zobaczyć grupy nadrzędne, do których nie ma uprawnień. Wyszukując grupę podrzędną, system błędnie zwraca pełne dane grupy nadrzędnej, ujawniając wrażliwe atrybuty i konfigurację.

W Keycloak wykryto lukę w funkcji podglądu autoryzacji JWT. Gdy konto użytkownika jest wyłączone, system nie sprawdza jego statusu podczas przetwarzania grantu autoryzacyjnego JWT, co pozwala atakującemu na uzyskanie tokena dla wyłączonego użytkownika.

W pakiecie org.keycloak.broker.oidc wykryto błąd polegający na nieprawidłowej synchronizacji atrybutu email_verified. Gdy dostawca OIDC ma ustawione trustEmail=true i włączony jest endpoint userinfo, Keycloak pobiera adres email z odpowiedzi userinfo, ale status email_verified wyłącznie z id_token. Brak walidacji, czy email_verified w id_token dotyczy tego samego adresu email co z userinfo, pozwala na błędne oznaczenie dowolnego adresu email jako zweryfikowanego.

W implementacji Fine-Grained Admin Permissions (FGAP) v2 w Keycloak wykryto lukę, która pozwala delegowanemu administratorowi na przeglądanie szczegółów podgrup, do których nie ma bezpośredniego dostępu. Problem występuje, gdy system nie filtruje poprawnie podgrup na podstawie uprawnień wywołującego przy żądaniu przez grupę nadrzędną.

W Keycloak znaleziono podatność w komponencie ClientResource usług administracyjnych, gdy włączone są szczegółowe uprawnienia administracyjne (FGAP) v2. Umożliwia ona delegowanemu administratorowi, który powinien mieć ograniczoną kontrolę nad konkretnymi klientami, dołączanie lub usuwanie ukrytych zakresów klienta, do których nie ma autoryzacji.

W interfejsie administracyjnym Keycloak wykryto podatność, która umożliwia administratorom z ograniczonymi uprawnieniami podgląd informacji o grupach, do których nie powinni mieć dostępu. Gdy włączone są nowe szczegółowe uprawnienia administracyjne (FGAP v2), administrator widzący konkretną rolę może również zobaczyć listę wszystkich grup przypisanych do tej roli, bez weryfikacji uprawnień do tych grup. Pozwala to na ujawnienie ukrytych grup oraz ich szczegółów, takich jak nazwy wewnętrzne i ustawienia niestandardowe, które mogą zawierać wrażliwe informacje o wdrożeniu.

W Keycloak wykryto podatność, która pozwala użytkownikowi z uprawnieniem `manage-clients` na wstrzyknięcie twardo zakodowanego mapowania ról do dowolnego klienta. Działanie to umożliwia ominięcie istniejących ograniczeń zakresu i dodanie roli `realm-admin` do generowanych tokenów, co prowadzi do eskalacji uprawnień i pełnego dostępu administracyjnego do realm.

W Keycloak Admin UI wykryto podatność, która pozwala administratorom z ograniczonymi uprawnieniami na ominięcie zabezpieczeń. Gdy włączone są szczegółowe uprawnienia administracyjne (FGAPv2), administrator mający jedynie prawo wyszukiwania użytkowników może użyć endpointu 'brute-force-user', aby uzyskać pełny profil użytkownika, w tym wrażliwe dane i metadane bezpieczeństwa. Problem wynika z braku weryfikacji uprawnienia 'view' dla konkretnego użytkownika przy użyciu tej ścieżki wyszukiwania.

W komponencie mapowania dostawcy tożsamości (IdP) w Keycloak wykryto podatność, która pozwala administratorowi z ograniczonymi uprawnieniami na przypisanie sobie lub innym użytkownikom wysokopoziomowych ról administracyjnych (np. realm-admin) poprzez utworzenie mapowania „Hardcoded Role”. Umożliwia to ominięcie kontroli bezpieczeństwa i przejęcie pełnej kontroli nad całym realmem.

W Keycloak wykryto podatność polegającą na pomyleniu algorytmu JWT w przepływie JWT Authorization Grant. Umożliwia ona atakującemu posiadającemu ważne dane uwierzytelniające klienta ominięcie weryfikacji podpisu poprzez sfałszowanie asercji.

W Keycloak Policy Enforcer wykryto lukę, która pozwala każdemu uwierzytelnionemu użytkownikowi ominąć wszystkie polityki autoryzacji, w tym sprawdzanie ról, zakresów i uprawnień UMA. Poprzez dodanie ścieżki strony odmowy dostępu do URL żądania (jako segment ścieżki lub parametr zapytania) atakujący może uzyskać nieautoryzowany dostęp do chronionych zasobów.

Znaleziono lukę w komponencie autoryzacji Keycloak. Uwierzytelniony użytkownik posiadający bilet UMA dla jednego zasobu może ominąć kontrolę dostępu dla wszystkich zasobów tego samego typu na serwerze zasobów, używając odpowiedniego prefiksu żądania uprawnień. Podatność wymaga trybu PERMISSIVE polityki egzekwowania oraz włączenia opcji ownerManagedAccess dla typowanych zasobów bez jawnej polityki ochrony.

W usłudze rejestracji klientów Keycloak wykryto lukę, która pozwala zdalnemu atakującemu z wcześniej wydanym tokenem RAT na ponowne włączenie klienta wyłączonego przez administratora. Atakujący może zresetować sekret klienta i potencjalnie odzyskać uprzywilejowany dostęp do API.

W Keycloak wykryto brak autoryzacji w punkcie końcowym GroupResource.addChild() w Admin REST API. Uwierzytelniony użytkownik z ograniczonymi uprawnieniami administracyjnymi może przepiąć dowolną istniejącą grupę, w tym grupę z rolą realm-admin, pod swoją zarządzaną grupę, gdy włączone jest FGAPv2.

W Keycloak wykryto podatność, która pozwala zdalnemu atakującemu z uprawnieniami administracyjnymi (posiadającemu uprawnienie `manage-client` lub dostęp do punktów końcowych rejestracji klientów) na ominięcie walidacji URI klienta. Atakujący może zarejestrować złośliwego klienta z odpowiednio spreparowanym URI przekierowania, używając schematów `javascript:` lub `data:` bez uwzględniania wielkości liter, co prowadzi do podatności na Cross-Site Scripting (XSS).

W Keycloak wykryto podatność, w której administrator realm z rolą 'manage-realm' może podać dowolną ścieżkę systemu plików jako parametr keystore podczas tworzenia komponentu dostawcy kluczy. Umożliwia to sprawdzenie, które pliki istnieją i są odczytywalne przez proces Keycloak.

Zgłoszona podatność została odrzucona, ponieważ opisane zachowanie nie stanowi eskalacji uprawnień. Atakujący musi już posiadać rolę administracyjną manage-realm w kliencie realm-management, która z założenia jest równoważna roli realm-admin. Importowanie użytkowników z mapowaniem roli realm-admin przez endpoint POST /admin/realms/{realm}/partialImport nie przyznaje dodatkowych uprawnień.

W org.keycloak.services administrator z delegowanym dostępem do odczytu członkostw grup i użytkowników może ominąć uprawnienia profilu użytkownika, uzyskując dostęp do endpointu członków grupy, co pozwala na wyświetlenie atrybutów użytkownika, które są jawnie zabronione.

W Keycloak wykryto podatność, która przy włączonej opcji revokeRefreshToken=true i użyciu trwałego przechowywania sesji, umożliwia atakującemu ponowne użycie unieważnionego tokena odświeżania po restarcie serwera. Atakujący, który wcześniej przechwycił token odświeżania ofiary, może uzyskać nieautoryzowany dostęp do jej konta.

W Keycloak wykryto podatność umożliwiającą atakującemu z wysokimi uprawnieniami (np. administratorowi domeny konfigurującemu złośliwy serwer LDAP lub osobie atakującej kompromitującej nadrzędny serwer LDAP) wywołanie błędu OutOfMemoryError poprzez wysłanie nieprawidłowej odpowiedzi polityki haseł LDAP podczas żądania uwierzytelnienia. Prowadzi to do zatrzymania maszyny wirtualnej Java (JVM) Keycloak i odmowy usługi (DoS) dla wszystkich domen na zaatakowanym węźle.

W Keycloak wykryto podatność w funkcji Fine-Grained Admin Permissions (FGAPv2). Administrator z ograniczonymi uprawnieniami do zarządzania klientami może przypisać dowolną rolę realm, w tym wysoce uprzywilejowane, do mapowania zakresu klienta. Obejście to pozwala na wstrzyknięcie roli do tokena uwierzytelniającego użytkownika.

W Keycloak wykryto podatność, która umożliwia uwierzytelnionemu użytkownikowi z członkostwem w organizacji ujawnienie metadanych organizacji w tokenach OIDC lub poprzez API konta, nawet po wyłączeniu funkcji Organizacji przez administratora. Może to prowadzić do błędnych decyzji autoryzacyjnych na serwerach zasobów.

W Keycloak wykryto błąd, w którym dowód weryfikacji krzyżowej sesji jest kluczowany tylko przez (localUserId, idpAlias) i nie jest powiązany z rzeczywistą tożsamością upstream. Drugie konto upstream na tym samym IdP może skonsumować dowód i zostać połączone z lokalnym kontem ofiary.

W Keycloak wykryto podatność na fiksację sesji w endpointach logowania. Nieuwierzytelniony atakujący może stworzyć sesję uwierzytelniającą i nakłonić ofiarę do kliknięcia spreparowanego linku, co pozwala na przejęcie formularza wymaganych akcji bez znajomości jej danych logowania. Udane wykorzystanie może prowadzić do całkowitego przejęcia konta, w tym kont administracyjnych.

W Keycloak wykryto podatność w logice walidacji URL podczas operacji przekierowań. Poprzez spreparowanie złośliwego żądania atakujący może ominąć walidację i przekierować użytkowników na nieautoryzowane adresy URL, co może prowadzić do ujawnienia wrażliwych informacji w domenie lub ułatwić dalsze ataki. Podatność dotyczy klientów Keycloak skonfigurowanych z symbolem wieloznacznym (*) w polu "Valid Redirect URIs" i wymaga interakcji użytkownika.

W Keycloak wykryto podatność, która pozwala zdalnemu, nieuwierzytelnionemu atakującemu na wysłanie specjalnie spreparowanego wejścia XML do punktu końcowego SAML. Może to spowodować wysokie zużycie CPU i wygłodzenie wątków roboczych, prowadząc do odmowy usługi (DoS) i uniemożliwienia dostępu do serwera.

W Keycloak wykryto błąd, w którym przy jednoczesnym skonfigurowaniu polityk unieważniania `notBefore` na poziomie realm i klienta, funkcja OIDC Introspection nie honoruje polityki realmowej. Tokeny, które powinny być unieważnione, pozostają aktywne.

Uwierzytelniony użytkownik może ominąć skonfigurowane polityki WebAuthn podczas rejestracji poświadczeń poprzez manipulację JavaScript po stronie klienta. Serwer nie sprawdza, czy parametry nowego poświadczenia (np. algorytmy klucza publicznego) są zgodne z politykami WebAuthn domeny.

W Keycloak wykryto lukę, która pozwala uwierzytelnionemu użytkownikowi z rolą uma_protection na ominięcie walidacji zasad User-Managed Access (UMA). Atakujący może w żądaniu utworzenia polityki podać identyfikatory zasobów należących do innych użytkowników, nawet jeśli ścieżka URL wskazuje na jego własny zasób. Umożliwia to uzyskanie nieautoryzowanego dostępu do wrażliwych danych lub wykonanie nieuprawnionych działań.

W Keycloak wykryto podatność, która pozwala nieuwierzytelnionemu atakującemu na przeprowadzenie ataku DoS poprzez wysłanie specjalnie spreparowanego żądania POST z nadmiernie długim parametrem scope do punktu końcowego tokena OIDC. Powoduje to wysokie zużycie zasobów i wydłużony czas przetwarzania, prowadząc do odmowy usługi.

W Keycloak wykryto lukę w SingleUseObjectProvider, globalnym magazynie klucz-wartość, który nie zapewnia odpowiedniej izolacji typów i przestrzeni nazw. Umożliwia to nieuwierzytelnionemu atakującemu fałszowanie kodów autoryzacyjnych.

W Keycloak wykryto podatność umożliwiającą atakującemu kontrolującemu inną ścieżkę na tym samym serwerze WWW ominięcie dozwolonej ścieżki w przekierowaniach URI używających symbolu wieloznacznego. Udany atak może prowadzić do kradzieży tokena dostępu i ujawnienia informacji.

W Keycloak wykryto podatność SSRF. Uwierzytelniony atakujący może manipulować parametrem `client_session_host` podczas odświeżania tokenów, co pozwala na wysyłanie żądań HTTP z kontekstu sieciowego serwera Keycloak. Problem występuje, gdy klient Keycloak jest skonfigurowany z `backchannel.logout.url` zawierającym placeholder `application.session.host`.

W Keycloak, rozwiązaniu do zarządzania tożsamością i dostępem, zidentyfikowano błąd polegający na niewłaściwym śledzeniu przekierowań HTTP podczas przetwarzania określonych żądań konfiguracji klientów. Umożliwia to atakującemu oszukanie serwera, aby ten wysyłał niezamierzone żądania do wewnętrznych lub zastrzeżonych zasobów.

W Keycloak wykryto lukę umożliwiającą zdalnemu atakującemu ominięcie kontroli bezpieczeństwa poprzez wysłanie prawidłowej odpowiedzi SAML z zewnętrznego dostawcy tożsamości (IdP) do punktu końcowego SAML Keycloak dla logowań brokerskich inicjowanych przez IdP. Pozwala to na zalogowanie się nawet wtedy, gdy dostawca SAML jest wyłączony.