CVE-2026-55377
WysokieCVSS 8.1Prawdopodobieństwo exploitacji (EPSS)
Niskie ryzykoPercentyl 17 - wyżej niż 17% wszystkich znanych CVE
Streszczenie
Logto przed wersją 1.41.0 zawiera podatność w mechanizmie weryfikacji wieloetapowej (step-up) w Centrum Konta. Atakujący z tokenem API może utworzyć i zweryfikować rejestrację WebAuthn dla nowego klucza dostępu, a następnie użyć jej jako potwierdzenia tożsamości, co pozwala na zarządzanie czynnikami MFA bez posiadania hasła, identyfikatora lub istniejącego czynnika MFA.
Ocena ryzyka
Organizacja narażona jest na ryzyko nieautoryzowanego dodawania lub usuwania czynników MFA przez atakującego, który uzyskał token API. Może to prowadzić do przejęcia kont użytkowników i naruszenia bezpieczeństwa uwierzytelniania wieloskładnikowego.
Rekomendacja
Należy niezwłocznie zaktualizować Logto do wersji 1.41.0 lub nowszej. Po aktualizacji należy również zresetować wszystkie tokeny API i wymusić ponowną weryfikację użytkowników.
Inne podatności w Logto
Zobacz wszystkie- CVE-2026-15617Krytyczne
Logto wykonuje wyszukiwanie główne bez normalizacji adresów email i identyfikatorów, co umożliwia kolizję główną i nieautoryzowany dostęp do konta poprzez użycie tożsamości różniących się wielkością liter lub znakami Unicode.
- CVE-2026-15616Krytyczne
Logto nie wymusza lokalnie skonfigurowanego MFA podczas uwierzytelniania SSO, co umożliwia użytkownikom ominięcie wymogów drugiego czynnika i uzyskanie nieautoryzowanego dostępu.
- CVE-2026-15612Krytyczne
Logto pomija walidację nonce OIDC, gdy roszczenie nonce jest nieobecne w id_token, co umożliwia odtwarzanie tokenów uwierzytelniających i osłabia wiązanie sesji.
- CVE-2026-15611Krytyczne
Logto umożliwia łączenie kont SSO na podstawie niezweryfikowanego adresu email, co pozwala atakującemu zarejestrować tożsamość u dostawcy tożsamości używając adresu email ofiary i uzyskać nieautoryzowany dostęp do jej konta.
- CVE-2026-82263Średnie
Logto do wersji 1.42.0 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w endpointcie tworzenia łącznika OIDC SSO, który nie waliduje parametru adresu URL wystawcy. Administratorzy dzierżawy z poświadczeniami Management API mogą podać dowolne wewnętrzne adresy URL, aby wywołać żądania HTTP GET do usług w sieci prywatnej, a treść odpowiedzi jest zwracana w odpowiedziach API.
- CVE-2026-82262Średnie
Logto do wersji 1.42.0 zawiera podatność na podrabianie żądań po stronie serwera (SSRF) w endpointcie POST /api/hooks/:id/test, który akceptuje dowolne adresy URL bez walidacji hosta. Administratorzy dzierżawy z tokenami Management API mogą sprawić, że serwer wyśle żądania HTTP POST do wewnętrznych adresów URL i odczyta treść odpowiedzi z usług w sieci prywatnej.
- CVE-2026-63187Średnie
Logto, nowoczesna infrastruktura uwierzytelniania open-source, w wersjach od 1.40.1 do 1.41.0 zawiera podatność w workflow GitHub Actions, gdzie tytuł pull requesta jest bezpośrednio interpolowany do polecenia echo w kroku commitlint. Tytuł zawierający pojedynczy cudzysłów może przerwać ciąg echo i dołączyć dowolne polecenia powłoki na runnerze GitHub Actions. Atakujący może zakłócić działanie ephemeral workflow, ale nie ma dostępu do sekretów repozytorium.
- CVE-2026-62317Wysokie
Logto przed wersją 1.41.0 ma podatność na katastrofalne cofanie się (catastrophic backtracking) w wyrażeniu regularnym używanym do blokowania subadresów e-mail. Atakujący może wysłać specjalnie skonstruowany adres e-mail, powodując zablokowanie pętli zdarzeń i niedostępność usług uwierzytelniania.
- CVE-2026-15615Wysokie
Logto pomija walidację elementu SAML <Conditions>, co umożliwia atakującym usunięcie ograniczeń czasowych i dotyczących odbiorców oraz wielokrotne odtwarzanie asercji.
- CVE-2026-15614Wysokie
Logto po cichu nie usuwa sesji SAML inicjowanych przez IdP, co umożliwia odtwarzanie sesji i ponowne użycie w oknie ważności sesji.
Oryginalny opis (angielski, źródło NVD)
Logto is the modern, open-source auth infrastructure for SaaS and AI apps. Prior to 1.41.0, Logto's Account Center step-up check accepted any active verification record that belonged to the current user and had isVerified === true. A WebAuthn registration verification record for binding a new passkey could be created and verified with only an existing Account API bearer token, then sent in the logto-verification-id header and treated as identityVerified=true by Account Center routes, allowing MFA factor management without proving possession of an existing password, identifier, or MFA factor. This issue is fixed in version 1.41.0.

