SAML signature bypass enables federated account takeover in Red Hat Build of Keycloak

A flaw was found in the SAML HTTP-Redirect binding implementation of Keycloak. The issue occurs because the server processes percent-encoded parameter names (like %53AMLResponse) while the signature verification logic only checks literal parameter names. An attacker can use this discrepancy to provide a crafted, unsigned SAML message that the server processes instead of a legitimately signed one, leading to full account takeover of federated users.

• Red Hat Build of Keycloak, component keycloak-services: Affected; no fixed release or erratum is identified.
• Red Hat Build of Keycloak, component rhbk/keycloak-rhel9: Affected; no fixed release or erratum is identified.
• Red Hat Single Sign-On 7, component keycloak-services: Known not affected because vulnerable code is not present.
• Red Hat states that, unless explicitly marked not affected, previous package versions in any minor update stream of a listed product should be assumed vulnerable, although they may not have received full analysis. The current evidence provides no specific version boundary for the two affected components.

The flaw is in the keycloak-services component's handling of the SAML HTTP-Redirect binding. The server decodes percent-encoded parameter names, such as %53AMLResponse becoming SAMLResponse, while signature verification recognizes only literal parameter names. The technical description states that a request can place a crafted unsigned SAML message under an encoded name before a legitimately signed message; verification checks the legitimate message, but processing selects the first occurrence after decoding. This discrepancy allows the unsigned message to be processed as if it were valid and corresponds to CWE-347, Improper Verification of Cryptographic Signature. The available evidence does not establish other implementation details, additional configuration dependencies, or specific version boundaries beyond the products identified.

The flaw is reachable over the network and does not require prior privileges or user interaction; the supplied record describes low attack complexity. Red Hat Bugzilla identifies an additional condition: the attacker needs an account at the external Identity Provider to capture a validly signed redirect-binding message, such as a logout response, and use it in the bypass. An unauthenticated remote attacker can then impersonate a federated user in the SAML assertion and take over that account. The available evidence does not establish active exploitation or a public exploit.

The flaw allows an unsigned SAML message to bypass the intended signature-validation boundary and be processed as a valid message. The documented technical outcome is remote impersonation of a federated user, followed by access to the victim's roles and data through connected services. Possible consequences include loss of data confidentiality and unauthorized modification of application data or state within the victim account's authority. The documented additional condition is that the attacker needs an account at the external Identity Provider to obtain a validly signed redirect-binding message; the evidence does not establish impact to the operating-system account or the entire server.

Successful exploitation can let an attacker log in as any federated user and access that user's roles and data without authorization. This can undermine trust in federated identity and enable unauthorized access to applications that rely on Keycloak. Depending on the impersonated account's roles, the attacker could read or modify data within that account's authority. The available evidence focuses on account takeover, data access, and application-state changes; it does not establish broader impact to the server or infrastructure.

1. Inventory and prioritize every Red Hat Build of Keycloak deployment containing keycloak-services or rhbk/keycloak-rhel9, especially deployments that enable the SAML HTTP-Redirect binding.
2. Monitor Red Hat Product Security for an erratum or fixed build and apply it promptly when published. The current evidence does not identify a fixed release or an issued patch.
3. Do not rely on an unconfirmed workaround. Red Hat states that mitigation is unavailable, or that currently available options do not meet its criteria for ease of deployment, applicability, and stability.
4. Until a fix is available, reduce exposure of affected federation endpoints where the deployment policy permits and increase review of federated login activity. If abuse is identified, follow the organization's account-response process, revoke affected sessions, and protect impacted accounts according to internal policy.

• Inventory Red Hat Build of Keycloak deployments and determine whether they contain keycloak-services or rhbk/keycloak-rhel9.
• Identify endpoints using the SAML HTTP-Redirect binding and compare product status with Red Hat Product Security rather than relying only on the package string reported by a scanner.
• If request logging is available, review SAML Redirect requests for percent-encoded parameter names or multiple parameters that decode to the same logical name. This is a mechanism-based detection heuristic, not a vendor-published IOC.
• As a precaution, review authentication telemetry for unusual successful federated logins, account activity, or privilege changes following SAML flows. The absence of matching log evidence does not establish that a system is safe.