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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.4",
  "pubDate": "2026-11-05T18:17:11.053Z",
  "pubdate": "2026-11-05T18:17:11.053Z",
  "executiveSummary": "A critical security vulnerability exists within the SAML adapter component of Keycloak, involving an improper verification of the assertion issuer.\nThe vulnerability occurs because the adapter fails to enforce a match between the issuer of a signed SAML assertion and the identity provider (IdP) configured for the specific application.\nThis flaw allows an attacker who controls a malicious identity provider to masquerade as any user, provided the malicious provider shares a trusted signing key with a legitimate one.\nSuccessful exploitation enables unauthorized authentication and potential privilege escalation, leading to full administrative control over the target application.\nThis is a logic-based authentication bypass vulnerability that exposes identity management systems to cross-provider impersonation attacks.\nThe risk is categorized as high, as it fundamentally compromises the trust relationship between the Service Provider (SP) and the Identity Provider (IdP) within the SAML ecosystem.\nNo specific user interaction is required for the exploit, as the attack leverages the trust established in the shared cryptographic material.",
  "technicalDetails": "The root cause of this vulnerability lies in the validation logic within the Keycloak SAML adapter. When processing a signed SAML assertion, the adapter verifies the cryptographic signature against a set of trusted keys. However, it fails to perform a secondary, mandatory validation check: ensuring the 'Issuer' element within the SAML assertion exactly matches the entity ID of the configured identity provider for the application instance.\nIn environments where multiple identity providers share a common trusted signing key, the adapter treats any assertion signed by that key as valid, regardless of which IdP actually issued the assertion. This behavior allows an attacker operating a rogue IdP (or an IdP they have compromised) that is registered as a trusted entity by the service provider to forge assertions.\nThe attack flow proceeds as follows: First, the attacker identifies that the Keycloak SAML adapter is relying solely on the validity of the signature and not the issuer identity. Second, the attacker crafts a malicious SAML assertion containing an arbitrary NameID or user attribute, claiming the identity of a privileged user (e.g., an administrator). Third, the attacker signs this assertion using the shared signing key. Fourth, the attacker presents this assertion to the target application. Finally, the Keycloak SAML adapter validates the signature successfully, fails to perform the issuer-to-provider binding check, and grants the attacker an active session with the privileges of the targeted user.\nThe vulnerable component is the SAML adapter logic responsible for assertion processing and identity validation. This vulnerability exposes the application to unauthorized authentication attempts over the network where SAML endpoints are accessible. The post-exploitation impact is severe, as the attacker can manipulate the assertion payload to define the identity they wish to assume. By crafting assertions with administrative claims, the attacker can achieve full account takeover and administrative access to the Keycloak-protected application, effectively bypassing the intended security boundaries of the authentication flow. This vulnerability demonstrates the importance of strict validation of all fields within a signed XML assertion, not merely verifying the integrity of the signature itself."
}