Vulnerabilities

SuperTokens is an open source authentication provider that many teams run themselves to handle sign-up, login and sessions. Its licensed multi-tenant mode lets one deployment serve many separate applications, each with its own tenant, its own users and its own API key (an application programming interface key, the secret a service sends to prove it is allowed to call the management interface). A software platform that gives each customer a walled-off space usually builds that wall on exactly this feature.

A flaw now tracked as CVE-2026-123800, rated 9.9 out of 10 on the CVSS version 3.1 severity scale (the Common Vulnerability Scoring System, the standard 0 to 10 measure of how serious a flaw is), breaks that wall. An attacker who holds the valid API key for one application can rewrite the key that sits above it and reach into every sibling application in the same deployment. One leaked or over-shared key stops being a single-tenant problem and becomes a deployment-wide one.

How it works

SuperTokens Core arranges tenants in a hierarchy. A connection URI domain (Uniform Resource Identifier, the address and scope a tenant is reached through) sits at the top, and applications live underneath it. Each application is handed an API key scoped to that application, which should let it manage only its own tenant. The design intent is that a child key cannot touch the parent domain or any neighbour.

The method that enforces this is Multitenancy.checkPermissionsForCreateOrUpdate, in src/main/java/io/supertokens/multitenancy/Multitenancy.java. On a create or update request it is supposed to confirm that the caller actually owns the parent connection URI domain or the base tenant before allowing a change to it. It does not. The check on the domain never requires the requesting application and tenant to be the public, top-level ones, so a call carrying a child application's key passes a permission test it should fail.

Because the api_keys field is left unprotected by that check, the consequences run straight to credential takeover. The attacker uses their valid child key to issue an update against the parent connection URI domain and writes a new set of keys. That overwrites the parent key and the keys of sibling applications in one move.

With the sibling keys replaced, the rest follows. The attacker can read and modify users in sibling tenants, mint sessions as those users, plant a dashboard user to keep access after the keys are rotated, and lock a sibling application out of its own key. SuperTokens classes the flaw under two entries in the CWE list (Common Weakness Enumeration, the standard catalogue of software weakness types): CWE-639, authorization bypass through a user-controlled key, and CWE-863, incorrect authorization. Both describe a check that trusts input it should verify.

There is a second path through the same method. In the version 2 create and update handlers, leaving out the optional tenant identifier makes the call target the base tenant, and that route skips both the permission checks and the gate that is supposed to require an enterprise licence. Through it an attacker can change login settings on the base tenant: which first factors are allowed, which secondary factors are required, and which recipes are switched on. That variant still refuses changes to coreConfig and does not expose the keys, so it damages login integrity and availability rather than handing over credentials.

Who is affected and why it matters

The flaw only bites licensed multi-tenant SuperTokens Core deployments that run several applications under one non-default connection URI domain with separate API keys. A single-tenant install, or one that never issues a child key, is not in the blast radius. Affected versions start at 6.0.0 and run up to the patched release on each line.

The deployments that match this description tend to be the ones where it hurts most. A software-as-a-service product (SaaS, software delivered over the internet to many customers at once) that gives every customer its own tenant is the textbook case, and so is an internal platform that carves out a tenant per team or per application. In both, the whole point of the setup is that one tenant cannot see another.

The reason the rating reached 9.9 is the scope change built into the attack. The attacker needs only low privilege, one legitimate child key, and from that single foothold the impact crosses a trust boundary into tenants they were never issued access to. A shared continuous-integration token, a key checked into a repository, or one careless customer is enough to put every neighbour at risk. SuperTokens disclosed this on November 9, 2026.

What to do

Upgrade SuperTokens Core to the patched release on your line. The fix shipped across every supported branch, including v9.3.5, v10.1.9 and v11.0.9; if you are on an older or different line, take its patched build (for example 6.0.24, 8.0.7 or 12.3.1) rather than assuming one of those three applies to you. The advisory GHSA-4rf2-xqvf-8rcx lists the full set.

Rotate keys after upgrading, and treat this as mandatory rather than optional. A child key that was leaked or shared before you patched may already have been used to overwrite the keys above and beside it, so rotate every tenant API key and the parent connection URI domain key. Patching closes the hole; it does not undo a key that was already swapped.

Go back through your SuperTokens logs for tenant and application create and update calls, and for any change to an API key. Pay attention to calls that targeted the parent connection URI domain or the base tenant, and to version 2 handler calls that omitted the tenant identifier, since that is the base-tenant path. An update to the parent domain from an application that should only manage itself is the signal to look for.

Restrict who can reach the Core management interface. It should sit behind your network perimeter and accept requests only from the services that genuinely administer tenants, not from general application traffic. Then review your tenant isolation model as a whole and confirm no single key, if abused, can act beyond its own tenant. A related but separate SuperTokens Core flaw, CVE-2026-123797, is a tenant-path bypass fixed in 11.3.6, 11.4.6 and 12.0.8, so check your version against that one too while you are in the release notes.

This is the class of bug that a careful review of authentication and authorization logic is built to catch: a privileged action that trusts the caller's own input to decide whether the caller is allowed. We look for exactly this kind of failing check in web application testing and in red team code review, where reading the authorization path is often the fastest way to find a cross-tenant break. If you run SuperTokens or any shared authentication service and want a second set of eyes on its isolation model, open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: Rapid7 on CVE-2026-123800, OpenCVE entry for CVE-2026-123800, SuperTokens advisory GHSA-4rf2-xqvf-8rcx, OpenCVE entry for CVE-2026-123797.