CVE-2025-64103
KrytyczneCVSS 9.8Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 27 - wyżej niż 27% wszystkich znanych CVE
Streszczenie
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.
Ocena ryzyka
Atakujący może obejść uwierzytelnianie wieloskładnikowe i przejąć konto chronione 2FA, jeśli zna kod TOTP. Prowadzi to do nieautoryzowanego dostępu do konta i powiązanych zasobów.
Rekomendacja
Zaktualizuj Zitadel do wersji 4.6.0, 3.4.3, 2.71.18 lub nowszej. Upewnij się, że polityki logowania wymuszają MFA dla wszystkich użytkowników, którzy je skonfigurowali.
Inne podatności w Zitadel
Zobacz wszystkie- CVE-2026-105215Krytyczne
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.
- CVE-2026-105209Krytyczne
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.
- CVE-2026-105207Krytyczne
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.
- CVE-2025-67494Krytyczne
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.
- CVE-2025-64717Krytyczne
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.
- CVE-2025-64102Krytyczne
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.
- CVE-2026-109374Średnie
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.
- CVE-2026-109373Wysokie
ZITADEL 3.0.0 przed 4.19.2 zawiera podatność obejścia uwierzytelniania w interfejsie Login V2, która pozwala nieuwierzytelnionym atakującym na uzyskanie tokenów sesji innych użytkowników poprzez fałszowanie niepodpisanych ciasteczek sesji. Atakujący mogą odgadnąć uporządkowane czasowo identyfikatory sesji wokół logowania ofiary i dostarczyć je z pustymi tokenami, aby otrzymać rotowane tokeny, przejmując konta, w tym sesje administratorów z ukończonym MFA.
- CVE-2026-109372Wysokie
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.
- CVE-2026-109371Wysokie
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.
Oryginalny opis (angielski, źródło NVD)
Starting from 2.53.6, 2.54.3, and 2.55.0, Zitadel only required multi factor authentication in case the login policy has either enabled requireMFA or requireMFAForLocalUsers. If a user has set up MFA without this requirement, Zitadel would consider single factor auhtenticated sessions as valid as well and not require multiple factors. Bypassing second authentication factors weakens multifactor authentication and enables attackers to bypass the more secure factor. An attacker can target the TOTP code alone, only six digits, bypassing password verification entirely and potentially compromising accounts with 2FA enabled. This vulnerability is fixed in 4.6.0, 3.4.3, and 2.71.18.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

