EUVD-2026-30879
GHSA-c739-f6xw-6pv2
Severity by source
AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N
Primary rating from NVD.
CVSS VectorNVD
Lifecycle Timeline
1Blast Radius
ecosystem impact- 61 maven packages depend on org.keycloak:keycloak-services (28 direct, 33 indirect)
Ecosystem-wide dependent count for version 26.6.2.
DescriptionCVE.org
A flaw was found in Keycloak. An authenticated client could exploit an Insecure Direct Object Reference (IDOR) vulnerability in the Authorization Services Protection API endpoint. By knowing or obtaining a resource's unique identifier (UUID) belonging to another Resource Server within the same realm, the client could bypass authorization checks. This allows the client to perform unauthorized GET, PUT, and DELETE operations on resources, leading to information disclosure and potential unauthorized modification or deletion of data.
AnalysisAI
Keycloak's Authorization Services Protection API is vulnerable to an Insecure Direct Object Reference (IDOR) flaw that allows authenticated low-privileged clients to perform unauthorized GET, PUT, and DELETE operations on resources owned by a different Resource Server within the same realm. By supplying a resource UUID belonging to a peer Resource Server - which a client can obtain through enumeration or disclosure - the attacker bypasses Keycloak's authorization enforcement entirely. The CVSS score of 6.8 (High) reflects confirmed confidentiality and integrity impact, though High complexity (AC:H) indicates the attacker must first acquire valid cross-server UUIDs. No public exploit code and no CISA KEV listing have been identified at time of analysis.
Technical ContextAI
Keycloak's Authorization Services expose a UMA (User-Managed Access) 2.0 Protection API that allows Resource Servers to register and manage protected resources programmatically. CWE-639 (Authorization Through User-Controlled Key) describes the root cause: the API accepts a resource UUID as a user-controlled identifier and performs operations on the identified object without verifying that the requesting client's Resource Server is the legitimate owner of that UUID. Since UUIDs are scoped at the realm level rather than the Resource Server level, a client registered under Resource Server A can supply a UUID belonging to Resource Server B and receive a valid API response. The affected product is identified by CPE cpe:2.3:a:red_hat:red_hat_build_of_keycloak:*:*:*:*:*:*:*:*, indicating the wildcard version range covers Red Hat's enterprise distribution of Keycloak across all versions reported to NVD. The CVSS vector AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N confirms network reachability, low privilege (authenticated client), no scope change, and no availability impact - consistent with a data access and tampering scenario rather than service disruption.
RemediationAI
The primary remediation is to apply the patch released by Red Hat for the Red Hat Build of Keycloak, referenced in the security advisory at https://access.redhat.com/security/cve/CVE-2026-4630. An exact fixed version number is not confirmed in the currently available intelligence - consult the advisory and https://bugzilla.redhat.com/show_bug.cgi?id=2450245 directly for the patched release version before upgrading. As a compensating control pending patching, administrators should audit realm architecture: if multiple Resource Servers share a realm and Authorization Services are enabled, consider network-layer or API gateway controls that restrict Protection API calls so each Resource Server's service account can only invoke the endpoint for its own registered resources. Disabling Authorization Services entirely on Resource Servers that do not require UMA-based resource management removes the vulnerable code path but may break fine-grained authorization workflows. Restricting the Protection API endpoint (typically /realms/{realm}/authz/protection/resource_set) at the reverse-proxy or firewall level to known client IP ranges reduces external exposure but does not prevent exploitation by compromised internal 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
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
Open redirect in Red Hat build of Keycloak permits remote attackers to send victims to attacker-controlled hosts by abus
Same technique Authentication Bypass
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today