CVE-2026-85056

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 3.0.0 do 3.4.13 oraz 4.16.1 zawiera podatność w Actions V1, która umożliwia korzystanie z rejestru require() kompatybilnego z Node.js (goja) bez ograniczenia ładowania plików z systemu plików. Autor akcji organizacji z uprawnieniami ORG_OWNER, org.action.write i org.flow.write może uruchamiać JavaScript w punktach wyzwalania OIDC, SAML i przepływu logowania oraz ładować pliki czytelne dla procesu serwera ZITADEL. Może to ujawnić zamontowaną konfigurację i sekrety, w tym poświadczenia przechowywane przez ZITADEL_FIRSTINSTANCE_LOGINCLIENTPATPATH lub ZITADEL_FIRSTINSTANCE_MACHINEKEYPATH, a odzyskane poświadczenia bootstrap mogą umożliwić eskalację z administratora organizacji do administratora instancji. Problem naprawiono w wersjach 3.4.13 i 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.