SuperTokens Core is an open source authentication server. From 7.0.0 until 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1, createNewSession can resolve a primary user before unlinkAccounts detaches a login method and then insert the session after unlink has enumerated and revoked the existing sessions. A user who controls the linked login method can exploit this race to retain a signed, database-backed, refreshable session as the former primary identity after that method is unlinked; the session persists until expiry or explicit revocation. This issue is fixed in versions 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1.

SuperTokens Core is an open source authentication server. From 10.1.0 until 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1, loadOptionsByIdTransaction and getUserInfoByCredentialIdTransaction perform application-scoped WebAuthn lookups without constraining them to the requested tenant, and WebAuthN.signIn does not verify tenant membership. In a multi-tenant deployment using WebAuthn with a shared user pool, an ordinary user who possesses their own valid passkey in one tenant can submit its assertion to another tenant's sign-in endpoint in the same application and be authenticated there despite having no membership in the target tenant. This issue is fixed in versions 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1.

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

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, SAML.handleCallback does not consume RelayState, record assertion identifiers, or enforce Response.InResponseTo. In the SP-initiated flow, an attacker who obtains a legitimately issued, still-valid SAML response and its matching RelayState can resubmit the pair to /recipe/saml/callback before the assertion's NotOnOrAfter time; in the IdP-initiated flow, the assertion can be replayed without RelayState. The missing Response.InResponseTo check also permits an in-progress login to be completed with an assertion for a different identity and fails to enforce allowIDPInitiatedLogin=false. The callback does not validate Destination or SubjectConfirmationData Recipient and NotOnOrAfter, and each accepted callback mints a fresh, independently redeemable authorization code carrying the captured user's identity. 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.

SuperTokens Core is an open source authentication server. From 6.0.0 until 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, and 12.3.1, Multitenancy.checkPermissionsForCreateOrUpdate in src/main/java/io/supertokens/multitenancy/Multitenancy.java does not adequately authorize updates to a parent connection URI domain or the base tenant. In a licensed multi-tenant deployment with multiple applications under one non-default connection URI domain and separate apikeys, an attacker holding one application's valid API key can update the parent domain because the CUD-target branch checks the domain without requiring the source application and tenant to be public. Because apikeys is not protected, the attacker can replace the parent key and then sibling application keys, read or modify sibling users, obtain sessions as those users, establish persistence through a sibling dashboard user, and lock out the sibling application's own key. In the advisory's v2 create or update handlers, omitting the optional identifier produces a base-tenant target that skips the permission branches and enterprise-feature gate, allowing changes to firstFactors, required secondary factors, and recipe-enabled flags that affect login integrity and availability. The base-target variant still rejects coreConfig and does not establish key theft. This issue is fixed in versions 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, and 12.3.1.

SuperTokens Core is an open source authentication server. From 11.0.0 until 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, and 12.1.2, Dashboard.isValidUserSession treats any stored session row as valid without comparing DashboardSessionInfo.expiry to the current time. DashboardQueries.getSessionInfoWithSessionId also selects by app and session identifier without an expiry predicate, leaving the periodic DeleteExpiredDashboardSessions cleanup as the only expiration enforcement. An attacker who obtains a dashboard administrator session after its 30-day lifetime can continue using POST /recipe/dashboard/session/verify until the row is removed, and frequent Core restarts can prevent the 12-hour cleanup sweep from running. The stale session retains full dashboard read and write access, but the flaw does not provide a way to guess or acquire the random session identifier. This issue is fixed in versions 11.0.9, 11.1.4, 11.2.4, 11.3.8, 11.4.8, 12.0.11, and 12.1.2.

SuperTokens Core is an open source authentication server. From 11.3.0 until 11.3.7, 11.4.7, and 12.0.10, SAML.verifySamlResponseSignature calls OpenSAML SignatureValidator.validate without first applying SAMLSignatureProfileValidator. The Core can therefore accept a cryptographically valid signature that references a different XML element from the Response or Assertion whose NameID and attributes are used for authentication. An ordinary user of the configured identity provider can move a genuinely signed element elsewhere in the document while supplying an attacker-authored identity-bearing element, causing XML Signature Wrapping authentication as another IdP user. Both response-level and assertion-level signing paths are affected, and SP-initiated login remains reachable without enabling allowIDPInitiatedLogin. This issue is fixed in versions 11.3.7, 11.4.7, and 12.0.10.

SuperTokens Core is an open source authentication server. From 12.0.6 until 12.0.8, from 11.4.0 until 11.4.6, from 11.3.0 until 11.3.6, and in versions before 11.3.0, app-specific management requests using an unknown tenant path and an older supported cdi-version can bypass API-key and public-tenant enforcement. In src/main/java/io/supertokens/webserver/WebserverAPI.java, checkIPAccess and assertThatAPIKeyCheckPasses suppress TenantOrAppNotFoundException, while the later app-specific handler resolves app/public storage and the public-tenant guard applies only to CDI versions 5.0 and later. An unauthenticated caller able to reach the Core endpoint can therefore use PUT /ghosttenant/recipe/role and GET /ghosttenant/recipe/roles to create and enumerate application roles without a valid API key. This issue is fixed in versions 11.3.6, 11.4.6, and 12.0.8.

Hello,

This is a disclosure for CVE-2026-37171, a cross-tenant authorization flaw in SuperTokens Core, the self-hosted authentication server by SuperTokens Inc.

Affected: SuperTokens Core (supertokens-core) versions 6.0.0 through 11.4.0. CWE: CWE-863 (Incorrect Authorization). CVE: CVE-2026-37171 (published; NVD and GitHub Advisory GHSA-j7vw-hh5c-2w6x).

Summary ------- SuperTokens Core lacks tenant separation in session operations. The Core derives the tenant identifier from the access token's "tId" claim and trusts it without comparing it to the tenant specified in the HTTP request path. As a result, an authenticated party operating in one tenant can verify, read, regenerate, and otherwise act on sessions, data, and endpoints belonging to another tenant.

Impact ------ In a multi-tenant deployment, a party with a valid session in one tenant can reach another tenant's sessions and data. This is a cross-tenant confidentiality and integrity breach within a single SuperTokens Core deployment.

Example ------- A request such as:

POST /<tenantB>/recipe/session/verify

carrying an access token whose "tId" claim is tenantA is served in tenantA's context rather than being rejected for the tenantB path. The Core reads the tenant from the token, not the path.

Mitigation ---------- - Treat the SuperTokens Core service as sensitive infrastructure. Keep it off any untrusted network; the Core admin interface trusts its callers, and by default binds to localhost. - Set apikeys on the Core so the admin interface is not reachable without a key. - Upgrade to a fixed release once the vendor ships one. No fixed version is named in the current CVE record; operators running 6.0.0-11.4.0 should apply the network and apikeys mitigations now.

Details / advisory ------------------ Full advisory: https://www.google.com/url?q=https://whitenbaker.com/supertokens-core-multitenant-advisory&source=gmail&ust=1789023669402000&sa=E NVD: https://www.google.com/url?q=https://nvd.nist.gov/vuln/detail/CVE-2026-37171&source=gmail&ust=1789023669402000&sa=E GitHub Advisory: https://www.google.com/url?q=https://github.com/advisories/GHSA-j7vw-hh5c-2w6x&source=gmail&ust=1789023669402000&sa=E

Discoverer: Drew Morana (@dmorana), Whitenbaker.

Regards, Drew Morana Whitenbaker

A lack of tenant separation in SuperTokens Inc. SuperTokens Core v6.0.0 to v11.4.0 allows an authenticated party in one tenant to access sessions, data, and endpoints of another tenant.