CVE-2026-123801: 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
What does an attacker need to exploit the SAML flow?
For an SP-initiated login, the attacker needs a legitimately issued, still-valid SAMLResponse and its matching RelayState, and must submit them before the assertion's NotOnOrAfter time. For an IdP-initiated login, the assertion can be replayed without RelayState.
Does setting allowIDPInitiatedLogin=false prevent this issue?
No. The missing Response.InResponseTo validation fails to enforce allowIDPInitiatedLogin=false, and can also allow an in-progress login to be completed using an assertion for a different identity.
What is the result of a successful replay?
Each accepted callback creates a new, independently redeemable authorization code carrying the identity in the captured assertion. Replaying the same accepted assertion can therefore produce multiple authorization codes.
Which releases include the fix?
The issue is fixed in versions 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 12.3.1.