REDHAT-BUG-2539284: Medium severity Red Hat Keycloak vulnerability
A flaw was found in Keycloaks Pushed Authorization Request PAR implementation. The single-use enforcement for PAR request URIs, as required by RFC 9126 section 4, is bypassed when using the silent authentication path prompt=none. When an existing SSO session is present, the authorization endpoint short-circuits directly to the successful-flow redirect handler. In this specific code path, the PAR consumption logic is never triggered, meaning the pushed request object is not removed from storage after use. Exploitation requires that the realm has PAR enabled, the attacker has valid client credentials to push an authorization request, and an active SSO session exists for the target user. A successful attacker can replay the requesturi multiple times to mint distinct, fully redeemable authorization codes for the same user without requiring the resource owner to re-authenticate. This allows for unauthorized token generation and violates the single-use guarantee required for FAPI-2 and RFC 9126 compliant deployments.
Affected Software
Event History
Frequently Asked Questions
What conditions are required to exploit this issue?
PAR must be enabled for the realm, and the attacker must have valid client credentials that allow them to push an authorization request. The target user must also have an active SSO session, and the request must use the silent authentication path with prompt=none.
Who is realistically exposed?
Deployments using Keycloak PAR in FAPI-2 or RFC 9126-compliant flows are exposed when clients with valid credentials can submit PAR requests and users have active SSO sessions. The issue enables replay against a target user without requiring that user to authenticate again.
What can an attacker obtain by replaying a request URI?
An attacker can replay the same request_uri multiple times to mint distinct authorization codes for the same user. Those authorization codes are fully redeemable, enabling unauthorized token generation.
How can I determine whether my deployment is affected?
Check whether PAR is enabled in the relevant realm and whether authorization requests can be processed with prompt=none while an SSO session exists. An affected flow allows the same PAR request_uri to produce more than one successful authorization response rather than consuming and removing it after first use.