Description

A flaw was found in the Client-Initiated Backchannel Authentication (CIBA) implementation of Keycloak. The CIBA endpoint fails to properly validate the sub parameter, allowing it to be stored as an additional request parameter. During the token issuance process, this injected value overwrites the legitimate subject identifier. This allows an attacker to authenticate as themselves but receive security tokens belonging to a different victim user, leading to unauthorized account access.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.8",
  "pubDate": "2026-11-05T18:17:11.493Z",
  "pubdate": "2026-11-05T18:17:11.493Z",
  "executiveSummary": "A critical improper input validation vulnerability exists within the Client-Initiated Backchannel Authentication (CIBA) implementation of Keycloak.\nThe flaw stems from the improper handling of the 'sub' parameter during the CIBA request phase, enabling an attacker to perform parameter injection.\nBy manipulating the 'sub' parameter, an attacker can influence the token issuance process, resulting in the unauthorized generation of security tokens associated with an arbitrary victim user.\nThis vulnerability leads to complete account takeover, as the system erroneously maps the authenticated session to the identity injected via the 'sub' parameter rather than the legitimate authentication context.\nThe risk is severe, as it bypasses standard authorization controls and enables unauthorized access to sensitive victim resources.\nExploitation requires the ability to interact with the CIBA endpoint, though it does not necessitate administrative privileges or prior access to the victim's credentials.\nSuccessful exploitation results in full authentication bypass and identity impersonation within the affected Keycloak environment.",
  "technicalDetails": "The vulnerability resides in the CIBA endpoint of Keycloak, specifically within the logic responsible for parsing and persisting request parameters initiated via backchannel communication.\nThe root cause is a failure to strictly validate and sanitize the 'sub' (subject) parameter during the initial authentication request sequence. In the OIDC CIBA flow, the 'sub' parameter is intended to identify the user requested for authentication; however, the implementation incorrectly permits this parameter to be processed and stored as an arbitrary request parameter.\nDuring the token issuance phase, the CIBA flow retrieves stored request parameters to finalize the token generation process. Due to the lack of input validation, the application retrieves the injected 'sub' value provided by the attacker and improperly uses it to override the internal subject identifier derived from the legitimate authentication flow.\nThe attack flow proceeds as follows: First, the attacker initiates a CIBA request to the Keycloak endpoint, including a malformed or malicious 'sub' parameter representing the target victim's unique user identifier. Second, Keycloak registers this request and stores the injected 'sub' value alongside the session state. Third, the attacker proceeds with the standard authentication flow as their own identity. Fourth, upon the client's subsequent request to the token endpoint to exchange the authentication result for security tokens, Keycloak resolves the session. During this resolution, the backend service incorrectly overwrites the legitimate authenticated subject ID with the stored malicious 'sub' parameter.\nAs a result, the OIDC provider issues identity and access tokens (ID tokens and Access tokens) that reflect the victim's identity rather than the attacker's. The token issuance logic fails to verify if the subject identifier requested in the initial CIBA call matches the subject identifier authenticated during the backchannel process.\nThis allows an attacker to gain fully authenticated access to a victim's account, provided the attacker knows or can guess the victim's user identifier. The vulnerability impacts the integrity of the CIBA authentication flow and invalidates the trust model of the token issuance component.\nThe issue persists until the application logic is updated to enforce strict schema validation on the CIBA request parameters and ensure that the 'sub' parameter is strictly immutable once the initial authentication state is established."
}