Bug 2509764 (CVE-2026-18573)

Summary: CVE-2026-18573 keycloak-services: keycloak-services: Client access-type policy condition bypass during client update
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: anujha, aschwart, asoldano, aszczucz, bbaranow, bmaxwell, boliveir, bstansbe, dlofthou, drichtar, istudens, ivassile, iweiss, mosmerov, mposolda, msvehla, nwallace, pberan, pesilva, pjindal, pmackay, rmartinc, rstancel, ssilvert, sthorger, thjenkin, vdosoudi, 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 keycloak-services component of Keycloak, which is used for managing authentication and authorization flows. The issue occurs when a realm administrator configures client policies to enforce specific authentication requirements on confidential clients. Due to improper evaluation of the client state during an update operation, an attacker with client management permissions can bypass these security policies by first creating a public client and then updating it to a confidential client with weaker authentication. This can result in the persistence of clients that do not comply with the intended security hardening of the realm.
 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-07-31 12:37:18 UTC 
A state-based policy bypass vulnerability was discovered in Keycloak's client policy engine. The flaw exists in the way the access-type condition evaluates UPDATE operations. Specifically, the condition checks the old client state instead of the proposed new state during an update. An attacker with low privileges, such as delegated client management permissions or a valid dynamic registration token, can exploit this by creating a public client and subsequently updating it to a confidential client. Because the policy engine still perceives the client as public during the update process, it fails to trigger the confidential-client policy profile. This allows the attacker to configure a confidential client with weak authentication (e.g., client-secret) even when the realm policy mandates stronger methods like client-jwt. Successful exploitation allows an attacker to persist non-compliant confidential clients, undermining realm-level security hardening.