Skip to main content
cve.nowby Sazabi
← Vulnerabilities
CVE-2026-123800EUVD-2026-120149

SuperTokens Core: App-scoped API key can overwrite the parent connection URI domain's credentials and take over sibling applications

Only affects SuperTokens Core deployments with the licensed multi-tenancy feature and several apps under one non-default connection URI domain, each with separate api_keys. Fixed in the patch release for each version line.

Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.

9.9CriticalCNA
Exploited
No known exploitation
Fix
Fixed in 6.0.24, 7.0.23, 8.0.7, 9.0.6, 9.1.6, and 13 more
Who is exposed
Specific setups only

Do first: Check whether your setup matches what the bug needs. Multi-tenancy feature enabled, which requires a licensed deployment Multiple apps placed under one non-default connection URI domain, each with separate api_keys Attacker holds a valid API key for one application under the connection URI domain

Published
Last modified
18/100 · provisional
Specific setups only
None on Exploit-DB, Metasploit or GitHub
On X
View the cve.now post

Summary

SuperTokens Core, an open source authentication server, has a flaw in its multi-tenant permission checks that lets someone holding a valid API key for one application in a multi-application deployment change the parent connection URI domain and the base tenant. The attacker can reach it remotely over the network with low-privilege login, and a successful attack can take over sibling applications' credentials, users, and sessions, and alter login settings.

Read the original description

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 api_keys, 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 api_keys 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.

cve.now Index

18Pcve.now Index 18 of 100 · methodology v3 · provisional
  • Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
  • Exposure8/25Specific setups only, reachable over the network
  • Reach?/20Unknown. No tracked technology or package matched
  • Severity9.9/10CVSS 9.9
  • No patch0/5No signal

What would change the score

  • Would score about 68 if added to CISA KEV
  • Would score about 63 if CISA's SSVC rates exploitation active
  • Would score about 25 if CISA's SSVC rates it automatable

How the score works · Rankings

What to do

  • Check whether your setup matches what the bug needs.

    Multi-tenancy feature enabled, which requires a licensed deployment Multiple apps placed under one non-default connection URI domain, each with separate api_keys Attacker holds a valid API key for one application under the connection URI domain

  • Upgrade to a fixed version: 6.0.24, 7.0.23, 8.0.7, 9.0.6, 9.1.6, or one of 13 more.

Timeline

  1. CVE published
  2. First seen by cve.now
  3. Posted on X by cve.now

Affected versions

  • supertokens supertokens-core

    From 6.0.0 · fixed in 6.0.24; From 7.0.0 · fixed in 7.0.23; From 8.0.0 · fixed in 8.0.7; From 9.0.0 · fixed in 9.0.6; From 9.1.0 · fixed in 9.1.6; From 9.2.0 · fixed in 9.2.7; From 9.3.0 · fixed in 9.3.5; From 10.0.0 · fixed in 10.0.8; From 10.1.0 · fixed in 10.1.9; From 11.0.0 · fixed in 11.0.9; From 11.1.0 · fixed in 11.1.4; From 11.2.0 · fixed in 11.2.4; From 11.3.0 · fixed in 11.3.8; From 11.4.0 · fixed in 11.4.8; From 12.0.0 · fixed in 12.0.11; From 12.1.0 · fixed in 12.1.2; From 12.2.0 · fixed in 12.2.1; From 12.3.0 · fixed in 12.3.1

Evidence 25

  1. Advisory
  2. Repository
  3. Repository
  4. Repository
  5. Repository
Show all 25 sourcesShow fewer sources
  1. Repository
  2. Repository
  3. Repository
  4. Repository
  5. Repository
  6. Repository
  7. Repository
  8. Repository
  9. Repository
  10. Repository
  11. Repository
  12. Repository
  13. Repository
  14. Repository
  15. Repository
  16. Repository
  17. Repository
  18. Repository
  19. Repository
  20. Repository

Corrections

None so far.

Something wrong on this page? Report an error. Every fix is listed here.

Questions about CVE-2026-123800

Is CVE-2026-123800 being exploited?

It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data

What does this mean?

An app-scoped API key can overwrite the credentials of the parent connection URI domain. This lets an attacker with a valid key for one app gain full read and write access to a sibling app's users and sessions, authenticate as its users, keep a persistent foothold through a dashboard user, and lock the victim app out of its own key.Source: github.com

Which versions are affected by CVE-2026-123800?

supertokens-core: from 6.0.0 before 6.0.24; from 7.0.0 before 7.0.23; from 8.0.0 before 8.0.7; from 9.0.0 before 9.0.6; from 9.1.0 before 9.1.6; from 9.2.0 before 9.2.7; from 9.3.0 before 9.3.5; from 10.0.0 before 10.0.8; from 10.1.0 before 10.1.9; from 11.0.0 before 11.0.9; from 11.1.0 before 11.1.4; from 11.2.0 before 11.2.4; from 11.3.0 before 11.3.8; from 11.4.0 before 11.4.8; from 12.0.0 before 12.0.11; from 12.1.0 before 12.1.2; from 12.2.0 before 12.2.1; from 12.3.0 before 12.3.1.Source: cve.now feed data

Am I affected, and how do I check?

Affected are supertokens-core releases from 6.0.0 up to, but not including, the fixed release on each line (for example 6.0.24, 7.0.23, 8.0.7, 9.0.6, 10.0.8, 11.0.9, 12.0.11, 12.3.1). The setup needs the licensed multi-tenancy feature with more than one app under one non-default connection URI domain, each with its own api_keys. Check the installed supertokens-core version and whether multiple apps share a non-default connection URI domain with separate api_keys.Source: github.com

How do I fix CVE-2026-123800?

Upgrade to the fixed release for your version line: 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, or 12.3.1.Source: github.com

Sources

CVSS details

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Related

More vulnerabilities