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

Q: Which deployments are exposed to the described cross-application takeover?

The described attack requires a licensed multi-tenant deployment with multiple applications under the same non-default connection URI domain, where the applications have separate API keys. The issue targets authorization for the parent connection URI domain or base tenant.

Q: What access does an attacker need to exploit this issue?

An attacker needs a valid API key for one application sharing the affected connection URI domain. They can use that app-scoped key to update the parent domain and replace its API key, then target sibling applications.

Q: What can an attacker do after replacing the parent domain key?

They can replace sibling application keys, read or modify sibling users, and obtain sessions as sibling users. They may also create persistence through a sibling dashboard user and lock out a sibling application's original API key.

Published Nov 9, 2026

Updated

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

Affected Software

1 affected component

SuperTokens SuperTokens Core>=6.0.0<6.0.24, >=7.0.0<7.0.23, >=8.0.0<8.0.7, >=9.0.0<9.0.6, >=9.1.0<9.1.6, >=9.2.0<9.2.7, >=9.3.0<9.3.5, >=10.0.0<10.0.8, >=10.1.0<10.1.9, >=11.0.0<11.0.9, >=11.1.0<11.1.4, >=11.2.0<11.2.4, >=11.3.0<11.3.8, >=11.4.0<11.4.8, >=12.0.0<12.0.11, >=12.1.0<12.1.2, >=12.2.0<12.2.1, >=12.3.0<12.3.1

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade SuperTokens Core to a version that resolves this vulnerability.
Fixed in 6.0.24
Upgrade
Upgrade SuperTokens Core to a version that resolves this vulnerability.
Fixed in 7.0.23
Upgrade
Upgrade SuperTokens Core to a version that resolves this vulnerability.
Fixed in 8.0.7
Upgrade
Upgrade SuperTokens Core to a version that resolves this vulnerability.
Fixed in 9.0.6
Upgrade
Upgrade SuperTokens Core to a version that resolves this vulnerability.
Fixed in 9.1.6
Upgrade
Upgrade SuperTokens Core to a version that resolves this vulnerability.
Fixed in 9.2.7
Upgrade
Upgrade SuperTokens Core to a version that resolves this vulnerability.
Fixed in 9.3.5
Upgrade
Upgrade SuperTokens Core to a version that resolves this vulnerability.
Fixed in 10.0.8
Upgrade
Upgrade SuperTokens Core to a version that resolves this vulnerability.
Fixed in 10.1.9
Upgrade
Upgrade SuperTokens Core to a version that resolves this vulnerability.
Fixed in 11.0.9
Upgrade
Upgrade SuperTokens Core to a version that resolves this vulnerability.
Fixed in 11.1.4
Upgrade
Upgrade SuperTokens Core to a version that resolves this vulnerability.
Fixed in 11.2.4
Upgrade
Upgrade SuperTokens Core to a version that resolves this vulnerability.
Fixed in 11.3.8
Upgrade
Upgrade SuperTokens Core to a version that resolves this vulnerability.
Fixed in 11.4.8
Upgrade
Upgrade SuperTokens Core to a version that resolves this vulnerability.
Fixed in 12.0.11
Upgrade
Upgrade SuperTokens Core to a version that resolves this vulnerability.
Fixed in 12.1.2
Upgrade
Upgrade SuperTokens Core to a version that resolves this vulnerability.
Fixed in 12.2.1
Upgrade
Upgrade SuperTokens Core to a version that resolves this vulnerability.
Fixed in 12.3.1

Event History

Nov 9, 2026

CVE Published

via MITRE·06:16 PM

Data Sourced

via MITRE·06:16 PM

DescriptionSeverityWeakness

Frequently Asked Questions

Which deployments are exposed to the described cross-application takeover?

The described attack requires a licensed multi-tenant deployment with multiple applications under the same non-default connection URI domain, where the applications have separate API keys. The issue targets authorization for the parent connection URI domain or base tenant.

What access does an attacker need to exploit this issue?

An attacker needs a valid API key for one application sharing the affected connection URI domain. They can use that app-scoped key to update the parent domain and replace its API key, then target sibling applications.

What can an attacker do after replacing the parent domain key?

They can replace sibling application keys, read or modify sibling users, and obtain sessions as sibling users. They may also create persistence through a sibling dashboard user and lock out a sibling application's original API key.

Is there a base-tenant path that bypasses the normal permission checks?

In the advisory's v2 create or update handlers, omitting the optional identifier creates a base-tenant target. That target skips the permission branches and the enterprise-feature gate.