CVE-2026-46619

OpenAM od wersji 13.0.0 do 16.1.2 ma podatność na odbity XSS w endpointzie OAuth2 authorize z parametrem display=wap. Strona zgody odzwierciedla wartości pochodzące z żądania bez kodowania HTML, co pozwala atakującemu na wykonanie JavaScriptu w kontekście OpenAM, kradzież sesji lub ciasteczek, ujawnienie tokenów CSRF i działania z uprawnieniami ofiary. Wymagany jest co najmniej jeden zarejestrowany klient OAuth2, ale atakujący nie musi go kontrolować.

W OpenAM domyślna konfiguracja inicjalizuje ciasteczko SSO iPlanetDirectoryPro z wyłączonym HttpOnly i bez ochronnego domyślnego SameSite, a przepływy zgody OAuth i OpenID Connect używają tego ciasteczka przez CsrfProtection jako tokenu CSRF. W połączeniu z XSS w tej samej domenie i kliknięciem przez użytkownika linku kontrolowanego przez atakującego ciasteczko może zostać odczytane i użyte do kradzieży sesji SSO oraz realizacji zgód zainicjowanych przez atakującego. Problem naprawiono w wersji 16.1.1.

W OpenAM ścieżka uwierzytelniania klienta private_key_jwt używa ClientJwksResolverCache bez niezawodnego powiązania buforowanego resolvera jwks_uri i zweryfikowanego asercji z oczekiwanym clientID w ClientCredentialsReader. Atakujący kontrolujący dowolnego zarejestrowanego klienta z opublikowanymi kluczami, w tym uzyskanego przez otwartą rejestrację dynamiczną, może uwierzytelnić się jako inny klient, którego klucze są udostępnione przez jwks_uri, i wystawiać tokeny w jego imieniu w różnych realmach w tym samym procesie OpenAM. Problem naprawiono w wersji 16.1.1.

W OpenAM GroovySandboxValueFilter pozwala uwierzytelnionemu autorowi skryptów po stronie serwera na ucieczkę z sandboxa pomimo domyślnych list dozwolonych i zabronionych klas. Użytkownik taki jak RealmAdmin podrealm, który może tworzyć lub edytować skrypty w kontekście wykonywanym, może wywoływać polecenia systemu operacyjnego jako konto serwera aplikacji OpenAM, przekraczając granicę administracji realmem i kompromitując JVM oraz wszystkie obsługiwane realmy. Problem naprawiono w wersji 16.1.1.

W OpenAM moduł uwierzytelniania OAuth2 aktualizuje istniejące konto lokalne atrybutami profilu, które mogą zawierać userPassword i inetUserStatus, przepisując hasło na nazwę użytkownika i reaktywując wyłączone konta. Brak filtrowania OAuth.removeRestrictedAccountUpdateAttributes pozwala tym polom poświadczeń i statusu dotrzeć do aktualizacji konta. Przy włączonym tworzeniu kont powtarzane logowanie OAuth powoduje, że domyślny łańcuch ldapService akceptuje nazwę użytkownika jako identyfikator i hasło, co pozwala nieuwierzytelnionemu atakującemu przejąć konto lokalne bez interakcji z dostawcą tożsamości. Problem naprawiono w wersji 16.1.1.

W OpenAM OAuthTokenStore odczytuje identyfikatory tokenów dostarczone przez wywołującego ze wspólnego Core Token Store (CTS) bez przestrzeni nazw przeznaczonej tylko dla OAuth, a OAuthAdapter akceptuje wiersz, którego BLOB rzekomo zawiera token OAuth, bez powiązania zaufanego typu CTS i weryfikacji integralności. Atakujący, który może umieścić kontrolowany JSON w CTS pod znanym identyfikatorem tokenu, na przykład przez Push Registration, a następnie anonimowe wywołanie zwrotne SNS w włączonym realmie, może wygenerować tokeny bearer OAuth i tokeny ID OpenID Connect z wybranym podmiotem, klientem, realmem i zakresem. Problem naprawiono w wersji 16.1.1.

W OpenAM anonimowe wywołanie zwrotne SNS Push Notification obsługiwane przez SnsMessageResource po wygaśnięciu messageId z dyspozytora w pamięci sięga do predykatu blob CTS, traktuje klucze najwyższego poziomu blob jako nazwy klas Java dla Class.forName i deserializuje kontrolowany przez atakującego JSON przez Jackson. Użytkownik o niskich uprawnieniach, który rozpocznie Push Registration i uzyska messageId, wspólny sekret i wyzwanie, może poczekać na wygaśnięcie, zastąpić trwały blob przez anonimowe wywołania zwrotne i wywołać ładowanie i konstrukcję klas w JVM OpenAM. Problem naprawiono w wersji 16.1.1.

W OpenAM SessionRequestHandler w punkcie końcowym zarządzania sesjami nie wymusza kontroli własności ani uprawnień, gdy użytkownik o niskich uprawnieniach odpytuje informacje o sesji w środowiskach z stanowym przechowywaniem sesji. Wnioskujący znający identyfikator tożsamości celu może pobrać aktywne poświadczenia sesji innego użytkownika, w tym konta o wyższych uprawnieniach, i użyć ich do przejęcia tej sesji. Problem naprawiono w wersji 16.1.1.

W OpenAM w wersjach przed 16.1.1 niektóre punkty końcowe federacji w niedomyślnej konfiguracji klastrowej niekonsekwentnie kodują parametry dostarczane przez użytkownika, renderowane do HTML w ścieżce przekierowania cookie-hash SAML2. Nieuwierzytelniony atakujący może nakłonić użytkownika do otwarcia spreparowanego żądania i wykonania skryptu w domenie OpenAM. Problem naprawiono w wersji 16.1.1.

W OpenAM w wersjach przed 16.1.1 punkt końcowy autoryzacji OAuth 2.0 i OpenID Connect nie koduje wystarczająco parametrów dostarczanych przez użytkownika, zanim szablony FormPostResponse.ftl i checkSession.ftl wyrenderują je do HTML w trybie odpowiedzi form_post. Nieuwierzytelniony atakujący może nakłonić użytkownika do otwarcia spreparowanego żądania autoryzacji i wykonania skryptu w domenie OpenAM. Problem naprawiono w wersji 16.1.1.