CVE-2026-92855 in Keycloak
Summary
by MITRE • 11/05/2026
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.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability identified in Keycloak's SAML identity broker component represents a critical failure in cryptographic verification within single sign-on architectures. This flaw specifically affects the mechanism used by Keycloak when acting as an identity provider or service provider to delegate authentication requests to external identity providers using Security Assertion Markup Language protocols. In standard OAuth and OpenID Connect flows, holder-of-key assertions are designed to bind access tokens to specific client instances through cryptographic proof of possession. However, in this SAML context, the broker fails to enforce the verification that the entity presenting the signed assertion actually holds the corresponding private key. This omission creates a significant gap between the theoretical security model and its practical implementation, allowing for authentication bypass scenarios that undermine the integrity of federated identity management systems.
From a technical perspective, the core issue lies in the validation logic during the SAML response processing phase. When an external identity provider issues a signed assertion containing user attributes and authentication statements, Keycloak is expected to validate not only the digital signature but also any binding mechanisms that require proof of possession. The absence of this check means that the system trusts the authenticity of the assertion based solely on its cryptographic signature from the trusted issuer, without verifying if the current session or client instance possesses the private key required by the holder-of-key profile. This design oversight effectively neutralizes one of the primary defenses against token theft and replay attacks in federated environments where multiple clients might share access to signed assertions but not necessarily their associated keys.
The operational impact of this vulnerability is severe, particularly for organizations relying on Keycloak for enterprise single sign-on solutions. An attacker who successfully intercepts a victim's valid SAML assertion can reuse it to gain unauthorized access to protected resources without needing the victim's private key or credentials. This replay attack vector allows impersonation of legitimate users across any application that trusts the same identity provider and accepts such assertions. Since many enterprise applications do not implement additional session binding checks beyond the initial authentication, this flaw enables persistent unauthorized access until the assertion expires or is revoked by the identity provider. The risk is amplified in high-value environments where sensitive data protection and strict access controls are mandatory compliance requirements.
This vulnerability aligns with CWE-287 Improper Authentication because it involves a failure to correctly verify credentials or proof of possession during an authentication process. It also maps directly to MITRE ATT&CK technique T1550, specifically the subtechnique for Use Alternate Authentication Credentials such as SAML tokens, where attackers leverage stolen or intercepted valid assertions to bypass traditional login mechanisms. The lack of binding between the assertion and a specific client instance violates fundamental principles of secure token exchange defined in industry standards like OASIS SAML V2.0 specifications which emphasize robust proof-of-possession requirements for sensitive operations.
Mitigation strategies should focus on immediate patching if an update is available, as this type of logic error typically requires code-level fixes to enforce proper cryptographic validation. Organizations must ensure that their Keycloak deployments are updated to the latest stable version containing patches for SAML broker security issues. In environments where upgrading is not immediately feasible, network segmentation and strict monitoring of authentication logs can help detect anomalous replay patterns. Additionally, implementing additional layers of verification such as multi-factor authentication at critical application boundaries or enforcing stricter session binding policies in dependent service providers can reduce the attack surface. Long-term remediation should involve reviewing all SAML configurations to ensure that holder-of-key profiles are correctly implemented and validated according to current security best practices for federated identity management.