CVE-2026-96446: Keycloak-services: keycloak-services: par single-use bypass via prompt=none silent authentication path
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.
Other sources
A flaw was found in the Pushed Authorization Request PAR implementation of Keycloak. The issue occurs when the silent authentication path prompt=none is used, which allows the authorization process to skip certain steps if a user is already logged in. Due to this bypass, the security rule that ensures a pushed request URI is used only once is not enforced. An attacker could potentially reuse a request URI to obtain multiple authorization codes for a user who is already signed in, violating security standards like FAPI-2.
— MITRE
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
A realm is exposed only if Pushed Authorization Requests (PAR) are enabled. Exploitation additionally depends on an active SSO session for the target user and use of the silent authentication flow with prompt=none.
What does an attacker need to exploit the flaw?
The attacker needs valid client credentials that permit them to push an authorization request, plus an active SSO session for the target user. They can then replay the same request_uri through the authorization endpoint using prompt=none.
What is the practical impact of replaying a PAR request URI?
Each replay can mint a distinct, fully redeemable authorization code for the same user without requiring the user to authenticate again. This can lead to unauthorized token generation and breaks the PAR single-use guarantee.
How can teams identify likely exploitation conditions?
Review whether PAR is enabled in the realm, whether clients can submit PAR requests using valid client credentials, and whether authorization requests using prompt=none are processed while target users have active SSO sessions. The affected behavior is reuse of a previously successful PAR request_uri to obtain additional authorization codes.