CVE-2026-56664

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.

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, przepływy OAuth2 i OIDC (CodeExchange, RefreshToken, device token) nie weryfikują, czy żądający klient jest zgodny z klientem, który zainicjował przepływ autoryzacji. Umożliwia to wymianę przechwyconych grantów lub tokenów odświeżania pod innym klientem.

Podatność w ZITADEL od wersji 4.0.0-rc.1 do 4.15.1 umożliwia ataki SSRF poprzez niespójne walidowanie adresów URL w kanałach powiadomień HTTP, wylogowaniu OIDC BackChannel i pobieraniu metadanych SAML. Atakujący może wykorzystać DNS rebinding, przekierowania lub downgrade protokołu, aby wysłać żądania do pętli zwrotnej, wewnętrznych IP lub link-local.

W ZITADEL przed wersją 4.15.1 walidacja magazynu zdarzeń może zachować oryginalnego właściciela zasobu dla usuniętego identyfikatora użytkownika, co powoduje, że późniejszy użytkownik odtworzony z tym samym identyfikatorem w innej organizacji zostanie przypisany do oryginalnej organizacji i narażony na dostęp administratora tej organizacji. Problem został naprawiony w wersji 4.15.2.