CVE-2025-13591

Podatność XXE w funkcji przepływu XACML w WSO2 Identity Server 5.1.0 przed WSO2-CARBON-PATCH-4.4.0-0231 pozwala zdalnym uwierzytelnionym użytkownikom z dostępem do funkcji XACML na odczyt dowolnych plików, wywołanie odmowy usługi, przeprowadzenie ataków SSRF lub inne nieokreślone skutki poprzez spreparowane żądanie XACML.

W podatności CVE-2016-4311 występuje luka CSRF w funkcji przepływu XACML w WSO2 Identity Server 5.1.0, która pozwala zdalnym atakującym na przejęcie uwierzytelnienia uprzywilejowanych użytkowników dla żądań przetwarzających żądania XACML.

Podatność dotyczy wdrożeń WSO2 Identity Server skonfigurowanego jako Resident Key Manager z udostępnianiem bazy danych. W takim środowisku samodzielnie zarejestrowany użytkownik może uzyskać dostęp do System REST APIs WSO2 API Manager poprzez token z endpointu tokenów WSO2 Identity Server.

W WSO2 Identity Server z magazynem użytkowników nieczułym na wielkość liter i bazą danych czułą na wielkość liter mogą wystąpić niezgodności w obsłudze wielkości liter nazw użytkowników. Powoduje to, że operacje unieważniania tokenów OAuth nie identyfikują poprawnie nazw z mieszaną wielkością liter, przez co tokeny nie są unieważniane.

WSO2 Identity Server nie egzekwuje domyślnego czasu wygaśnięcia dla SMS-owych haseł jednorazowych (OTP) używanych w MFA. Nieużywane OTP pozostają ważne bezterminowo, co umożliwia atakującym przeprowadzanie ataków brute force przez wielokrotne zgadywanie kodu. Udany atak może prowadzić do obejścia MFA i przejęcia konta użytkownika.

Interfejs REST API do zarządzania typami sekretów nie izoluje poprawnie kontroli dostępu podczas usuwania typu sekretu. Logika kaskadowego usuwania nie przestrzega granic organizacyjnych, co prowadzi do usunięcia sekretów powiązanych z tym typem we wszystkich organizacjach. Eksploatacja może spowodować niezamierzone usunięcie sekretów w całym wdrożeniu, prowadząc do awarii konfiguracji, przerw w działaniu usług i warunków typu denial-of-service.

Gdy włączone jest logowanie wieloatrybutowe, interfejs logowania nie maskuje konsekwentnie istnienia kont użytkowników. Dla prawidłowych użytkowników serwer wyświetla ich kanoniczną nazwę użytkownika, a dla nieistniejących odsyła oryginalne dane wejściowe. Dzieje się tak niezależnie od konfiguracji validate_username. Ujawnienie prawidłowych nazw użytkowników zwiększa ryzyko ataków brute force, inżynierii społecznej i ukierunkowanego wycieku informacji.

Proces personifikacji użytkownika w WSO2 Identity Server nie zarządza poprawnie tokenami odświeżania związanymi z sesjami personifikowanymi. Pozwala to atakującemu, który uzyskał token dostępu dla personifikowanego użytkownika, wykorzystać grant tokena odświeżania do uzyskania nowych tokenów dostępu, przedłużając możliwość działania jako prawowity użytkownik. Atakujący może w ten sposób kontynuować działania w imieniu rzeczywistego użytkownika, kompromitując integralność logów i utrudniając śledzenie działań.

Nieużywane kody autoryzacyjne wydane usuniętym użytkownikom nie są prawidłowo unieważniane ani usuwane z systemu, co pozwala na ich potencjalne ponowne użycie. Jeśli atakujący posiada zarówno kod autoryzacyjny, jak i powiązane dane klienta (ID i sekret), może uzyskać tokeny dostępu w imieniu usuniętych użytkowników, co prowadzi do nieautoryzowanego dostępu do zasobów.

Mechanizm blokady konta nie uruchamia się, gdy dodatkowe magazyny użytkowników są niedostępne. Oprogramowanie nie utrzymuje spójnego stanu blokady, jeśli nie może osiągnąć wszystkich skonfigurowanych magazynów, co pozwala atakującemu na wielokrotne próby uwierzytelnienia z nieprawidłowymi danymi bez wyzwalania blokady.