CVE-2026-97174 in Keycloak
Summary
by MITRE • 11/05/2026
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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 11/05/2026
The vulnerability identified in Keycloak’s implementation of Client-Initiated Backchannel Authentication (CIBA) represents a critical authentication bypass mechanism rooted in improper input validation and object injection flaws. CIBA is an OpenID Connect extension designed for scenarios where the user device does not have direct network access to the authorization server, such as smart TVs or IoT devices, requiring interaction via a separate channel like a mobile phone. The core technical flaw lies within the handling of the sub parameter during the token issuance phase. Specifically, the CIBA endpoint fails to strictly validate and sanitize this identifier before processing it for storage in additional request parameters. This lack of rigorous validation allows an attacker to inject arbitrary values into the flow that are not properly scoped or isolated from the core authentication context.
During the operational execution of a backchannel login, the authorization server processes the client’s request to initiate authentication. In this specific instance, the system incorrectly treats the injected sub parameter as a legitimate additional request parameter rather than rejecting it due to its presence in an unauthorized location or format. As the token issuance process proceeds, the application logic erroneously prioritizes this injected value over the legitimately authenticated subject identifier derived from the actual user interaction on the secondary device. Consequently, the security tokens generated and returned to the client contain a sub claim that corresponds to the attacker’s specified victim rather than the individual who actually completed the authentication challenge. This discrepancy creates a severe identity confusion state within the session management layer of the application.
The operational impact of this vulnerability is profound, enabling unauthorized account access through token substitution. An attacker can authenticate as themselves on their own device but receive an ID token and access tokens that assert they are another user. When these forged tokens are presented to downstream resource servers or APIs protected by Keycloak, those services trust the sub claim embedded in the JWT without further verification of its origin against the current session context. This allows the attacker to impersonate any valid user within the system, gaining full administrative privileges if targeting an admin account or accessing sensitive personal data for regular users. The attack does not require compromising passwords or breaking cryptographic algorithms; it relies entirely on logic flaws in how identity assertions are constructed and validated during the backchannel flow.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the system failed to restrict unacceptable inputs within the CIBA endpoint parameters. It also maps closely to CWE-613 Insufficient Session Expiration, in terms of how session identity is maintained incorrectly across token issuance boundaries, and more critically to CWE-862 Missing Authorization Check regarding the validation of subject ownership during token generation. In the context of the MITRE ATT&CK framework for enterprise security, this behavior facilitates Account Manipulation techniques where an adversary gains access by exploiting trust relationships between components rather than breaking them directly. It also touches upon Identity-Based Attack vectors specific to OAuth 2.0 and OpenID Connect implementations.
Mitigation strategies must focus on strict parameter validation and separation of concerns within the authentication flow. Developers should ensure that parameters intended for internal processing are not exposed or modifiable by client-side inputs unless explicitly defined in the specification with appropriate scope restrictions. Implementing allowlists for accepted request parameters can prevent injection attacks where unexpected fields alter core identity logic. Additionally, enforcing strict binding between the authenticated user’s session and the issued tokens is essential; this includes verifying that the sub claim in the token matches the actual authenticating principal rather than accepting any value provided by the client application. Regular security audits of OpenID Connect implementations against current best practices are recommended to identify similar logical flaws before they can be exploited in production environments.