CVE-2026-80182
WysokieCVSS 7.6Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 40 - wyżej niż 40% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Ryzyko dla organizacji obejmuje możliwość tworzenia trwałych poświadczeń przez nieautoryzowanych użytkowników, co może prowadzić do długotrwałego nieautoryzowanego dostępu do zasobów. Może to również umożliwić eskalację uprawnień.
Rekomendacja
Zaleca się zaktualizowanie OpenStack Keystone do wersji 29.0.3 lub nowszej. Należy również przejrzeć zasady delegacji i monitorować tworzenie nowych poświadczeń.
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-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-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 OAuth1 access token, application credential, or trust-scoped authentication could create new long-lived credentials or authorize new delegations that persist independently of, and outlive, the credential used to obtain them. The delegation restrictions that block these operations did not consistently apply to all delegated token types, allowing an OAuth1-scoped token, for example, to create application credentials or authorize OAuth1 request tokens despite those operations being restricted for other delegated token types. All Keystone deployments that permit delegated authentication through OAuth1 access tokens, application credentials, or trusts are affected.