CVE-2026-63203
WysokieCVSS 7.6Streszczenie
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.
Ocena ryzyka
Ryzyko obejmuje nieautoryzowany dostęp do tokenów dostawcy SSO, co może prowadzić do naruszenia danych użytkownika lub działań w imieniu użytkownika w zakresie przyznanych uprawnień.
Rekomendacja
Zaleca się aktualizację Logto do wersji 1.42.0, która naprawia tę podatność.
Inne podatności w Logto
Zobacz wszystkie- CVE-2026-56739Wysokie
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.
- 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.
Oryginalny opis (angielski, źródło NVD)
Logto is the modern, open-source auth infrastructure for SaaS and AI apps. From 1.31.0 until 1.42.0, the Account API handlers in packages/core/src/routes/account/third-party-tokens.ts allow a caller holding a same-user access token with only the openid scope to retrieve stored social or enterprise SSO provider access tokens through GET /api/my-account/identities/{target}/access-token or GET /api/my-account/sso-identities/{connectorId}/access-token. The handlers authenticate the user but do not require the identities scope that protects neighboring identity-detail operations, bypassing the intended Account API consent boundary. Exploitation requires federated token-set storage to be enabled and the affected user to have authenticated through a supported connector. A low-trust application can use the disclosed provider token against upstream APIs within that token's granted scopes. This issue is fixed in version 1.42.0.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

