CVE-2026-63187

Logto od wersji 1.31.0 do 1.42.0 ma podatność w handlerach API konta w packages/core/src/routes/account/third-party-tokens.ts, które pozwalają posiadaczowi tokenu dostępu z tylko zakresem openid na pobranie przechowywanych tokenów dostępu dostawcy SSO przez GET /api/my-account/identities/{target}/access-token lub GET /api/my-account/sso-identities/{connectorId}/access-token. Handlery uwierzytelniają użytkownika, ale nie wymagają zakresu identities, który chroni sąsiednie operacje, omijając granicę zgody API.

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.

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.

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.

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.

Logto przed wersją 1.43.0 pobiera dane z adresów kontrolowanych przez administratora bez walidacji adresu połączenia. Dostarczanie webhooków oraz niestandardowe i OIDC konektory mogą docierać do adresów specjalnego przeznaczenia i metadanych chmury, co może ujawnić wewnętrzne dane lub poświadczenia dostawcy. Problem został naprawiony w wersji 1.43.0.

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.

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.

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.

Logto pomija walidację elementu SAML <Conditions>, co umożliwia atakującym usunięcie ograniczeń czasowych i dotyczących odbiorców oraz wielokrotne odtwarzanie asercji.