CVE-2026-54714

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, 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.

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.