CVE-2026-123801 json
SuperTokens Core: SAML callback accepts a replayed RelayState + SAMLResponse, minting a fresh authorization code on each replay
published 5h ago modified 4h ago also EUVD-2026-120152
- cvss
- 7.4
- version 3.1, CNA
- cisa kev
- Not listed
- not in CISA's catalog
- epss
- —
- no EPSS score yet
- public exploits
- 0
- none known
Summary
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.
Patch / fix
- github.com/supertokens/supertokens-core@0756552 commit
- github.com/supertokens/supertokens-core@4e05d8c commit
- github.com/supertokens/supertokens-core@5578354 commit
- github.com/supertokens/supertokens-core@5c42f02 commit
- github.com/supertokens/supertokens-core@b6730e6 commit
- github.com/supertokens/supertokens-core@ca2bca9 commit
- github.com/supertokens/supertokens-core/releases/tag/v11.3.8 release
- github.com/supertokens/supertokens-core/releases/tag/v11.4.8 release
- github.com/supertokens/supertokens-core/releases/tag/v12.0.11 release
- github.com/supertokens/supertokens-core/releases/tag/v12.1.2 release
Is CVE-2026-123801 in your stack? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.
Check with FencerCVSS scores
| assigned by | version | score | vector |
|---|---|---|---|
| CNA | 3.1 | 7.4 | CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N |
Affected products
- supertokens supertokens-core
Classification
References
- github.com /supertokens/supertokens-core/commit/075655222f5e72f3683a127e45c83c4174fbd4f7
- github.com /supertokens/supertokens-core/commit/4e05d8cf60287e9d2720140031a8b8f4430d056f
- github.com /supertokens/supertokens-core/commit/557835406547d269f5d0e33159630a1873461c38
- github.com /supertokens/supertokens-core/commit/5c42f02e98f67174c6a5a800dd9f8bd5b6e98486
- github.com /supertokens/supertokens-core/commit/b6730e608b2d4562939cd4f41ea07df5f841dfe5
- github.com /supertokens/supertokens-core/commit/ca2bca9bc900c2fd399d508818ad026cc977dcf6
- github.com /supertokens/supertokens-core/security/advisories/GHSA-3r7x-rhvc-fw28
- github.com /supertokens/supertokens-core/releases/tag/v11.3.8
- github.com /supertokens/supertokens-core/releases/tag/v11.4.8
- github.com /supertokens/supertokens-core/releases/tag/v12.0.11
- github.com /supertokens/supertokens-core/releases/tag/v12.1.2
- github.com /supertokens/supertokens-core/releases/tag/v12.2.1
- github.com /supertokens/supertokens-core/releases/tag/v12.3.1
Sources
- CVE List CVE-2026-123801
- NVD CVE-2026-123801
Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.