CVE-2026-80184
WysokieCVSS 7.6Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 41 - wyżej niż 41% wszystkich znanych CVE
Streszczenie
W OpenStack Keystone przed wersją 29.0.3 tokeny uzyskane za pomocą delegowanych mechanizmów uwierzytelniania (tokeny dostępu OAuth1, poświadczenia aplikacji, zaufania) mogły być przesyłane do ścieżki uwierzytelniania metodą tokena w celu ponownego uwierzytelnienia, aby uciec od zamierzonego zakresu projektu. Gdy token poświadczeń aplikacji został przedstawiony bez jawnego zakresu, Keystone wydawał nowy token o zakresie domyślnego projektu właściciela poświadczeń, a nie projektu, dla którego poświadczenie zostało wydane, omijając zamierzoną granicę projektu. Wszystkie wdrożenia Keystone, które zezwalają na delegowane uwierzytelnianie przez tokeny dostępu OAuth1, poświadczenia aplikacji lub zaufania, są dotknięte.
Ocena ryzyka
Ryzyko dla organizacji obejmuje możliwość eskalacji uprawnień lub nieautoryzowanego dostępu do projektów, do których użytkownik nie powinien mieć dostępu. Może to prowadzić do naruszenia integralności danych i kontroli dostępu.
Rekomendacja
Zaleca się zaktualizowanie OpenStack Keystone do wersji 29.0.3 lub nowszej. Należy również przejrzeć konfiguracje delegowanego uwierzytelniania i monitorować tokeny pod kątem nietypowych zakresów.
Inne podatności w OpenStack Keystone
Zobacz wszystkie- CVE-2026-80183Wysokie
W OpenStack Keystone przed wersją 29.0.3, każdy uwierzytelniony użytkownik z rolą reader na dowolnym projekcie może wyświetlić wszystkie przypisania ról w obrębie dowolnej domeny, przekazując ID domeny jako scope.project.id z parametrem include_subtree do punktu końcowego GET /v3/role_assignments. Rekord projektu domeny ma pole domain_id=null, co powoduje, że sprawdzenie polityki domain_id przechodzi dla każdego wywołującego. Z include_names odpowiedź ujawnia nazwy i ID domen macierzystych wszystkich użytkowników, grup, projektów i ról. Atakujący może zbierać ID domen i powtarzać zapytania, aby zmapować przypisania ról w całej chmurze.
- CVE-2026-80182Wysokie
W OpenStack Keystone przed wersją 29.0.3 tokeny uzyskane za pomocą tokena dostępu OAuth1, poświadczeń aplikacji lub uwierzytelniania z zakresem zaufania mogły tworzyć nowe długotrwałe poświadczenia lub autoryzować nowe delegacje, które utrzymują się niezależnie od poświadczenia użytego do ich uzyskania i go przeżywają. Ograniczenia delegacji, które blokują te operacje, nie były spójnie stosowane do wszystkich typów tokenów delegowanych, co pozwalało na przykład tokenowi z zakresem OAuth1 na tworzenie poświadczeń aplikacji lub autoryzację tokenów żądań OAuth1, mimo że te operacje były ograniczone dla innych typów tokenów delegowanych. Wszystkie wdrożenia Keystone, które zezwalają na delegowane uwierzytelnianie przez tokeny dostępu OAuth1, poświadczenia aplikacji lub zaufania, są dotknięte.
- CVE-2026-43000Średnie
W OpenStack Keystone przed wersją 29.0.2 wykryto podatność, która w połączeniu z eskalacją uprawnień przez poświadczenia aplikacji pozwala atakującemu z rolą member na projekcie na eskalację do admina. Atakujący tworzy nieograniczone poświadczenia aplikacji i łączy je z trustami Keystone, podszywając się pod ofiarę i przejmując jej rolę admina.
- CVE-2026-42999Średnie
W OpenStack Keystone przed wersją 29.0.2, mechanizm wymuszania polityk RBAC w funkcji enforce_call bezwarunkowo scala surowe JSONowe ciało żądania do słownika wymuszania polityk za pomocą policy_dict.update(json_input.copy()), nadpisując zaufane dane docelowe ustawione wcześniej z zapytań do bazy danych. Ponieważ flask.request.get_json jest wywoływane z force=True, działa to niezależnie od Content-Type lub metody HTTP. Każdy uwierzytelniony użytkownik może wstrzyknąć dowolne atrybuty docelowe polityki (np. user_id, project_id) do ciała żądania, aby ominąć kontrole RBAC i wykonać nieautoryzowane operacje na zasobach należących do innych użytkowników lub projektów. Podatność została wprowadzona w commicie 5ea59f52 (Rocky/14.0.0).
- CVE-2026-43001Wysokie
W OpenStack Keystone przed wersją 29.0.2 brak walidacji projektu w żądaniu POST /v3/credentials dla poświadczeń EC2. Atakujący z nieograniczonym poświadczeniem aplikacji dla projektu A mógł utworzyć poświadczenie EC2 dla projektu B, a następnie wymienić je na token Keystone dla projektu B, zachowując oryginalne ID poświadczenia aplikacji.
- CVE-2026-40683Wysokie
W OpenStack Keystone przed wersją 28.0.1, backend tożsamości LDAP nie konwertuje atrybutu enabled użytkownika na wartość logiczną, gdy opcja konfiguracyjna user_enabled_invert ma wartość False (domyślnie). Powoduje to, że użytkownicy wyłączeni w LDAP są traktowani jako włączeni przez Keystone, co pozwala im na uwierzytelnianie i wykonywanie działań.
- CVE-2013-0270Średnie
W OpenStack Keystone stwierdzono podatność, która pozwala zdalnemu atakującemu wysłać duże żądanie HTTP z długą nazwą dzierżawcy (tenant name) podczas żądania tokena, co prowadzi do nadmiernego zużycia CPU i pamięci, powodując odmowę usługi (DoS).
Oryginalny opis (angielski, źródło NVD)
In OpenStack Keystone before 29.0.3, tokens obtained via delegated authentication mechanisms (OAuth1 access tokens, application credentials, trusts) could be submitted to the token-method authentication path for reauthentication to escape their intended project scope. When an application credential token was presented with no explicit scope, Keystone would issue a new token scoped to the credential owner's default project rather than the project for which the credential was issued, bypassing the intended project boundary. All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected.