CVE-2026-105213

ZITADEL przed wersją 3.4.14 oraz 4.x przed 4.16.2 zawiera obejście uwierzytelniania w hostowanym interfejsie Login V1, ponieważ punkt końcowy rejestracji 'external account not found' ufa dostarczonym przez klienta polom tożsamości zewnętrznej bez ukończonego wywołania zwrotnego IdP. Nieuwierzytelnieni atakujący mogą przesłać sfałszowane wartości IDPConfigID i ExternalUserID, aby wstępnie utworzyć konto powiązane z tożsamością zewnętrznego IdP ofiary, do którego późniejsze autentyczne logowanie zewnętrzne ofiary uzyska dostęp.

ZITADEL 3.x przed 3.4.15 oraz 4.x przed 4.17.1 zawiera podatność nieprawidłowej autoryzacji: przy wydawaniu kodów rejestracji passkey lub logowania bez hasła sprawdza tylko organizację w nagłówku x-zitadel-orgid, a nie organizację docelowego użytkownika. Atakujący z uprawnieniami do zapisu użytkownika w jednej organizacji może uzyskać kod rejestracji dla użytkownika w innej organizacji w tej samej instancji i zarejestrować własny uwierzytelniacz, aby przejąć to konto.

ZITADEL 3.0.0 do 3.4.15 oraz 4.0.0 przed 4.17.3 tworzy powiązania między kontami użytkowników a zewnętrznymi dostawcami tożsamości bez weryfikacji czynnika podstawowego lub uprawnień wywołującego, w tym w sesjach Login V2 typu identify-only oraz przez punkt końcowy User Service V2 AddIDPLink. Nieuwierzytelniony atakujący znający login ofiary może powiązać własną tożsamość zewnętrznego IdP z kontem ofiary, a następnie zalogować się jako ofiara.

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.

Podatność w procesie federacji ZITADEL pozwalała na automatyczne powiązanie użytkownika z zewnętrznego dostawcy tożsamości z istniejącym kontem wewnętrznym, nawet gdy dany IdP był wyłączony lub organizacja nie zezwalała na uwierzytelnianie federacyjne. Wynikało to z nieegzekwowania polityk bezpieczeństwa organizacji podczas logowania. Wersje 2.71.19, 3.4.4 i 4.6.6 naprawiają problem poprzez prawidłową walidację polityki logowania przed automatycznym powiązaniem.

W wersjach Zitadel od 2.53.6, 2.54.3 i 2.55.0 wymagane było uwierzytelnianie wieloskładnikowe tylko wtedy, gdy polityka logowania miała włączone requireMFA lub requireMFAForLocalUsers. Jeśli użytkownik skonfigurował MFA bez tego wymogu, Zitadel uznawał sesje z pojedynczym składnikiem za ważne i nie wymagał wielu składników. Pominięcie drugiego składnika osłabia MFA i umożliwia atakującemu obejście bezpieczniejszego składnika, np. atak na sam kod TOTP (sześć cyfr) z pominięciem weryfikacji hasła. Podatność naprawiono w wersjach 4.6.0, 3.4.3 i 2.71.18.

Zitadel przed wersjami 4.6.0, 3.4.3 i 2.71.18 pozwala atakującemu na przeprowadzenie ataku brute-force online na OTP, TOTP i hasła. Mechanizm blokady konta, który może temu zapobiec, nie jest domyślnie włączony i może powodować odmowę usługi dla danego użytkownika, jeśli zostanie włączony. Ponadto strategie mitygacji nie zostały w pełni wdrożone w nowszych API opartych na zasobach.

ZITADEL w wersjach od 3.0.0 do 3.4.15 oraz od 4.0.0 przed 4.19.5 zawiera podatność braku autoryzacji w Login V2, która pozwala atakującym zatwierdzić autoryzacje urządzeń OAuth 2.0 przy użyciu istniejącej sesji ofiary bez jej zgody. Atakujący może wysłać zalogowanemu użytkownikowi link z własnym kodem użytkownika, aby uzyskać tokeny ofiary, oraz obejść ustawienia dostępu projektu przez API autoryzacji urządzeń OIDC.

ZITADEL w wersjach 4.0.0 przed 4.19.5 zawiera podatność obejścia uwierzytelniania w interfejsie Login V2, która pozwala nieuwierzytelnionym atakującym ustawić pierwsze poświadczenie użytkowników niemających żadnej metody uwierzytelniania. Atakujący może obliczyć ważny plik cookie verificationCheck na podstawie identyfikatora użytkownika i odcisku przeglądarki, aby ustawić hasło, zarejestrować passkey lub powiązać dostawcę tożsamości, przejmując konto.

W ZITADEL w wersjach od 4.0.0 do 4.19.5 występuje podatność na wstrzyknięcie nagłówka hosta w interfejsie Login V2. Nieuwierzytelniony atakujący może zatruć linki do resetowania hasła, zaproszeń i weryfikacji e-mail, dostarczając niezaufane nagłówki x-zitadel-public-host, x-zitadel-forward-host lub x-forwarded-host.