CVE-2026-123801 · Package
NO FIX YET · SEE WHAT TO DO
SuperTokens Core, an open source authentication server, does not check SAML login responses for replay or the expected recipient and session. An attacker who captures a valid SAML response can resubmit it before it expires and obtain a fresh authorization code for the captured user's identity.
first public Nov 9, 2026 · 1 source
Could this affect your app?
Free first check from your website. Connect your repo for the full answer.
Teams that run a self-hosted SuperTokens Core server with the SAML login flow enabled on a version in the affected ranges (11.3.0 to 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, 12.3.1 before their fixes). Deployments using only other login methods, or managed hosting where the vendor operates the core, can skip it.
Not affected if managed-hosting, saml-not-enabled
Who cares authentication, saml, self-hosted, supertokens-core
/recipe/saml/callback in use)11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, 12.3.1 (fixed in the version line matching your install)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.
Are you affected?
Tell InfraStack what you run. It checks this one, and every next one, against your stack.
Ask from here. InfraStack checks the affected versions against your stack and answers in your inbox.
InfraStack checks the affected versions against your stack and answers in Slack, with the evidence and the fix.
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.