EUVD-2026-51927
GHSA-wm3j-jpqg-fwv2
Severity by source
AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
Network-accessible admin API requires manage-clients role (PR:L); two-step manipulation is mechanically straightforward (AC:L); impact is integrity-only with no data disclosure or service disruption.
Primary rating from Vendor (redhat).
CVSS VectorVendor: redhat
Lifecycle Timeline
2DescriptionCVE.org
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.
AnalysisAI
Client policy enforcement in Red Hat Build of Keycloak can be bypassed by an authenticated user holding client management permissions, allowing non-compliant OAuth clients to persist in a realm despite administrator-configured security hardening. The bypass exploits improper client state evaluation during update operations: an attacker creates a public client - which passes policy validation - and then updates it to a confidential client type, skipping the re-evaluation that would normally reject a non-compliant confidential client. No public exploit code has been identified and this CVE is not listed in CISA KEV; however, the low attack complexity and broad deployment of Keycloak in enterprise IAM infrastructure elevate its practical significance.
Technical ContextAI
Keycloak is a widely-adopted open-source Identity and Access Management platform, and the affected component is keycloak-services, which governs client lifecycle operations including policy enforcement. Keycloak distinguishes between public OAuth clients (no client credential required) and confidential clients (must authenticate via client secret or certificate). Realm administrators can define client policies to enforce authentication standards specifically on confidential clients. The root cause maps to CWE-862 (Missing Authorization): during a client update operation that transitions a client from public to confidential, the authorization check against active client policies is not re-executed, creating a gap between creation-time and update-time enforcement. Affected CPEs per NVD include cpe:2.3:a:red_hat:red_hat_build_of_keycloak:*:*:*:*:*:*:*:*, cpe:2.3:a:red_hat:red_hat_single_sign-on_7:*:*:*:*:*:*:*:*, cpe:2.3:a:red_hat:red_hat_data_grid_8:*:*:*:*:*:*:*:*, and cpe:2.3:a:red_hat:red_hat_jboss_enterprise_application_platform_expansion_pack:*:*:*:*:*:*:*:*.
RemediationAI
Consult the Red Hat security advisory at https://access.redhat.com/security/cve/CVE-2026-18573 for patch availability; no specific fixed version was identified in the available intelligence data, so the exact remediated release must be confirmed directly with Red Hat. As an immediate compensating control, audit and restrict assignment of the manage-clients role (and any delegated realm admin privileges that include client management) to a minimal set of trusted users - this directly reduces the population of principals capable of executing the bypass. Conduct an audit of existing confidential clients across all realms to identify those originally registered as public clients and subsequently updated, verifying their compliance with active client policies. Enable and retain audit logs for client creation and update API events to detect future policy evasion attempts. Note that tightening manage-clients role assignments may disrupt self-service developer workflows where application teams register their own OAuth clients.
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
Same weakness CWE-862 – Missing Authorization
View allSame technique Authentication Bypass
View allVendor StatusVendor
Debian
Bug #1088287| Release | Status | Fixed Version | Urgency |
|---|---|---|---|
| open | - | - |
Share
External POC / Exploit Code
Leaving vuln.today