GHSA-4rf2-xqvf-8rcx: SuperTokens Core: App-scoped API key can overwrite the parent connection URI domain's credentials and take over sibling applications
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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
SuperTokens Coreto a version that resolves this vulnerability.Fixed in 6.0.24 - Upgrade
Upgrade
SuperTokens Coreto a version that resolves this vulnerability.Fixed in 7.0.23 - Upgrade
Upgrade
SuperTokens Coreto a version that resolves this vulnerability.Fixed in 8.0.7 - Upgrade
Upgrade
SuperTokens Coreto a version that resolves this vulnerability.Fixed in 9.0.6 - Upgrade
Upgrade
SuperTokens Coreto a version that resolves this vulnerability.Fixed in 9.1.6 - Upgrade
Upgrade
SuperTokens Coreto a version that resolves this vulnerability.Fixed in 9.2.7 - Upgrade
Upgrade
SuperTokens Coreto a version that resolves this vulnerability.Fixed in 9.3.5 - Upgrade
Upgrade
SuperTokens Coreto a version that resolves this vulnerability.Fixed in 10.0.8 - Upgrade
Upgrade
SuperTokens Coreto a version that resolves this vulnerability.Fixed in 10.1.9 - Upgrade
Upgrade
SuperTokens Coreto a version that resolves this vulnerability.Fixed in 11.0.9 - Upgrade
Upgrade
SuperTokens Coreto a version that resolves this vulnerability.Fixed in 11.1.4 - Upgrade
Upgrade
SuperTokens Coreto a version that resolves this vulnerability.Fixed in 11.2.4 - Upgrade
Upgrade
SuperTokens Coreto a version that resolves this vulnerability.Fixed in 11.3.8 - Upgrade
Upgrade
SuperTokens Coreto a version that resolves this vulnerability.Fixed in 11.4.8 - Upgrade
Upgrade
SuperTokens Coreto a version that resolves this vulnerability.Fixed in 12.0.11 - Upgrade
Upgrade
SuperTokens Coreto a version that resolves this vulnerability.Fixed in 12.1.2 - Upgrade
Upgrade
SuperTokens Coreto a version that resolves this vulnerability.Fixed in 12.2.1 - Upgrade
Upgrade
SuperTokens Coreto a version that resolves this vulnerability.Fixed in 12.3.1
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
The issue affects licensed multi-tenant deployments that host multiple applications under one non-default connection URI domain and use separate API keys. The affected releases include versions from 6.0.0 up to the listed fixed releases through 12.3.1.
What access does an attacker need to exploit this vulnerability?
An attacker needs a valid API key for one application sharing the affected non-default connection URI domain. No user interaction is required, and the attacker can use that key to target the parent domain or, through the v2 handlers, omit the optional identifier to target the base tenant.
What could indicate that sibling applications have been compromised?
Indicators include unexpected replacement of the parent-domain or sibling application API keys, unauthorized changes to sibling users, sessions issued as sibling users, or an unexpected dashboard user in a sibling application. A compromised application may also be unable to use its own API key after it has been replaced.