Bug 2523347 (CVE-2026-79652)

Summary: CVE-2026-79652 keycloak-services: keycloak-services: JWT Bearer authorization grant does not enforce consentRequired
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security <prodsec-ir-bot>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: aschwart, aszczucz, boliveir, drichtar, mposolda, pjindal, rmartinc, ssilvert, sthorger, vmuzikar
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
A flaw was found in the JWT Bearer authorization grant implementation within the keycloak-services component of Red Hat Build of Keycloak. This component handles various OAuth2 and OpenID Connect grant types used for issuing access tokens. The issue occurs because the JWT Bearer grant fails to check if a client requires user consent before issuing a token. This allows an authenticated attacker with valid client credentials and a trusted identity provider assertion to bypass the consent requirement and obtain unauthorized access to a user account at a consent-gated client.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description OSIDB Bzimport 2026-08-25 10:44:04 UTC 
A Missing Authorization flaw (CWE-862) was identified in the JWT Bearer authorization grant (urn:ietf:params:oauth:grant-type:jwt-bearer) in Keycloak. The vulnerability exists in the JWTAuthorizationGrantType.process function, which fails to verify the client.isConsentRequired flag or check for a stored UserConsentModel before issuing an access token.
While other user-facing grants like Resource Owner Password Credentials (ROPC) explicitly refuse consent-required clients, and interactive grants verify stored consent, the JWT Bearer grant bypasses these checks entirely. To exploit this flaw, an attacker must have access to a confidential client credentials and a valid JWT assertion for a target user signed by an allow-listed Identity Provider (IdP).
Successful exploitation allows an attacker to:
Obtain a valid access token for a target user without their consent.

Access protected resources and APIs on behalf of the user.

Bypass administrative security policies intended to gate client access behind explicit user approval.