CVE-2026-59358
WysokieCVSS 7.6Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 26 - wyżej niż 26% wszystkich znanych CVE
Streszczenie
Podatność w Cloud Foundry UAA w punkcie końcowym tokenów OAuth umożliwia uwierzytelnionemu atakującemu, posiadającemu ważny token dostępu użytkownika, uzyskanie tokenu client_credentials z pełnymi uprawnieniami klienta OAuth, który wydał ten token. Dzieje się to poprzez przedstawienie tokenu użytkownika jako poświadczenia Bearer w żądaniu client_credentials zamiast sekretu klienta, ponieważ UAA nie weryfikuje, czy poświadczenie Bearer jest faktycznie poświadczeniem klienta.
Ocena ryzyka
Atakujący może eskalować uprawnienia z tokenu użytkownika (tylko uaa.user) do tokenu klienta z pełnymi autoryzacjami, takimi jak clients.write, co umożliwia tworzenie dowolnych klientów OAuth z wybranymi uprawnieniami. Może to prowadzić do nieautoryzowanego dostępu do zasobów i przejęcia kontroli nad konfiguracją OAuth w organizacji.
Rekomendacja
Należy natychmiast zaktualizować Cloud Foundry UAA do wersji zawierającej poprawkę oraz skonfigurować klientów OAuth tak, aby nie łączyli publicznych przepływów autoryzacji użytkownika z grantem client_credentials na tym samym client_id. Dodatkowo należy ograniczyć uprawnienia nadawane klientom i monitorować żądania client_credentials pod kątem nietypowych poświadczeń Bearer.
Inne podatności w Cloud Foundry UAA
Zobacz wszystkie- CVE-2017-4963Wysokie
Wykryto problem w Cloud Foundry, który dotyczy wersji v252 i wcześniejszych oraz UAA w wersjach od v2.0.0 do v2.7.4.12 i od v3.0.0 do v3.11.0. UAA jest podatny na atak typu session fixation, gdy jest skonfigurowany do uwierzytelniania zewnętrznych dostawców tożsamości opartych na SAML lub OpenID Connect.
- CVE-2017-4960Wysokie
W systemie Cloud Foundry w wersjach od v247 do v252 oraz w UAA w wersjach od v3.9.0 do v3.11.0 zidentyfikowano problem, który może prowadzić do ataku typu denial of service na klientów OAuth UAA.
- CVE-2016-6659Wysokie
Cloud Foundry oraz UAA w wersjach przed 248 oraz 2.x przed 2.7.4.12, 3.x przed 3.6.5 i 3.7.x do 3.9.x przed 3.9.3 mają lukę, która pozwala atakującym na uzyskanie uprawnień poprzez dostęp do logów UAA i uruchomienie specjalnie przygotowanej aplikacji współpracującej z dostawcą SAML.
- CVE-2026-40965Krytyczne
Cloud Foundry UAA w wersjach od v76.12.0 do v78.12.0 zawiera lukę, która nieumyślnie ujawnia prywatne klucze EC przez publiczny endpoint /token_keys. Luka dotyczy tylko wdrożeń używających kluczy EC do podpisywania tokenów JWT.
- CVE-2026-59357Średnie
Podatność w Cloud Foundry UAA (wersje 4.5.0 do 79.6.0) wynika z niewystarczającej weryfikacji autentyczności danych w zewnętrznym wywołaniu zwrotnym OIDC. Umożliwia uwierzytelnionemu użytkownikowi UAA ominięcie wymiany kodu autoryzacyjnego OAuth i ustanowienie sesji przeglądarki OIDC poprzez podstawienie własnego tokena JWT jako parametru id_token.
- CVE-2026-59335Wysokie
Niewłaściwe obsługiwanie wielkości liter (CWE-178) w kontroli autoryzacji strefy tożsamości w Identity Zone Endpoint w Cloud Foundry UAA pozwala zdalnemu uwierzytelnionemu atakującemu posiadającemu tylko uprawnienie zones.write na ominięcie zamierzonego ograniczenia, że to uprawnienie nie daje dostępu do uprzywilejowanej strefy tożsamości uaa (system), poprzez odwoływanie się do identyfikatora strefy w formie innej niż małe litery (np. UAA) w ścieżce i treści żądania. Warstwa autoryzacji wykonuje porównanie uwzględniające wielkość liter z identyfikatorem strefy systemowej, podczas gdy warstwa trwałości MySQL rozwiązuje identyfikatory bez uwzględniania wielkości liter przy domyślnej kolacji, więc żądanie jest autoryzowane nieprawidłowo, a następnie rozwiązywane względem rzeczywistego rekordu strefy systemowej. Pozwala to atakującemu nadpisać klucz podpisywania JWT strefy systemowej materiałem kontrolowanym przez atakującego, sfałszować JWT z zakresami klienta admin i administratora oraz w pełni skompromitować UAA i każde wdrożenie Cloud Foundry, które mu ufa. Problem dotyczy tylko wdrożeń UAA korzystających z MySQL z domyślną kolacją; backendy PostgreSQL i HSQLDB nie są dotknięte.
Oryginalny opis (angielski, źródło NVD)
Improper authentication (CWE-287) in the OAuth token endpoint in Cloud Foundry UAA allows a remote, authenticated attacker holding a valid user access token to obtain a fully-privileged client_credentials token for the OAuth client that issued it, by presenting the user token as an OAuth 2.0 Bearer credential on a client_credentials grant request in place of the client’s configured secret. UAA’s client_credentials handling does not verify that the Bearer credential supplied for client authentication is actually a client credential (a client secret or a valid configured client authentication method); it accepts any valid access token whose client_id matches the request. A token obtained by a normal end user through a public authorization_code + PKCE flow — scoped only to uaa.user, carrying a user_id, and recording client_auth_method=none — satisfies this check. That user token cannot itself administer OAuth clients (POST /oauth/clients correctly returns 403), but when replayed as Bearer authentication on a client_credentials request for the same client, UAA issues a new client-only token carrying the client’s full authorities, such as clients.write. An attacker can use that token to create arbitrary new OAuth clients, including clients with attacker-chosen authorities, without ever possessing the client’s actual secret. Exploitation requires a valid user access token (the attacker’s own) for a client that is configured to support both a public, user-facing authorization flow and the client_credentials grant type on the same client_id — a non-default combination. Practical impact scales with the authorities assigned to that client.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS