Brief Summary: Keycloak UMA Protection API Missing Authorization (CVE-2026-114232) Enables Cross-Owner Resource Access

Introduction

A missing authorization check in Keycloak's UMA Protection API lets an authenticated realm user create a policy that reaches resources owned by other users in the same realm. For deployments that rely on User Managed Access to keep one user's protected resources separate from another's, CVE-2026-114232 weakens exactly the ownership boundary that the authorization model is designed to enforce.

Keycloak is an open-source identity and access management solution for applications and services, accepted by the Cloud Native Computing Foundation at the Incubating maturity level on April 10, 2023. Red Hat ships a commercial distribution, Red Hat Build of Keycloak, based on the community project, and it is this build that Red Hat lists as affected. CNCF's IFTM case study describes Keycloak providing unified single sign-on and Gov.br integration for more than 12,000 active users, an example of how central this kind of identity infrastructure can be (the case study does not indicate that IFTM uses the affected UMA functionality).

Red Hat assigns a preliminary CVSS v3.1 score of 8.1 (High) and an Important product severity rating. NVD has not supplied its own score and lists the record as Awaiting Enrichment. The issue was reported by 0xNayel of the YesWeHack Bug Bounty Program, and none of the reviewed primary records report exploitation in the wild.

Technical Information

Root cause: resource type and ownership are conflated

The weakness is classified as CWE-862, Missing Authorization: the software fails to perform an authorization check when an actor accesses a resource or performs an action. Authentication has already established who the attacker is. What is missing is the check on whether that identity may define a policy over the resources in question.

Keycloak's Authorization Services documentation describes two separate concepts that matter here:

Resource type: a grouping attribute that lets common permissions protect a set of resources.
Ownership: resources have owners and can be associated with individual users.

The flaw lives in UserManagedPermissionService, which backs the UMA Protection API used to manage user permissions. When a user creates a new policy, the resourceType field is not validated against the caller's ownership. An authenticated user who is able to create their own resources can therefore submit a policy that names a resource type belonging to someone else.

The second half of the problem appears at evaluation time. DefaultPolicyEvaluator matches the stored policy against resources of the specified type regardless of ownership. The result is a policy authored by one user that applies to resources owned by other users across the realm.

Attack flow

Based on the Red Hat Bugzilla report, exploitation proceeds as follows:

Prerequisites. The attacker is an authenticated user in the realm, owns at least one resource, and knows the victim's resourceType string.
Policy creation. The attacker submits a policy through the UMA Protection API containing a resourceType outside their ownership boundary. No validation rejects it.
Cross-owner matching. During policy evaluation, DefaultPolicyEvaluator matches the policy against every resource of that type, without regard to who owns them.
Token issuance. The attacker obtains a Requesting Party Token (RPT) that grants access to other users' resources, enabling sensitive information disclosure or unauthorized actions.

Keycloak defines an RPT as an access token containing permissions granted through policy evaluation. In this scenario, the authorization server itself issues a permission-bearing token for access the resource owner never authorized.

The normal Protection API controls do not cover this case. Access to the Protection API is ordinarily governed by a protection API token carrying the uma_protection scope, but the vulnerability is documented as exploitable by an authenticated user despite the intended ownership model, so that token requirement should not be read as a mitigating control.

Severity vector

The CNA (Red Hat) vector is:

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Attack vector, Network: remotely reachable.
Attack complexity, Low.
Privileges required, Low: this is not an unauthenticated attack.
User interaction, None: no victim action is needed.
Scope, Unchanged.
Confidentiality and Integrity, High: data access and modification drive the rating.
Availability, None.

These values are Red Hat's assessment, not an independent NVD analysis.

What the sources do and do not establish

The documented reach is resources whose type matches the attacker-supplied resourceType, across ownership boundaries, within the same realm. The sources do not establish compromise of every resource, access to other realms, or impact on the underlying host. The public bug report also does not include a complete exploit request, token claims, or an executable proof of concept.

On exploitation status, the Red Hat advisory, Bugzilla entry, and CNA record do not report observed attacks or name a threat actor. VulDB lists the entry as in review with KEV: no and very low activity, and a CISA Known Exploited Vulnerabilities listing is not confirmed by the available evidence. We treat this as an information gap rather than evidence that exploitation has not occurred.

The disclosure timeline from the CNA record and Bugzilla:

October 19, 2026: reported to Red Hat.
October 21, 2026: public Bugzilla entry created.
November 5, 2026: made public, with the CNA record published at 16:05:41 UTC and NVD publication in Awaiting Enrichment status.

Affected Systems and Versions

Red Hat's CNA record lists the following:

Red Hat Build of Keycloak, package keycloak-services: Affected, no version range supplied.
Red Hat Build of Keycloak, container rhbk/keycloak-rhel9: Affected, no version range supplied.
Red Hat Single Sign On 7, package keycloak-services: Unaffected, no package version supplied.

The record does not provide affected version bounds or a fixed release, and the public Bugzilla entry is marked NEW with the version listed as unspecified. The underlying service is part of Keycloak, but the record does not enumerate community versions or other downstream distributions, so a reliable version-based exposure rule cannot be built from the available data. Any deployment that uses Keycloak Authorization Services with UMA, where users can create their own resources and policies through the Protection API, matches the vulnerable configuration described in the advisory.

Red Hat also states that mitigation is either unavailable or that available options do not meet its Product Security criteria for ease of deployment, applicability across the installation base, or stability. The advisory therefore supplies no qualifying workaround. Keycloak's general security policy recommends tracking the latest release and points to Red Hat Build of Keycloak for long-term support, but that is general maintenance guidance and not confirmation that any particular release resolves this CVE. The commercial build is itself listed as affected.

Vendor Security History

A closely related UMA ownership flaw. CVE-2025-14778 also affected UserManagedPermissionService. When a policy associated with multiple resources was updated or deleted, the ownership check ran only against the first resource, allowing changes that affected other owners. The mechanism differs from CVE-2026-114232, which concerns missing resourceType validation at policy creation and subsequent cross-owner matching. Remediation published for the earlier CVE should not be treated as a fix for this one, but the pair does show the UMA ownership boundary has been a recurring source of authorization defects.

Independent audit history. REWE Digital funded a Cure53 assessment of Keycloak 8.0 in November 2019, combining source-assisted penetration testing with a broader security review over 21 days. It produced 10 security-relevant findings, five vulnerabilities and five general weaknesses, including one High-severity stored cross-site scripting issue. Cure53's conclusion was broadly positive while explicitly noting incomplete feature and source coverage. Those results describe a historical version and do not speak to the current issue.

Response process. Keycloak's published security charter and policy describe a permanent resolution team, prioritization of security fixes above other backlog items, and acknowledgement of reports within seven business days. Depending on severity, fixes may land in the current major.minor release, with lower-severity issues addressed in the following release. These are process commitments, not a stated remediation deadline for CVE-2026-114232.

CVE Analysis

Experimental AI-Generated Content

Introduction

Technical Information