CVE-2026-109373

ZITADEL 3.0.0 przed 4.18.0 zawiera podatność na brak uwierzytelniania w hostowanym interfejsie Login V1, gdzie procedura zmiany nazwy użytkownika działa na koncie powiązanym z przepływem logowania przed weryfikacją jakiegokolwiek czynnika. Nieuwierzytelnieni atakujący mogą przesłać nazwę logowania ofiary, a następnie wysłać nową nazwę użytkownika, aby zmienić nazwę dowolnego aktywnego użytkownika, w tym administratorów, blokując im dostęp.

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.

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 3.0.0 przed 4.19.2 zawiera lukę pozwalającą na eskalację uprawnień w wymianie tokenów OIDC, która umożliwia podszywanie się pod administratorów, w tym IAM_OWNER, z pominięciem mechanizmów kontrolnych. Atakujący posiadający role IAM_END_USER_IMPERSONATOR lub ORG_END_USER_IMPERSONATOR mogą logować się do aplikacji polegających na tym systemie jako administratorzy.

ZITADEL 4.x przed 4.19.2 oraz 3.x do 3.4.15 zawiera obejście uwierzytelniania w wywołaniu zwrotnym intencji dostawcy tożsamości SAML. Weryfikacja podpisu asercji odbywa się względem dostawcy wskazanego w URL, ale użytkownik jest rozwiązywany z intencji logowania bez sprawdzenia zgodności. Atakujący z uprawnieniami administratora organizacji może zarejestrować dostawcę SAML z własnym kluczem podpisującym, aby uzyskać uwierzytelnione sesje jako dowolny użytkownik powiązany z innym dostawcą SAML w instancji, w tym w innych organizacjach.

Zitadel przed wersją 4.16.2 zawiera podatność na podrabianie żądań po stronie serwera (SSRF), która umożliwia atakującym zmuszenie serwera do wysyłania żądań do wewnętrznych zasobów poprzez weryfikację domen organizacji. Pobieranie wyzwania używa domyślnego http.Get zamiast chronionego klienta, więc atakujący mogą rejestrować domeny przekierowujące na adresy loopback, wewnętrzne lub metadane chmury, aby skanować porty i mapować sieć wewnętrzną.

ZITADEL 4.x przed 4.17.1 nie sprawdza stanu nieaktywności organizacji podczas uwierzytelniania Login V2, weryfikując tylko status indywidualnego użytkownika. Użytkownicy zdezaktywowanej organizacji, którzy posiadają ważne poświadczenia, istniejącą sesję lub token odświeżania, mogą nadal logować się, tworzyć sesje oraz uzyskiwać lub odświeżać tokeny.