W
WHITENBAKER
Adversarial Security Research
← Advisories
Cross-tenant session trust in SuperTokens Core
Core honors a session’s embedded tenant claim without checking it against the tenant context of the request — so a token minted for one tenant is accepted, verbatim, by another.
The boundary, and the crossing
A session signed for Tenant A is replayed against Tenant B’s endpoint
The signature was never the problem. The trust was.
Core reads the tenant from the token, not from the request — and the token is signed by the same key for every tenant.
Technical analysis
SuperTokens Core derives the tenant for a session operation from the tId claim carried inside the session token, rather than from the tenant context of the incoming request path. The claim is never compared against the request’s tenant.
In a multitenant deployment, every tenant’s endpoints live under a tenant-scoped path — /tenant-a/…, /tenant-b/…. The expectation is that a session issued under one tenant is meaningful only within that tenant. But Core validates a session by verifying its signature and reading its embedded tId — and because every tenant is served by the same Core signing key, a token minted in Tenant A carries a perfectly valid signature when presented to Tenant B. No check reconciles the token’s tenant with the path’s tenant, so the operation proceeds against Tenant B as though the caller belonged there.
The result is a complete collapse of the isolation boundary that multitenancy exists to provide. The three scenarios below were confirmed against a running Core instance; each returned 200 OK with cross-tenant data.
Scenario A — Cross-tenant session verification
POST /tenant-b/recipe/session/verify {"accessToken":"<tenant-a token>","doAntiCsrfCheck":false, "enableAntiCsrf":false,"checkDatabase":false} → 200 OK "status":"OK" # tenant-a session data returned
Scenario B — Cross-tenant data exfiltration
GET /tenant-b/recipe/session?sessionHandle=<tenant-a-handle> → 200 OK userDataInDatabase from tenant-a returned, including {"secretField":"tenant-a-private-db-data"}
Scenario C — Cross-tenant JWT claim injection
POST /tenant-b/recipe/session/regenerate {"accessToken":"<tenant-a token>", "userDataInJWT":{"injected":"INJECTED-FROM-TENANT-B"}} → 200 OK new RS256-signed JWT returned carrying attacker claims
Related cross-tenant findings
The same missing check surfaces across the multitenancy surface. Each of the following was independently confirmed and stems from the identical failure to bind an operation to the request’s tenant:
| Finding | Weakness | CVSS |
|---|---|---|
| Cross-tenant user hijack — associate a victim’s account into a second tenant, then authenticate as them | CWE-863 | 6.5 |
| Cross-tenant password-reset token consumption — a reset token issued in one tenant is accepted by another | CWE-863 | 7.4 |
| Cross-tenant role injection — roles defined in one tenant assigned via another tenant’s endpoint | CWE-863 | 6.5 |
| Unauthenticated metadata & MFA read/write — in default config, any user’s metadata and MFA factors can be read, rewritten, or cleared (e.g. silently disabling MFA) | CWE-306 | 6.5 |
The obvious mitigation does not hold. SuperTokens Core ships without API-key authentication by default, but the cross-tenant operations above were re-confirmed with a valid API key configured and enforced (verified: 401 without the key, success with it). API-key auth gates who may talk to Core — it does not bind an operation to a tenant. The isolation boundary stays open until the tenant claim is validated against the request.
Multitenancy promises one thing: tenants cannot see each other.
For deployments serving distinct customers from one Core, that promise does not hold across v6.0.0–v11.4.0.
Impact
SuperTokens’ multitenancy is built for B2B SaaS, where a single deployment isolates many customer organizations. Under this flaw, any party able to obtain a legitimate session in its own tenant can reach across the boundary: read another tenant’s session data, hijack accounts between tenants, consume cross-tenant reset tokens, and inject roles. In a default-configuration deployment, the metadata and MFA surface is reachable without authentication at all. The confidentiality and integrity guarantees that justify a shared multitenant deployment do not survive these operations.
Affected operators requiring remediation guidance should contact Whitenbaker Security Research.
Disclosure timeline
Initial disclosure. Tenant-separation failure reported to SuperTokens under coordinated disclosure, opening a 90-day window.
Vendor response. API-key authentication proposed as a mitigation.
Follow-up. Demonstrated that the cross-tenant operations persist with a valid API key enforced; reaffirmed the disclosure deadline.
CVE assigned. MITRE assigned CVE-2026-37171.
Public advisory. 90-day window elapsed; this advisory published.
Whitenbaker
Adversarial security research — silent-patch detection, vulnerability disclosure, and the gap between what vendors ship and what they tell you.
Drew Morana · @dmorana