CVE-2026-85057

ZITADEL to narzędzie infrastruktury tożsamości open-source. Wersje 4.7.0 i niższe są podatne na nieuwierzytelnioną podatność SSRF z pełnym odczytem. Interfejs logowania ZITADEL (V2) traktuje nagłówek x-zitadel-forward-host jako zaufany fallback dla wszystkich wdrożeń, w tym samodzielnie hostowanych instancji. Pozwala to nieuwierzytelnionemu atakującemu zmusić serwer do wykonywania żądań HTTP do dowolnych domen, takich jak adresy wewnętrzne, i odczytywania odpowiedzi, co umożliwia eksfiltrację danych i obejście kontroli segmentacji sieci. Problem został naprawiony w wersji 4.7.1.

ZITADEL to platforma open source do zarządzania tożsamością. Podatność w procesie federacji pozwala na automatyczne powiązanie użytkowników z zewnętrznych dostawców tożsamości (IdP) z istniejącymi kontami użytkowników, nawet jeśli dany IdP jest wyłączony lub organizacja nie zezwala na uwierzytelnianie federacyjne. Problem wynika z nieprawidłowego sprawdzania ustawień bezpieczeństwa organizacji podczas procesu logowania.

ZITADEL, open-source platforma zarządzania tożsamością, w wersjach od 4.0.0 do 4.16.1 zawiera podatność w Login V2, która tworzy sesję przeglądarki po weryfikacji hasła i może użyć tej sesji do późniejszego żądania uwierzytelnienia bez weryfikacji zarejestrowanego drugiego składnika TOTP, OTP lub U2F. Gdy krok MFA zostanie porzucony, a logowanie rozpocznie się ponownie, kontrole ważności sesji wymagają MFA tylko wtedy, gdy organizacja włączy Force MFA lub Force MFA tylko dla użytkowników lokalnych, więc dobrowolnie zarejestrowany czynnik może zostać pominięty podczas kończenia callbacku OIDC lub SAML dla aplikacji klienta. Login V1, ZITADEL Console, Management i Admin APIs oraz samoobsługa użytkownika nie są dotknięte. Problem naprawiono w wersji 4.16.1.

ZITADEL to otwartoźródłowa platforma zarządzania tożsamością. Przed wersją 4.16.0 błąd w aktualizacji uprawnień przy jednoczesnym usuwaniu wielu ról projektowych może powodować pominięcie niektórych uprawnień użytkownika. Problem dotyczy User Grants w Granted Projects (projektach współdzielonych między organizacjami) i może pozwolić użytkownikom zachować prawa dostępu, które powinny zostać całkowicie usunięte.

W ZITADEL od 2.43.0 do 2.71.19, od 3.0.0 do 3.4.11 i od 4.0.0 do 4.15.1, API do zarządzania e-mailem i telefonem pozwalało użytkownikom na żądanie zwróconych kodów weryfikacyjnych bez wymaganych uprawnień. Umożliwia to przejęcie adresów e-mail lub numerów telefonów innych użytkowników i ominięcie polityk bezpieczeństwa opartych na e-mailu lub telefonie.

Podatność w ZITADEL przed wersją 4.15.3 umożliwia wymianę tokena o niskich uprawnieniach na token z podwyższonymi uprawnieniami w innej aplikacji. Dzieje się tak, ponieważ punkt końcowy OAuth2 Token Exchange nie weryfikuje, czy token podmiotu należy do żądającego klienta ani czy żądane zakresy mieszczą się w zakresach oryginalnego tokena.

W ZITADEL przed wersją 4.15.3, w ścieżkach błędów logowania Login V2 OIDC i SAML, parametr loginSettings.defaultRedirectUri jest przekazywany do router.push bez walidacji isSafeRedirectUri. Umożliwia to administratorowi organizacji lub instancji przechowanie URI javascript lub data, który może zostać wykonany w przeglądarce użytkownika po trafieniu na podatną ścieżkę błędu logowania.

W ZITADEL przed wersją 4.15.3, procedura obsługi zewnętrznego dostawcy tożsamości (IdP) sprawdzała, czy e-mail lokalnego użytkownika jest zweryfikowany, ale nie weryfikowała, czy zewnętrzny IdP potwierdził posiadanie tego samego adresu e-mail przed automatycznym powiązaniem kont. Umożliwiało to atakującemu posiadającemu konto u zewnętrznego dostawcy z adresem e-mail ofiary powiązanie go z lokalnym kontem ofiary.

Podatność w ZITADEL (wersje 3.0.0-rc.1 do 3.4.11 oraz 4.0.0-rc.1 do 4.15.1) powoduje, że walidacja zewnętrznych tokenów JWT pomija sprawdzanie wygaśnięcia, gdy token nie zawiera pola exp. Token z zaufanego wystawcy jest traktowany jako ważny bez automatycznego terminu ważności.

W ZITADEL przed wersjami 3.4.12 i 4.15.2, walidacja zewnętrznego JWT Identity Provider pomija sprawdzenie maksymalnego wieku tokena, gdy brakuje w nim deklaracji iat. Umożliwia to uwierzytelnienie dowolnie starych tokenów od zaufanego wystawcy.