Keycloak EUVD-2026-113442

Exploitation requires that 'remote resource management' is enabled on the Keycloak authorization services, and that the attacker is an authenticated user already holding specific resource-management permissions (PR:L) - it is not reachable by anonymous or unprivileged users. Given those prerequisites, the attacker simply supplies a target resource ID they do not own in the UMA resource-registration update request; the limiting factors are the required authentication, the required permissions, and the non-default enablement of remote resource management. No user interaction is needed (UI:N).

This is a moderate-severity authorization flaw (CWE-639, IDOR-style) rather than a high-urgency emergency. The Red Hat CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N = 4.3) tells a consistent story: network-reachable and low-complexity, but it requires an already-authenticated user holding specific permissions (PR:L), and the only impact is a limited integrity hit (I:L) - no confidentiality or availability loss. The vuln.today decision label is 'this_month', i.e. a planned-remediation priority, not act_now/emergency. No EPSS score was supplied, the CVE is not listed in CISA KEV, and no PoC or exploit reference is present in the input, so there is no signal of active or imminent exploitation. The signals do not conflict: a mid-range CVSS, a routine decision label, and the absence of exploitation evidence all point to a real-but-bounded issue whose impact is further gated by a non-default feature ('remote resource management' must be enabled). Note one metadata inconsistency to verify: the input carries an 'Authentication Bypass' tag, but the CWE-639 classification and the description describe an authorization (ownership) bypass affecting integrity only - this is not an authentication bypass.

An authenticated Keycloak user who already holds resource-management permissions sends a crafted UMA resource-registration update request that names a resource ID belonging to another owner, and the server applies the change because it does not verify ownership. The attacker thereby rewrites another user's resource configuration - its name, URIs, or scopes. No public exploit code or PoC reference is present in the supplied data, and exploitation is only possible when remote resource management is enabled.