CVE-2026-123800

W SuperTokens Core w wersjach od 7.0.0 do 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1 i 12.3.1 występuje wyścig (race condition) między createNewSession a unlinkAccounts. Użytkownik kontrolujący powiązaną metodę logowania może wykorzystać ten wyścig, aby zachować podpisaną, opartą na bazie danych sesję odświeżania jako dawna tożsamość główna po odłączeniu tej metody.

SuperTokens Core to serwer uwierzytelniania open source. W wersjach od 10.1.0 do 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1 i 12.3.1 funkcje loadOptionsById_Transaction i getUserInfoByCredentialId_Transaction wykonują wyszukiwania WebAuthn w zakresie aplikacji bez ograniczania ich do żądanego tenanta, a WebAuthN.signIn nie weryfikuje przynależności do tenanta. W środowisku wielodostępnym z WebAuthn i współdzieloną pulą użytkowników zwykły użytkownik posiadający własny ważny klucz dostępu w jednym tenancie może przesłać jego asercję do punktu końcowego logowania innego tenanta w tej samej aplikacji i zostać tam uwierzytelniony, mimo braku członkostwa w docelowym tenancie. Problem naprawiono w wersjach 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1 i 12.3.1.

SuperTokens Core to serwer uwierzytelniania open source. W wersjach od 11.3.0 do 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1 i 12.3.1 licencjonowane wdrożenie z skonfigurowanym klientem SAML może uwierzytelnić tożsamość na podstawie asercji, która nie spełniała sprawdzenia odbiorcy (audience). Gdy dostawca tożsamości używa podpisywania na poziomie asercji, atakujący posiadający nadal ważną asercję podpisaną przez IdP wskazującą ofiarę dla dowolnego odbiorcy oraz własną ważną asercję dla docelowego odbiorcy może je połączyć, ponieważ validateSamlResponseAudience akceptuje odbiorcę z jednej asercji, podczas gdy extractAllClaims pobiera końcowy NameID i atrybuty z innej; podpisywanie na poziomie odpowiedzi nie ujawnia tego wariantu z wieloma asercjami. Niezależnie, asercja od dostawcy tożsamości skonfigurowanego dla docelowego wdrożenia, ale wydana innemu wdrożeniu SuperTokens używającemu współdzielonego domyślnego saml_sp_entity_id, może spełnić sprawdzenie odbiorcy celu. Skuteczne wykorzystanie uwierzytelnia atakującego jako użytkownika IdP ofiary. Problem naprawiono w wersjach 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1 i 12.3.1.

SuperTokens Core to serwer uwierzytelniania open source. W wersjach od 11.3.0 do 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1 i 12.3.1 funkcja SAML.handleCallback nie zużywa RelayState, nie rejestruje identyfikatorów asercji ani nie wymusza Response.InResponseTo. W przepływie inicjowanym przez SP atakujący, który uzyska legalnie wydaną, nadal ważną odpowiedź SAML i pasujący RelayState, może ponownie przesłać parę do /recipe/saml/callback przed upływem czasu NotOnOrAfter asercji; w przepływie inicjowanym przez IdP asercja może być odtworzona bez RelayState. Brak sprawdzenia Response.InResponseTo pozwala również na ukończenie logowania w toku za pomocą asercji dla innej tożsamości i nie wymusza allowIDPInitiatedLogin=false. Callback nie waliduje Destination ani SubjectConfirmationData Recipient i NotOnOrAfter, a każdy zaakceptowany callback generuje nowy, niezależnie wymienialny kod autoryzacyjny niosący tożsamość przechwyconego użytkownika. Problem naprawiono w wersjach 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1 i 12.3.1.

SuperTokens Core to serwer uwierzytelniania open source. W wersjach od 11.0.0 do 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11 i 12.1.2 funkcja Dashboard.isValidUserSession traktuje każdy zapisany wiersz sesji jako ważny bez porównywania DashboardSessionInfo.expiry z bieżącym czasem. DashboardQueries.getSessionInfoWithSessionId również wybiera według aplikacji i identyfikatora sesji bez predykatu wygaśnięcia, pozostawiając okresowe czyszczenie DeleteExpiredDashboardSessions jako jedyne wymuszenie wygaśnięcia. Atakujący, który uzyska sesję administratora dashboardu po jej 30-dniowym okresie ważności, może nadal używać POST /recipe/dashboard/session/verify, dopóki wiersz nie zostanie usunięty, a częste restarty Core mogą uniemożliwić uruchomienie 12-godzinnego czyszczenia. Nieaktualna sesja zachowuje pełny dostęp do odczytu i zapisu dashboardu, ale luka nie zapewnia sposobu na odgadnięcie lub uzyskanie losowego identyfikatora sesji. Problem naprawiono w wersjach 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11 i 12.1.2.

SuperTokens Core to serwer uwierzytelniania open source. W wersjach od 11.3.0 do 11.3.7, 11.4.7 i 12.0.10 funkcja SAML.verifySamlResponseSignature wywołuje OpenSAML SignatureValidator.validate bez uprzedniego zastosowania SAMLSignatureProfileValidator. Core może zatem zaakceptować kryptograficznie ważny podpis odnoszący się do innego elementu XML niż Response lub Assertion, którego NameID i atrybuty są używane do uwierzytelniania. Zwykły użytkownik skonfigurowanego dostawcy tożsamości może przenieść autentycznie podpisany element w inne miejsce dokumentu, dostarczając element niosący tożsamość autorstwa atakującego, powodując uwierzytelnienie przez XML Signature Wrapping jako inny użytkownik IdP. Dotyczy to zarówno ścieżek podpisywania na poziomie odpowiedzi, jak i asercji, a logowanie inicjowane przez SP pozostaje osiągalne bez włączania allowIDPInitiatedLogin. Problem naprawiono w wersjach 11.3.7, 11.4.7 i 12.0.10.

SuperTokens Core przed wersjami 11.3.6, 11.4.6 i 12.0.8 pozwala żądaniom zarządzania specyficznym dla aplikacji z nieznaną ścieżką tenanta i starszą obsługiwaną wersją cdi-version obejść wymuszanie klucza API i publicznego tenanta. W WebserverAPI.java funkcje checkIPAccess i assertThatAPIKeyCheckPasses tłumią TenantOrAppNotFoundException, a ochrona publicznego tenanta dotyczy tylko CDI 5.0 i nowszych. Nieuwierzytelniony wywołujący może użyć PUT /ghosttenant/recipe/role i GET /ghosttenant/recipe/roles do tworzenia i wyliczania ról aplikacji bez ważnego klucza API.

W SuperTokens Core w wersjach od 6.0.0 do 11.4.0 brakuje separacji dzierżawców (tenantów). Uwierzytelniony użytkownik jednego dzierżawcy może uzyskać dostęp do sesji, danych i punktów końcowych innego dzierżawcy.