EUVD-2026-112639
GHSA-3cf5-cf36-hfwx
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate to Keycloak as OAuth client/user
-
DeliverySubmit Pushed Authorization Request (PAR)
-
ExploitRestart authentication flow to reset consumption markers
-
ExecutionReplay same authorization request
-
ImpactObtain multiple access tokens
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Always-incorrect control flow
|
| Exploitation Conditions | Exploitation requires that the Keycloak/RH-SSO deployment actually uses OAuth 2.0 Pushed Authorization Requests (PAR) in the keycloak-services component; the flaw only manifests when an authentication flow is restarted, which incorrectly clears the internal PAR-consumption markers while leaving the request active. The attacker must hold enough privilege to initiate and restart an authentication flow as a client/user (CVSS PR:L = authenticated), so this is not exploitable by a fully unauthenticated outsider. Limiting factors: PAR must be in use (non-default for many deployments), valid credentials/client access are needed, and impact is confined to obtaining multiple access tokens from a request meant to be single-use (C:L/I:L, no availability impact). |
| Impact | This is a moderate-severity, authenticated logic flaw rather than a top-priority emergency. The input CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N, base 5.4) describes a network-reachable, low-complexity issue that requires privileges (PR:L), so an attacker must already be able to initiate and restart an OAuth authentication flow. The vendor priority label is 'this_month' (Red Hat), which signals a routine-patch cadence, not act_now/emergency urgency. No EPSS score, no CISA KEV listing, and no public exploit were provided, so there is no evidence of active or widespread exploitation; this aligns with the modest CVSS and the narrow, OAuth-specific nature of the bug. The real-world impact is the defeat of the single-use guarantee for Pushed Authorization Requests (PAR), letting one authorization request yield multiple access tokens - meaningful for environments relying on PAR for FAPI/high-assurance OAuth, but limited (C:L/I:L/A:N) and gated behind authentication. Net: genuine to fix on a normal patch cycle, but not a drop-everything issue. Key missing signals to note explicitly: EPSS, KEV, and PoC status are all absent from the input and cannot be assumed. |
| Exploit ScenarioDerived | An attacker who can act as an OAuth client/user (PR:L) submits a Pushed Authorization Request to a Keycloak instance that uses PAR, then deliberately restarts the authentication flow. Because the restart clears the internal PAR-consumption markers while leaving the request active, the attacker replays the same authorization request multiple times to mint multiple access tokens, defeating the single-use requirement. No public exploit was identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 29, 2026
Keycloak's keycloak-services PAR (Pushed Authorization Request) implementation can be induced to issue multiple access tokens from a single authorization request that is supposed to be single-use, by restarting the authentication flow so that internal PAR-consumption markers are cleared while the request stays active. Affected components are Red Hat Build of Keycloak and Red Hat Single Sign-On 7 deployments that actually have OAuth 2.0 PAR in use; the CVSS vector (PR:L) means the attacker must already be able to initiate and restart an authentication flow as a client or user, so this is not reachable by a fully unauthenticated outsider. Impact is limited to confidentiality and integrity of the token issuance path (C:L/I:L, no availability impact); there is no CISA KEV entry and no public exploit identified at time of analysis, and the priority label is 'this_month' rather than an emergency.
RemediationAI
No vendor-released patch version is identified in the supplied data; track the Red Hat advisory at https://access.redhat.com/security/cve/CVE-2026-117859 and the Bugzilla entry https://bugzilla.redhat.com/show_bug.cgi?id=2561991 for the fixed Red Hat Build of Keycloak and Red Hat Single Sign-On 7 builds, and apply those updates as soon as they are published. Because exploitation depends on the deployment using OAuth 2.0 PAR, environments whose clients do not require PAR can reduce exposure by not enabling the PAR endpoint - the trade-off is that any client currently relying on pushed authorization requests will break and must fall back to standard authorization requests. Environments that must keep PAR enabled should treat the issue as an authenticated logic flaw: restrict which clients and users can initiate and restart authentication flows, and monitor token issuance for repeated use of the same request_uri or duplicate access tokens from one pushed request, accepting that this is detection rather than a fix. There is no evidence in the supplied sources of a vendor-stated workaround, and no confirmed fixed version to cite.
Affects your stack
Find out whether the stacks and servers you run are on an affected version.
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
OAuth 2.0 Pushed Authorization Requests (PAR, RFC 9126) let a client push the authorization request parameters to a dedicated endpoint at the authorization server, which returns a request_uri that the client then uses at the authorization endpoint; the pushed request is intended to be consumed once and is tracked by internal markers in keycloak-services. The flaw is classified as CWE-670 (Always-Incorrect Control Flow Implementation): when an authentication flow is restarted, the code path that clears the PAR-consumption state runs but the underlying authorization request remains active, so the single-use invariant is broken and the same pushed request can be replayed to mint additional access tokens. This weakens the security properties that PAR is normally adopted for (integrity and one-time use of authorization parameters). The supplied CPE data maps the exposure to red_hat_build_of_keycloak and red_hat_single_sign-on_7 with unversioned wildcards; the specific affected and fixed build ranges are not enumerated in the available sources, and the exact code-level trigger beyond 'authentication flow restart' is not described in the available sources.
Know when Red Hat Build Of Keycloak gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
Network-facing OAuth endpoint (AV:N/AC:L), but the attacker must authenticate and drive an auth flow (PR:L); impact is limited token reuse, so C:L/I:L/A:N and scope unchanged.
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
DescriptionCVE.org
A flaw was found in the Pushed Authorization Request PAR implementation of the keycloak-services component. The issue occurs when an authentication flow is restarted, which incorrectly clears the internal markers used to track PAR consumption while leaving the request active. This allows an attacker to reuse the same authorization request to obtain multiple access tokens, bypassing security requirements for single-use requests.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Affected Products (CPE)CVE.org
More in Red Hat Build Of Keycloak
View allAccount takeover in Red Hat Build of Keycloak allows an unauthenticated attacker to abuse the reset-credentials flow in
Account takeover in Keycloak (Red Hat build of Keycloak, Red Hat Single Sign-On 7) arises because the IdP-initiated SAML
Authentication bypass in Red Hat Build of Keycloak (and Red Hat Single Sign-On 7) lets an unauthenticated attacker forge
Privilege escalation in Red Hat Build of Keycloak's Dynamic Client Registration (DCR) grants an attacker with low-privil
Mismatched handling of the HTTP/1 absolute-form request authority in Red Hat build of Quarkus and other affected Red Hat
Authorization bypass in the Keycloak Policy Enforcer allows any authenticated user to circumvent all enforced access con
URI normalization bypass in Keycloak's Authorization Services PathMatcher allows authenticated low-privilege users to re
Privilege escalation in Keycloak's Dynamic Client Registration (DCR) component allows attackers with standard user accou
Token exchange in Keycloak bypasses Google Workspace domain allowlist restrictions, enabling any valid Google account ho
Signature-verification bypass in Keycloak (and Red Hat's Keycloak-based products such as Red Hat Single Sign-On 7 and Re
Tenant-restriction bypass in Keycloak's Microsoft identity provider integration allows attackers holding any valid Micro
Session hijacking via SAML assertion replay in Keycloak's SAML broker component allows adjacent-network attackers to aut
Exploit-DB