CVE-2026-80183
WysokieCVSS 7.1Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 13 - wyżej niż 13% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Podatność umożliwia nieautoryzowany dostęp do informacji o przypisaniach ról w całej chmurze, co może prowadzić do eskalacji uprawnień lub naruszenia poufności danych.
Rekomendacja
Zaleca się natychmiastową aktualizację OpenStack Keystone do wersji 29.0.3 lub nowszej. Należy również przejrzeć uprawnienia użytkowników z rolą reader i ograniczyć dostęp do punktu końcowego role_assignments.
Inne podatności w OpenStack Keystone
Zobacz wszystkie- CVE-2026-80184Wysokie
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.
- 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, any authenticated user holding role:reader on any project can list every project-scoped role assignment under any domain by passing a domain ID as scope.project.id with include_subtree to the GET /v3/role_assignments endpoint. The domain's project record has domain_id=null, causing the policy domain_id check to pass for any caller. With include_names, the response discloses the names and home-domain IDs of every user, group, project, and role involved. The literal "default" domain ID works against any deployment created with keystone-manage bootstrap. An attacker can harvest domain IDs from the response and repeat the query to map role assignments across the entire cloud. This is caused by misuse of "None" in list_role_assignments_for_tree.