Keycloak-core: keycloak-core: saml adapter does not bind signed assertions to the configured identity provider issuer
Affects Red Hat Keycloak-based SAML setups where one signing key is shared across multiple SAML issuers or tenants and the application trusts that key. No fixed version is given in the checked facts.
Written by anthropic/claude-haiku-5.5 from the sources below. Verify against them.
- Exploited
- No known exploitation
- Fix
- No fix listed
- Who is exposed
- Not reported
Do first: Workaround: The checked facts give no workaround. The affected setup depends on one signing key being shared across issuers or tenants, so using a separate signing key for each identity provider removes that condition.
- 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? →
- 40/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? →
- Unclear
- 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
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
The SAML adapter in Keycloak fails to check that a signed assertion came from the expected identity provider, so an attacker who controls one of several providers sharing the same trusted signing key can log in as any user, potentially gaining full administrative control. The attack can be carried out remotely over the network without logging in.
Read the original description
A flaw was found in the SAML adapter component of Keycloak, which is used to secure applications with SAML-based authentication. The adapter fails to verify that the issuer of a signed SAML assertion matches the expected identity provider configured for the application. If multiple identity providers share the same trusted signing key, an attacker who controls one of those providers can create a validly signed assertion to log into the application as any user, potentially gaining full administrative control.
cve.now Index
- Exploitation0/40No signal
- Exposure17/25No login or user action needed, reachable over the network without a login · Unknown: Advisories don't say whether default setups are affected
- Reach10/20Shipped in major Linux distributions
- Severity8.4/10CVSS 7.4, total technical impact per CISA
- No patch5/5No patch listed yet
What would change the score
- Would score about 85 if added to CISA KEV
- Would score about 80 if CISA's SSVC rates exploitation active
- Would score about 45 if advisories confirm default setups are exposed
What to do
Workaround: The checked facts give no workaround. The affected setup depends on one signing key being shared across issuers or tenants, so using a separate signing key for each identity provider removes that condition.
Timeline
- CVE published
- First seen by cve.now
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- keycloak-core
Version range not reported
- keycloak-core
Version range not reported
- keycloak/rhbk-openshift-rhel9
Version range not reported
- keycloak/rhbk-rhel9-operator
Version range not reported
- rhbk/keycloak-rhel9
Version range not reported
- rhbk/keycloak-rhel9-operator
Version range not reported
- keycloak-core
Version range not reported
- jboss-eap-7/eap74-els-openjdk11-openshift-rhel8
Version range not reported
Show all 14 packagesShow fewer packages
- jboss-eap-7/eap74-els-openjdk17-openshift-rhel8
Version range not reported
- jboss-eap-7/eap74-els-openjdk8-openshift-rhel8
Version range not reported
- keycloak-core
Version range not reported
- keycloak-core
Version range not reported
- candlepin
Version range not reported
- keycloak-core
Version range not reported
Evidence 2
- Report
- Link
Corrections
None so far.
Something wrong on this page? Report an error. Every fix is listed here.
Questions about CVE-2026-93998
Is CVE-2026-93998 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 SAML adapter does not check that a signed assertion comes from the configured identity provider issuer. A validly signed assertion from another provider that shares the same signing key can therefore be accepted, including any roles it contains.Source: bugzilla.redhat.com, access.redhat.com
Am I affected, and how do I check?
The checked facts list Red Hat Build of Keycloak, Red Hat Single Sign-On 7, and several JBoss EAP, Fuse, AMQ Broker, and Satellite 6 products, but give no version ranges. The affected setup is one where a single signing key is shared across multiple SAML issuers or tenants and the application trusts that key. To check, confirm the configured identity provider issuer and whether the signing key is shared with other providers.Source: bugzilla.redhat.com, access.redhat.com
How do I fix CVE-2026-93998?
The checked facts do not name a fixed release or upgrade target. Check Red Hat's advisory for the fixed version of each listed product.Source: bugzilla.redhat.com, access.redhat.com
What if there's no patch?
The checked facts give no workaround. The affected setup depends on one signing key being shared across issuers or tenants, so using a separate signing key for each identity provider removes that condition.Source: bugzilla.redhat.com, access.redhat.com