Security Advisory

CVE-2026-37171: SuperTokens Core Cross-Tenant Session Bypass

Last updated:
  • CVE-2026-37171

CVE-2026-37171 is a CWE-863 (Incorrect Authorization) flaw in SuperTokens Core, a self-hosted/managed authentication backend, where the Core service trusts the tenant claim embedded inside a session token instead of checking it against the tenant the request is actually addressed to, and because every tenant's tokens are signed with the same shared key, a valid session issued to one tenant passes signature verification when replayed against a completely different tenant's endpoints.

Vulnerability summary

9.6

Critical

0.3%

EPSS score (FIRST)

No

CISA KEV catalog

2026-08-07

Published

Vulnerability ID: CVE-2026-37171 · Source: NVD

Affected components

ComponentCPEVersion range
SuperTokens Corecpe:2.3:a:supertokens:supertokens:*:*:*:*:*:*:*:*6.0.0 through 11.4.0

What this means

CVE-2026-37171 affects SuperTokens Core, the backend service behind the SuperTokens open-source and managed authentication platform used to add login, session management, and multi-tenant auth to applications. The independent advisory that disclosed the flaw lays out the root cause directly: "Core reads the tenant from the token, not from the request" and "the token is signed by the same key for every tenant" (SuperTokens Core Multitenant Advisory, whitenbaker.com).

Because a single signing key is shared across all tenants in a multitenant Core deployment, a session token legitimately issued to a user of Tenant A carries a cryptographically valid signature when presented to Tenant B's endpoints, for example /tenant-b/recipe/session/verify. Core verifies the signature, accepts the token, and never cross-checks the tenant claim embedded in the token against the tenant path the request was actually sent to. The advisory documents this as enabling cross-tenant session verification, exfiltration of another tenant's stored session data, and injection of attacker-controlled claims via cross-tenant token regeneration (SuperTokens Core Multitenant Advisory, whitenbaker.com).

The advisory also addresses an obvious-looking but ineffective mitigation: API-key authentication in front of Core. It states plainly that "API-key auth gates who may talk to Core — it does not bind an operation to a tenant," meaning an API key only proves the caller is an authorized client of Core overall, not that a specific session belongs to the tenant it's being used against (SuperTokens Core Multitenant Advisory, whitenbaker.com).

NVD's own analysis rates this CVSS v3.1 Primary 9.6 (critical), vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H — network-reachable, low attack complexity, requiring only low privileges (a valid session in any one tenant), with a scope change because a session from one tenant compromises confidentiality and integrity of a different tenant's data. MITRE's own CNA submission scored it far lower at Secondary 5.9 (S:U, no scope change, high attack complexity), reflecting a narrower read of the blast radius than NVD's own Primary analysis; this page follows NVD's Primary rating as authoritative (NVD).

As of this review, the CVE is confirmed absent from the live CISA KEV catalog by exact cveID match, and FIRST scores the probability of exploitation at 0.00312 (24.13th percentile) as of 2026-10-30 — low but notably higher than a typical unauthenticated-only flaw, consistent with a SaaS/self-hosted multitenant auth backend where exploitation requires nothing more than an ordinary account in any one tenant (FIRST EPSS; CISA KEV catalog). The advisory does not state a specific patched version; any organization running a multitenant SuperTokens Core deployment between v6.0.0 and v11.4.0 should treat tenant boundaries as currently unenforced, check SuperTokens' own changelog/release notes for a fix before relying on tenant isolation for compliance or data-segregation requirements, and avoid substituting API-key gating for a genuine per-request tenant check.

How to fix this class of issueThis advisory does not name a weakness class we have a dedicated guide for yet. The fix is usually the vendor patch or firmware update referenced above — our guide below covers how to plan and verify that: NIST SP 800-40 Rev. 4: enterprise patch management planning, explained.

Evidence

  • SuperTokens Core reads the tenant from inside the session token rather than from the request, and signs tokens for every tenant with the same key, so a token valid in one tenant passes signature verification when replayed against another tenant's endpoint. — SuperTokens Core Multitenant Advisory, whitenbaker.com
  • Confirmed impacts include cross-tenant session verification, exfiltration of another tenant's stored session data, and injection of attacker-controlled claims via cross-tenant token regeneration; API-key authentication in front of Core does not mitigate this because it gates who may talk to Core, not which tenant an operation is bound to. — SuperTokens Core Multitenant Advisory, whitenbaker.com
  • NVD Primary CVSS v3.1 base score is 9.6 (critical), vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, affecting SuperTokens Core v6.0.0 through v11.4.0; the CNA (MITRE) Secondary score is lower, 5.9. — NVD
  • EPSS score is 0.00312 (24.13th percentile) as of 2026-10-30; the CVE is confirmed absent from the live CISA KEV catalog by exact cveID match this run. — FIRST EPSS

Related advisories

Sources

  1. SuperTokens Core Multitenant Advisory, whitenbaker.com
  2. NVD
  3. FIRST EPSS
  4. CISA KEV catalog