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
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:N
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 allAuthorization bypass in the Keycloak Policy Enforcer allows any authenticated user to circumvent all enforced access con
Signature-verification bypass in Keycloak (and Red Hat's Keycloak-based products such as Red Hat Single Sign-On 7 and Re
Open redirect in Red Hat build of Keycloak permits remote attackers to send victims to attacker-controlled hosts by abus
Identity linking bypass in Red Hat build of Keycloak allows an attacker controlling a second account on the same upstrea
Authenticated users with uma_protection role in Red Hat Keycloak can bypass User-Managed Access policy validation to gai
Privilege escalation in Keycloak (Red Hat Build of Keycloak) lets an authenticated delegated admin with management right
Denial of service in Red Hat build of Keycloak allows remote unauthenticated attackers to exhaust CPU and worker threads
Denial of Service in Red Hat Build of Keycloak allows unauthenticated remote attackers to exhaust server resources by su
Session fixation in Keycloak's login-actions endpoints allows remote attackers to hijack authenticated sessions and take
Authorization code forgery in Red Hat Keycloak enables unauthenticated attackers to escalate privileges to admin-level a
Stored Cross-Site Scripting in Red Hat Build of Keycloak lets an authenticated administrator with `manage-client` permis
Open redirect in Red Hat Build of Keycloak allows authenticated attackers with control over another path on the same web
Same technique Information Disclosure
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today