CVE-2026-59357
ŚrednieCVSS 6.5Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 7 - wyżej niż 7% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Atakujący z ważnym tokenem JWT (np. tokenem dostępu z zakresem uaa.user) może uzyskać dostęp do konta lokalnego (shadow) z uprawnieniami administracyjnymi, jeśli konto to ma przypisane grupy takie jak clients.write. Może to prowadzić do nieautoryzowanych zmian w konfiguracji UAA.
Rekomendacja
Zaleca się natychmiastową aktualizację Cloud Foundry UAA do wersji nowszej niż 79.6.0, jeśli to możliwe. Ponadto należy sprawdzić konfiguracje OIDC pod kątem dostawców tożsamości typu self-UAA i rozważyć ich wyłączenie lub zmianę, aby uniknąć ryzyka.
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-59358Wysokie
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.
- 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)
Insufficient verification of data authenticity (CWE-345) in the external OIDC login callback in Cloud Foundry UAA v4.5.0 to v79.6.0 (inclusive) allows an authenticated UAA user to bypass the OAuth authorization-code exchange and establish an authenticated external-OIDC browser session, via submitting a UAA access token or a cross-client ID token as the callback’s id_token parameter. The issue only manifests when a UAA zone is configured with an OIDC identity provider whose issuer exactly matches that zone’s own /oauth/token endpoint (a “self-UAA” OIDC configuration). In this configuration, the callback takes a supplied id_token directly instead of requiring the authorization code exchange, and does not verify that the token was actually issued as an ID token for the specific self-OIDC relying-party client. An attacker holding any valid UAA JWT for themselves — including a plain access token with only uaa.user scope, or a valid ID token issued to an unrelated client such as cf — can present it as the callback’s id_token and be authenticated into a mapped local (“shadow”) account. Because the resulting session is not verified against the originating token’s true audience or user_id, its effective privilege depends entirely on the shadow account’s group memberships, which can include administrative scopes such as clients.write. Exploitation requires a valid UAA user JWT, a valid browser login state for the target zone, and the presence of a self-referential OIDC provider configuration — this is not a pre-authentication vulnerability, and does not by itself grant privileges beyond those already held by the mapped shadow account.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS