GHSA-3r7x-rhvc-fw28: SuperTokens Core: SAML callback accepts a replayed RelayState + SAMLResponse, minting a fresh authorization code on each replay
SuperTokens Core is an open source authentication server. From 11.3.0 until 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1, SAML.handleCallback does not consume RelayState, record assertion identifiers, or enforce Response.InResponseTo. In the SP-initiated flow, an attacker who obtains a legitimately issued, still-valid SAML response and its matching RelayState can resubmit the pair to /recipe/saml/callback before the assertion's NotOnOrAfter time; in the IdP-initiated flow, the assertion can be replayed without RelayState. The missing Response.InResponseTo check also permits an in-progress login to be completed with an assertion for a different identity and fails to enforce allowIDPInitiatedLogin=false. The callback does not validate Destination or SubjectConfirmationData Recipient and NotOnOrAfter, and each accepted callback mints a fresh, independently redeemable authorization code carrying the captured user's identity. This issue is fixed in versions 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 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 SAML deployments are exposed?
Deployments using the affected SuperTokens Core versions and the SAML callback endpoint are exposed. SP-initiated flows require a captured valid SAMLResponse and its matching RelayState; IdP-initiated assertions can be replayed without RelayState.
What does an attacker need to exploit the issue?
For an SP-initiated login, the attacker needs a legitimately issued, still-valid SAML response and the corresponding RelayState, then must submit them before the assertion's NotOnOrAfter time. For an IdP-initiated flow, the assertion can be replayed without RelayState.
Does setting allowIDPInitiatedLogin=false prevent this behavior?
No. The missing Response.InResponseTo validation means the callback fails to enforce allowIDPInitiatedLogin=false.
What is the practical result of a successful replay?
Each accepted callback creates a new, independently redeemable authorization code for the identity in the captured assertion. An in-progress login can also be completed using an assertion for a different identity.
Which versions contain the fix?
The issue is fixed in SuperTokens Core 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1.