Keycloak-services: keycloak-services: saml broker accepts holder-of-key assertions without proof of key possession
Only affects Keycloak configured as a SAML broker with a trusted upstream provider that issues holder-of-key assertions. No vendor rating or 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 only stated condition is the SAML broker setup with a trusted upstream provider issuing holder-of-key assertions, so limiting or disabling that brokering configuration is the only step the facts point to while no fix is available.
- 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? →
- 39/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
Summary
The SAML identity broker in Keycloak accepts holder-of-key assertions without checking that the user actually holds the matching private key, so an attacker who captures a victim's signed assertion can replay it. This can be done remotely, without logging in, and gives the attacker access to impersonate the victim.
Read the original description
A flaw was found in the SAML identity broker component of Keycloak, which is used to delegate authentication to external identity providers. The issue occurs because the broker fails to verify that a user actually possesses the private key associated with a holder-of-key assertion. An attacker who intercepts a victim signed assertion can replay it to gain unauthorized access and impersonate the victim without needing their private key.
cve.now Index
- Exploitation?/40Unknown. No CISA SSVC exploitation rating yet
- 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
- Severity7.4/10CVSS 7.4
- No patch5/5No patch listed yet
What would change the score
- Would score about 84 if added to CISA KEV
- Would score about 79 if CISA's SSVC rates exploitation active
- Would score about 44 if advisories confirm default setups are exposed
What to do
Workaround: The checked facts give no workaround. The only stated condition is the SAML broker setup with a trusted upstream provider issuing holder-of-key assertions, so limiting or disabling that brokering configuration is the only step the facts point to while no fix is available.
Timeline
- CVE published
- First seen by cve.now
Affected versions
- keycloak/rhbk-openshift-rhel9
Version range not reported
- keycloak-services
Version range not reported
- rhbk/keycloak-rhel9
Version range not reported
- keycloak-services
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-92855
Is CVE-2026-92855 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 broker accepts holder-of-key assertions without checking that the presenter holds the matching key. An attacker who holds a valid assertion for a victim can therefore impersonate that victim, gain full access to the victim account and downstream applications, and issue new downstream assertions for that identity.Source: bugzilla.redhat.com
Am I affected, and how do I check?
The checked facts list the affected products as Red Hat Build of Keycloak and Red Hat Single Sign-On 7, but give no version ranges. The stated condition is a SAML identity provider broker that trusts an upstream provider issuing holder-of-key assertions, which can be checked in the realm's identity provider settings and the server version shown in the admin console.Source: bugzilla.redhat.com
How do I fix CVE-2026-92855?
The checked facts do not name a fixed version, so check the Red Hat advisory for the patched release before planning an upgrade. Apply the update that the advisory specifies for your product line.Source: bugzilla.redhat.com
What if there's no patch?
The checked facts give no workaround. The only stated condition is the SAML broker setup with a trusted upstream provider issuing holder-of-key assertions, so limiting or disabling that brokering configuration is the only step the facts point to while no fix is available.Source: bugzilla.redhat.com