CVE-2026-123802
WysokieCVSS 8.1Streszczenie
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.
Ocena ryzyka
Atakujący może podszyć się pod użytkownika IdP ofiary, uzyskując nieautoryzowany dostęp do chronionych zasobów. Narusza to integralność procesu uwierzytelniania SAML i może prowadzić do przejęcia konta.
Rekomendacja
Zaktualizuj SuperTokens Core do wersji 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1 lub 12.3.1. Rozważ zmianę domyślnego saml_sp_entity_id na unikalny dla wdrożenia.
Inne podatności w SuperTokens Core
Zobacz wszystkie- CVE-2026-123804Średnie
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.
- CVE-2026-123803Wysokie
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.
- CVE-2026-123801Wysokie
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.
- CVE-2026-123799Wysokie
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.
- CVE-2026-123798Wysokie
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.
- CVE-2026-123797Wysokie
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.
- CVE-2026-123800Krytyczne
W SuperTokens Core w wersjach od 6.0.0 do 6.0.24, 7.0.23, 8.0.7, 9.0.6, 9.1.6, 9.2.7, 9.3.5, 10.0.8, 10.1.9, 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 funkcja Multitenancy.checkPermissionsForCreateOrUpdate nieprawidłowo autoryzuje aktualizacje domeny nadrzędnej URI połączenia lub dzierżawy bazowej. W licencjonowanym wdrożeniu wielodostępnym z wieloma aplikacjami w ramach jednej domeny URI połączenia innej niż domyślna i oddzielnymi kluczami API atakujący posiadający ważny klucz API jednej aplikacji może zaktualizować domenę nadrzędną, a następnie zastąpić klucze aplikacji siostrzanych, czytać lub modyfikować użytkowników siostrzanych, uzyskiwać sesje jako ci użytkownicy, utrwalić dostęp przez użytkownika pulpitu nawigacyjnego siostrzanej aplikacji i zablokować własny klucz aplikacji siostrzanej. Warianty obsługi tworzenia lub aktualizacji v2 z pominięciem opcjonalnego identyfikatora tworzą cel dzierżawy bazowej, który pomija gałęzie uprawnień i bramkę funkcji enterprise, umożliwiając zmiany w firstFactors, wymaganych czynnikach dodatkowych i flagach włączonych przepisów, co wpływa na integralność i dostępność logowania. Wariant celu bazowego nadal odrzuca coreConfig i nie prowadzi do kradzieży kluczy. Problem naprawiono w wersjach 6.0.24, 7.0.23, 8.0.7, 9.0.6, 9.1.6, 9.2.7, 9.3.5, 10.0.8, 10.1.9, 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.
- CVE-2026-37171Średnie
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.
Oryginalny opis (angielski, źródło NVD)
SuperTokens Core is an open source authentication server. From 11.3.0 until 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1, a licensed deployment with a configured SAML client can authenticate an identity from an assertion that did not satisfy the audience check. When the identity provider uses assertion-level signing, an attacker who has a still-valid IdP-signed assertion naming the victim for any audience and the attacker's own valid assertion for the target audience can combine them because validateSamlResponseAudience accepts an audience from one assertion while extractAllClaims takes the final NameID and attributes from another; response-level signing does not expose this multi-assertion variant. Independently, an assertion from an identity provider configured for the target deployment but issued to another SuperTokens deployment using the shared default saml_sp_entity_id can satisfy the target's audience check. Successful exploitation authenticates the attacker as the victim IdP user. This issue is fixed in versions 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1.
Dane podatności pochodzą z NVD (NIST) · CISA KEV · EPSS

