CVE-2026-123539

OpenAM przed wersją 16.1.4 zawiera wbudowane tożsamości w Top Level Realm (demo, anonymous, wsc, wsp, SecurityTokenService i agentAuth) z hasłami identycznymi w każdej instalacji, publicznie znanymi i umożliwiającymi uwierzytelnienie. Nieuwierzytelnieni zdalni atakujący mogą zalogować się jako te tożsamości, uzyskując sesje uwierzytelnione, a tożsamości agentów mogą odczytać konfigurację innych profili agentów.

OpenAM przed wersją 16.1.4 zawiera podatność typu server-side request forgery w sprawdzaniu CRL certyfikatów, które pobiera CRL z punktu dystrybucji wskazanego w przedstawionym certyfikacie bez ograniczania miejsca docelowego i weryfikacji podpisu pobranego CRL. Atakujący posiadający certyfikat z zaufanego łańcucha CA może zmusić OpenAM do żądań do wewnętrznych hostów, przechwycić skonfigurowane dane uwierzytelniające aktualizacji CRL, nadpisać przechowywane dane unieważnienia, aby zablokować uwierzytelnianie certyfikatów dla tego CA, oraz zajmować wątki uwierzytelniania.

OpenIdentityPlatform OpenAM przed wersją 16.1.4 zawiera podatność typu open redirect, ponieważ wylogowanie WS-Federation, wylogowanie SAML v2.0 i zarządzanie identyfikatorami nazw, wyszukiwarka dostawców tożsamości SAML v2.0 oraz niektóre strony uwierzytelniania nie sprawdzają adresów URL miejsca docelowego względem list dozwolonych. Atakujący mogą tworzyć linki w domenie OpenAM, które kierują użytkowników do dowolnych zewnętrznych witryn w celu phishingu.

OpenAM przed wersją 16.1.4 zawiera podatność typu open redirect, która pozwala atakującym przekierowywać użytkowników do zewnętrznych witryn, ponieważ parametr RelayState nie jest sprawdzany, gdy nie skonfigurowano relayStateUrlList. Atakujący mogą tworzyć linki do logowania jednokrotnego ze złośliwym parametrem RelayState, aby kierować użytkowników z zaufanego źródła OpenAM do witryn phishingowych i omijać filtry URL.

OpenAM przed wersją 16.1.4 zawiera podatność typu open redirect i cross-site scripting, która pozwala zdalnym atakującym kontrolować miejsca docelowe po logowaniu i wylogowaniu za pomocą parametrów goto i gotoOnFail. Atakujący mogą tworzyć linki logowania lub wylogowania OpenAM, które przekierowują ofiary do witryn phishingowych lub uruchamiają skrypt w XUI w celu kradzieży ciasteczek sesji.

OpenAM od wersji 14.5.1 przed 16.1.4 zawiera podatność typu cross-site request forgery w przepływie autoryzacji urządzenia OAuth 2.0, która pozwala atakującym zatwierdzać kody urządzeń, gdy zgoda jest pomijana dla klientów z domniemaną zgodą. Atakujący może rozpocząć autoryzację urządzenia i zwabić zalogowanego użytkownika na spreparowaną stronę, uzyskując tokeny dostępu i identyfikacji do wywoływania API w imieniu tego użytkownika.

OpenAM przed wersją 16.1.4 i jego zestaw SDK klienta nie weryfikują wystarczająco odpowiedzi na wewnętrznym kanale SOAP serwer-serwer, co pozwala atakującym z pozycji sieciowej wpływać na integralność i dostępność. Atakujący, którzy przechwycą niezaszyfrowany ruch lub kontrolują serwer witryny, mogą spowodować awarię procesów odbierających, manipulować plikami z prawem zapisu i prawdopodobnie wykonać kod.

OpenAM w wersjach przed 16.1.4 zawiera podatność typu denial of service, która pozwala nieuwierzytelnionym atakującym wyczerpać zasoby serwera poprzez wysyłanie serializowanych danych Java bez ograniczeń rozmiaru i struktury. Atakujący może wysyłać małe spreparowane żądania do zdalnych punktów końcowych SDK, klasycznych stron logowania lub konsoli administracyjnej, aby zablokować uwierzytelnianie, walidację sesji i decyzje polityk.

OpenAM przed wersją 16.1.4 nie wymusza PKCE w przepływie autoryzacji urządzenia OAuth 2.0, nigdy nie weryfikując code verifier podczas wymiany kodów urządzenia na tokeny. Atakujący, którzy uzyskają zatwierdzony kod urządzenia z logów klienta lub współdzielonego magazynu urządzenia, mogą wymienić go na tokeny dostępu i identyfikacji, aby podszyć się pod użytkownika.

OpenAM przed wersją 16.1.4 zawiera podatność typu open redirect, która pozwala zdalnym atakującym przekierowywać użytkowników po logowaniu jednokrotnym SAML 1.x poprzez wykorzystanie luźnego dopasowania miejsca docelowego zaufanego partnera. Atakujący mogą tworzyć linki do /SAMLAwareServlet lub /SAMLPOSTProfileServlet z hostem docelowym przypominającym zaufanego partnera, aby kierować uwierzytelnionych użytkowników do witryn phishingowych kontrolowanych przez atakującego.