CVE-2025-14777: Keycloak Authorization Bypass Vulnerability

CVE-2025-14777 Overview

CVE-2025-14777 is an Insecure Direct Object Reference (IDOR) vulnerability in Keycloak's admin API endpoints for authorization resource management. The flaw affects ResourceSetService and PermissionTicketService, which validate authorization against the resourceServer (client) ID supplied in the API request. However, the backend database operations (findById, delete) only use the resourceId, creating an authorization mismatch. An authenticated attacker holding fine-grained admin permissions on one client within a realm can read, modify, or delete authorization resources belonging to any other client in the same realm by supplying a valid resourceId. The issue is tracked under [CWE-289] Authentication Bypass by Alternate Name.

Critical Impact
Cross-client tampering of authorization resources within a Keycloak realm, breaking client isolation for fine-grained admins.

Affected Products

Red Hat build of Keycloak (see Red Hat CVE Analysis CVE-2025-14777)
Red Hat Single Sign-On / Keycloak server components exposing the admin authorization API
Deployments where multiple clients coexist in a realm with delegated fine-grained admin permissions

Discovery Timeline

2025-12-16 - CVE-2025-14777 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-14777

Vulnerability Analysis

Keycloak exposes admin API endpoints that manage authorization artifacts such as resource sets and permission tickets. Requests to these endpoints reference two identifiers: the resourceServer (client) ID and the target resourceId. The authorization check consumes the resourceServer value from the request to decide whether the caller has the required fine-grained admin scope. The subsequent database operation ignores that context and acts solely on resourceId.

The result is broken access control between clients within the same realm. A user granted manage-authorization or equivalent scoped rights over Client A can craft requests that reference Client A as the resourceServer while operating on a resourceId owned by Client B. The permission check passes, and the underlying findById or delete executes against Client B's resource. This undermines the client-level tenancy boundary Keycloak enforces for delegated administration.

Root Cause

The root cause is a mismatch between the authorization decision input and the data-access input. ResourceSetService and PermissionTicketService bind authorization to the client identifier from the request while performing state changes keyed exclusively on the resource identifier. Neither service validates that the target resourceId belongs to the resourceServer used for the access check.

Attack Vector

Exploitation requires an authenticated account with fine-grained admin permissions on at least one client in the realm. The attacker issues an authenticated HTTP request to the admin authorization endpoints, referencing their controlled client as the resourceServer while passing a resourceId enumerated or known from another client. The server authorizes the request against the attacker's client and then executes the modification or deletion against the victim client's record. No user interaction is required. Refer to Red Hat Bug Report #2422596 for backend behavior details.

Detection Methods for CVE-2025-14777

Indicators of Compromise

Admin API calls to /admin/realms/{realm}/clients/{client-id}/authz/resource-server/resource/{resourceId} where the resourceId does not belong to the {client-id} referenced in the path.
Unexpected DELETE or PUT operations against authorization resources or permission tickets originating from fine-grained admins who do not manage the affected client.
Audit log entries showing resource or permission-ticket removals with no corresponding change request from the owning client's administrators.

Detection Strategies

Correlate Keycloak admin event logs (RESOURCE_DELETE, RESOURCE_UPDATE, PERMISSION_TICKET_*) with the authenticated principal's assigned client scopes and flag cross-client actions.
Enable full admin event logging including representations and diff resource ownership before and after each authorization API call.
Baseline normal fine-grained admin behavior per client, then alert when a principal touches resourceId values outside their delegated client.

Monitoring Recommendations

Forward Keycloak admin and user events to a central log platform for retention and correlation.
Alert on 2xx responses to authorization admin endpoints where the acting user lacks realm-admin rights and the target resource crosses client boundaries.
Review fine-grained admin role assignments regularly to reduce the population of accounts capable of triggering the flaw.

How to Mitigate CVE-2025-14777

Immediate Actions Required

Apply the vendor patches referenced in RHSA-2026:6477 and RHSA-2026:6478 to affected Keycloak deployments.
Inventory all accounts holding fine-grained admin permissions on any client and revoke those not strictly required.
Audit recent admin events for cross-client authorization resource changes and restore any resources deleted or modified without authorization.

Patch Information

Red Hat has issued fixes through RHSA-2026:6477 and RHSA-2026:6478. The patched code aligns the authorization check with the backend lookup so that both operate on the same resource-server context. Consult the Red Hat CVE Analysis CVE-2025-14777 page for the full list of fixed builds and container images.

Workarounds

Restrict fine-grained admin roles (manage-authorization, view-authorization) to trusted realm administrators until patches are deployed.
Separate untrusted or multi-tenant clients into distinct realms so that a compromised fine-grained admin cannot reach unrelated clients.
Place the Keycloak admin API behind a reverse proxy or network allowlist that restricts access to a controlled administrative network.

bash

# Example: restrict fine-grained admin roles via kcadm.sh
kcadm.sh get users -r myrealm -q briefRepresentation=true \
  --fields id,username
kcadm.sh remove-roles -r myrealm --uusername suspect-admin \
  --cclientid myclient --rolename manage-authorization