SuperTokens Core Multi-Tenant Authorization Bypass (CVE-2026-123800)

SuperTokens Core is an open-source authentication server. A licensed deployment can run multitenancy, where several applications sit under one connection URI domain (CUD) and each application keeps its own API key. The advisory says the server must confirm a caller's application and tenant before it accepts a change to that shared domain's own configuration.

The advisory's root-cause section names the function Multitenancy.checkPermissionsForCreateOrUpdate, in src/main/java/io/supertokens/multitenancy/Multitenancy.java. Per the advisory, the branch that checks a CUD-level target accepts a caller whose own connection-URI-domain string matches the target.

It does not also require that caller to be the domain's base tenant and public application, unlike the neighboring tenant-level and application-level branches. The advisory adds that api_keys is not on the list of protected configuration fields, so a request that passes the weaker branch can carry a replacement key.

What an Attacker Gains

The advisory describes a two-hop privilege escalation. First, an application's own API key rewrites the shared domain's api_keys, which hands the caller the domain's own public application. Second, acting as that public application, the same method rewrites a sibling application's api_keys.

The advisory says the attacker can then read and change the sibling's users, and have the core issue sessions for any of them. It adds that the attacker can plant a persistent dashboard user, while the sibling's original key stops working.

The advisory names a second, narrower path. Per the advisory, the create-or-update handlers treat an omitted identifier as a request aimed at the base tenant. The same three permission branches all evaluate as false there, skipping the check entirely for that shape. The advisory says this path cannot carry a new API key, so it reaches fields such as firstFactors and the enterprise-feature gate instead.

How the Score Reads

GitHub, the CNA, scores CVE-2026-123800 at CVSS 3.1 9.9, vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. NVD lists the same score and vector as a secondary source; its own entry shows status Received, meaning NVD has not yet published an independent score.

There is no CVSS 4.0 score in the record or NVD. The advisory lists Scope as Changed because the impact of one application's own key reaches a different application's data. See our CVSS entry for how to read the vector. The advisory credits five reporters for the two variants: GrayOM, Judel777, Winfunc Research (mufeedvh and 123vivekr), Feldspar-AI-Agent and hhh0710.

What the Maintainers and CISA KEV Say

The advisory's own Patches field still reads "Pending." GitHub's release records show the fix shipped the same day the advisory was published: all 18 patched versions, from 6.0.24 through 12.3.1, carry a published timestamp of 16 October 2026. The 12.3.1 release notes name GHSA-4rf2-xqvf-8rcx directly as a fix in that build. We read the advisory's wording as describing the fix design, not the release state.

As of CISA catalog version 2026.11.09, the CVE is not in the Known Exploited Vulnerabilities catalog. No public report of exploitation found as of 9 November 2026. Our KEV glossary entry explains the catalog.

The CVE record and the GitHub advisory both list the same 18 affected release branches of SuperTokens Core, each with its own fixed point release. The ranges below are the vendor's own open-ended notation; we have not filled in an assumed last affected build for each branch.

The advisory limits the precondition to licensed multi-tenant deployments that place more than one application under one connection URI domain, each with its own API key. A single-tenant deployment, or a multi-tenant one where every application sits under its own domain, does not meet that precondition. The advisory says it reproduced the issue on a published 12.2.0 PostgreSQL image, and that the vulnerable branch has been present since version 10.0.0.

The advisory's own Workarounds field says none exist at the configuration level for an affected deployment shape. We recommend upgrading the core to the fixed point release on your branch. We also recommend rotating every API key under the affected connection URI domain afterward, since the flaw's own impact is key theft.