CVE-2025-14777
MEDIUMCVSS Vector
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:L
Lifecycle Timeline
3Description
A flaw was found in Keycloak. An IDOR (Broken Access Control) vulnerability exists in the admin API endpoints for authorization resource management, specifically in ResourceSetService and PermissionTicketService. The system checks authorization against the resourceServer (client) ID provided in the API request, but the backend database lookup and modification operations (findById, delete) only use the resourceId. This mismatch allows an authenticated attacker with fine-grained admin permissions for one client (e.g., Client A) to delete or update resources belonging to another client (Client B) within the same realm by supplying a valid resource ID.
Analysis
Keycloak's admin API endpoints for authorization resource management contain an IDOR vulnerability allowing authenticated administrators with fine-grained permissions for one client to delete or modify resources belonging to other clients within the same realm. The flaw exists in ResourceSetService and PermissionTicketService where authorization checks validate the resourceServer (client) ID from the API request, but backend database operations use only the resourceId, creating a permission bypass. Affected administrators can exploit this with standard HTTP requests to cross-client resource boundaries; no public exploit code identified at time of analysis.
Technical Context
Keycloak is an open-source Identity and Access Management (IAM) platform built on Java that provides OAuth 2.0 and OpenID Connect support. The vulnerability resides in the authorization resource management layer, specifically within ResourceSetService and PermissionTicketService classes that handle fine-grained authorization policies in the admin REST API. The root cause is a logic mismatch: authorization checks (likely using an isAuthorizedForClient or similar method) validate that the authenticated user has admin permissions for the resourceServer (client) ID extracted from the API request parameters, but subsequent database lookup and modification operations (findById, delete, update) ignore the resourceServer constraint and operate solely on the resourceId. This disconnect allows an attacker with admin:manage permission for Client A to supply a valid resourceId belonging to Client B, bypass the resourceServer scope check, and directly manipulate Client B's authorization resources. The underlying issue is classified as CWE-289 (Improper Access Control Based on User Attributes), though the traditional label for such flaws is Broken Access Control (CWE-639 or OWASP A01:2021).
Affected Products
Keycloak is affected by this vulnerability across multiple versions maintained by Red Hat. Specific version ranges are not explicitly detailed in the provided references, but Red Hat has issued security advisories RHSA-2026:6477 and RHSA-2026:6478, indicating fixes are available across multiple Keycloak releases. Organizations should consult the Red Hat Security Advisory at https://access.redhat.com/errata/RHSA-2026:6477 and https://access.redhat.com/errata/RHSA-2026:6478, as well as the CVE details page at https://access.redhat.com/security/cve/CVE-2025-14777 and Bugzilla tracking issue https://bugzilla.redhat.com/show_bug.cgi?id=2422596 for the precise affected version ranges and patched versions applicable to their deployment.
Remediation
Apply the security updates released by Red Hat in advisories RHSA-2026:6477 and RHSA-2026:6478, which contain fixes for this IDOR vulnerability in Keycloak's ResourceSetService and PermissionTicketService. Determine the patched version applicable to your Keycloak release series by consulting the Red Hat errata pages and Bugzilla issue 2422596. Additionally, as an interim control before patching, implement administrative segregation by restricting fine-grained admin permissions so that individual administrators have authority over only their assigned client and cannot cross-client boundaries even if the backend validation is bypassed; however, this is a compensating control and not a substitute for applying the vendor patch. Organizations should prioritize patching in development and staging environments first to validate compatibility before production deployment.
Priority Score
Vendor Status
Share
External POC / Exploit Code
Leaving vuln.today