CVE-2026-4630: Keycloak Auth Bypass Vulnerability

CVE-2026-4630 Overview

CVE-2026-4630 is an Insecure Direct Object Reference (IDOR) vulnerability in the Keycloak Authorization Services Protection API. An authenticated client can bypass authorization checks by referencing a resource's unique identifier (UUID) belonging to another Resource Server within the same realm. The flaw enables unauthorized GET, PUT, and DELETE operations against resources the client does not own. Successful exploitation results in information disclosure and potential unauthorized modification or deletion of data managed by other Resource Servers. The weakness is classified under CWE-639 (Authorization Bypass Through User-Controlled Key).

Critical Impact

Authenticated clients can read, modify, or delete protected resources owned by other Resource Servers in the same Keycloak realm, breaking tenant isolation in Authorization Services.

Affected Products

• Red Hat build of Keycloak (see Red Hat CVE Analysis CVE-2026-4630)
• Components patched in Red Hat Security Advisory RHSA-2026:19596
• Components patched in Red Hat Security Advisory RHSA-2026:19597

Discovery Timeline

• 2026-05-19 - CVE-2026-4630 published to NVD
• 2026-05-20 - Last updated in NVD database

Technical Details for CVE-2026-4630

Vulnerability Analysis

Keycloak's Authorization Services provides a Protection API that lets Resource Servers register, query, update, and remove protected resources. Each resource is identified by a UUID assigned at creation time. The vulnerable endpoints accept this UUID as the primary lookup key without verifying that the authenticated client owns the referenced resource.

Because the UUID is treated as a sufficient authorization token, any client holding a valid Protection API token within the realm can manipulate resources belonging to a different Resource Server. Attackers do not need to escalate privileges or break authentication. They only need a valid client credential and knowledge or enumeration of a target UUID.

The impact spans confidentiality and integrity. GET requests disclose resource definitions, scopes, and metadata. PUT requests rewrite resource attributes and policies. DELETE requests remove resources that downstream applications rely on for access control decisions.

Root Cause

The root cause is missing tenant-scope validation in the Protection API request handler. The endpoint resolves a resource by its UUID and proceeds to authorize the operation based on the caller's authentication state rather than the resource's ownership. This is a textbook IDOR pattern tracked under CWE-639.

Attack Vector

An attacker first authenticates to Keycloak as any registered client in the target realm. The attacker then issues HTTP requests to the Authorization Services Protection API, substituting the UUID of a resource owned by another Resource Server. The server returns or modifies the resource without enforcing ownership boundaries.

The attack is performed over the network and requires low privileges, but the CVSS vector indicates high attack complexity, reflecting the need to discover valid UUIDs and possess a Protection API token. Refer to the Red Hat Bug Report #2450245 for additional technical context.

Detection Methods for CVE-2026-4630

Indicators of Compromise

• Protection API requests where the authenticated client_id does not match the owner field of the resource returned or modified.
• Unexpected PUT or DELETE requests to /realms/{realm}/authz/protection/resource_set/{id} from clients that have not previously created or read that UUID.
• Bursts of GET requests against sequential or enumerated resource UUIDs from a single client.

Detection Strategies

• Enable Keycloak event logging for ADMIN and CLIENT event types and forward logs to a SIEM for correlation between client_id, resource UUID, and resource owner.
• Correlate authentication events with Protection API access patterns to identify cross-tenant resource access within a single realm.
• Build alerts that fire when a client accesses more distinct resource UUIDs than it has historically created.

Monitoring Recommendations

• Audit all Protection API endpoints under /authz/protection/resource_set for ownership mismatches between caller and resource.
• Track deletion events on Authorization Services resources and require approval workflows for high-value resource servers.
• Review existing Resource Server inventories regularly to confirm that no resources have been silently modified or removed.

How to Mitigate CVE-2026-4630

Immediate Actions Required

• Apply the Keycloak updates shipped in RHSA-2026:19596 and RHSA-2026:19597.
• Rotate Protection API client secrets for clients in realms that handle multi-tenant Authorization Services.
• Audit Authorization Services resources for unauthorized changes or deletions performed before patching.

Patch Information

Red Hat has released fixed packages through Red Hat Security Advisories RHSA-2026:19596 and RHSA-2026:19597. Consult the Red Hat CVE page for CVE-2026-4630 for the authoritative list of affected packages and fixed versions.

Workarounds

• Restrict which clients in each realm are granted the uma_protection role, limiting the set of accounts that can call the Protection API.
• Isolate sensitive Resource Servers into dedicated realms so that cross-tenant UUID references are not reachable.
• Place an authenticating reverse proxy in front of Keycloak to enforce per-client allowlists on Protection API paths until the patch is deployed.

# Example: limit Protection API access at a reverse proxy until patched
location ~ ^/realms/[^/]+/authz/protection/resource_set/ {
    if ($ssl_client_s_dn_cn !~ "^(trusted-rs-1|trusted-rs-2)$") {
        return 403;
    }
    proxy_pass http://keycloak_upstream;
}