SuperTokens Core SAML: identity taken from an assertion that never passed the audience check, allowing sign-in as any IdP user
Affects supertokens-core SAML setups where the identity provider signs assertions rather than the SAML Response. Fixed in 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1 and 12.3.1.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- Fixed in 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, and 1 more
- Who is exposed
- Specific setups only
Do first: Check whether your setup matches what the bug needs. The SAML enterprise feature is licensed and at least one SAML client is configured. The identity provider signs assertions rather than the SAML Response.
- Last modified
- A 0-100 score for how much a CVE matters across the industry: exploitation, exposure, how widely the software is used, severity and whether a fix exists.What do these mean? →
- 16/100 · provisional
- How many real-world setups can hit the bug, from the vendor's advisory and CISA data. It does not know your setup.What do these mean? →
- Specific setups only
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
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, a licensed deployment with a configured SAML client can authenticate an identity from an assertion that did not satisfy the audience check. When the identity provider uses assertion-level signing, an attacker who has a still-valid IdP-signed assertion naming the victim for any audience and the attacker's own valid assertion for the target audience can combine them because validateSamlResponseAudience accepts an audience from one assertion while extractAllClaims takes the final NameID and attributes from another; response-level signing does not expose this multi-assertion variant. Independently, an assertion from an identity provider configured for the target deployment but issued to another SuperTokens deployment using the shared default saml_sp_entity_id can satisfy the target's audience check. Successful exploitation authenticates the attacker as the victim IdP user. 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.
cve.now Index
- Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
- Exposure8/25Specific setups only, reachable over the network
- Reach?/20Unknown. No tracked technology or package matched
- Severity8.1/10CVSS 8.1
- No patch0/5No signal
What would change the score
- Would score about 66 if added to CISA KEV
- Would score about 61 if CISA's SSVC rates exploitation active
- Would score about 23 if CISA's SSVC rates it automatable
What to do
Check whether your setup matches what the bug needs.
The SAML enterprise feature is licensed and at least one SAML client is configured. The identity provider signs assertions rather than the SAML Response.Upgrade to a fixed version: 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1, or one of 1 more.
Workaround: Set saml_sp_entity_id to a value unique to the deployment.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- supertokens supertokens-core
From 11.3.0 · fixed in 11.3.8; From 11.4.0 · fixed in 11.4.8; From 12.0.0 · fixed in 12.0.11; From 12.1.0 · fixed in 12.1.2; From 12.2.0 · fixed in 12.2.1; From 12.3.0 · fixed in 12.3.1
Evidence 18
- Advisory
- Repository
- Repository
- Repository
- Repository
Show all 18 sourcesShow fewer sources
- Repository
- Repository
- Repository
- Repository
- Repository
- Repository
- Repository
- Repository
- Repository
- Repository
- Repository
- Repository
- Repository
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-123802
Is CVE-2026-123802 being exploited?
It is not in CISA's Known Exploited Vulnerabilities catalog, and CISA's SSVC assessment does not mark exploitation as active. That does not mean it has not been attacked: vendors and researchers can report attacks before CISA lists them. No public exploit code is tracked.Source: cve.now feed data
What does this mean?
The core could take a user's identity from a SAML assertion that had not passed the audience check. That allowed sign-in as any user of the configured identity provider, with the email marked verified, at every application the core backs.Source: github.com
Which versions are affected by CVE-2026-123802?
supertokens-core: from 11.3.0 before 11.3.8; from 11.4.0 before 11.4.8; from 12.0.0 before 12.0.11; from 12.1.0 before 12.1.2; from 12.2.0 before 12.2.1; from 12.3.0 before 12.3.1.Source: cve.now feed data
Am I affected, and how do I check?
Versions 11.3.0 to before 11.3.8, 11.4.0 to before 11.4.8, 12.0.0 to before 12.0.11, 12.1.0 to before 12.1.2, 12.2.0 to before 12.2.1, and 12.3.0 to before 12.3.1 are in scope. The setup also needs the SAML enterprise feature licensed, at least one SAML client configured, and an identity provider that signs assertions rather than the Response; check the core version in use and whether SAML clients exist in the configuration.Source: github.com
How do I fix CVE-2026-123802?
Upgrade to 11.3.8, 11.4.8, 12.0.11, 12.1.2, 12.2.1 or 12.3.1, matching your release line. If upgrading is not possible yet, set saml_sp_entity_id to a value unique to the deployment as a workaround.Source: github.com