Keycloak CVE-2026-94217

Requires Keycloak's User-Managed Access (UMA) feature to be enabled (opt-in, not a default deployment mode), and an authenticated attacker account (PR:L) able to create resources. The exploit is gated on a specific precondition: the attacker and a victim must both own resources sharing the exact same name, so the flawed permission merge occurs when the attacker requests an authorization token through the permission-ticket flow. These preconditions (UMA enablement plus name collision) substantially limit real-world exploitability and argue for higher attack complexity than the vendor's AC:L. Impact is confined to gaining unintended access scopes on the specific colliding resource.

This is a genuinely low-severity issue and should be treated as low priority. The CVSS 3.1 base score of 3.5 (AV:N/AC:L/PR:L/UI:R/S:U/C:N/I:L/A:N) reflects an authenticated (PR:L) attacker achieving only limited integrity impact (I:L) with no confidentiality or availability impact per the vendor. No EPSS score, KEV listing, or public exploit is present in the supplied data, so exploitation status is: no public exploit identified at time of analysis. The CWE-862 (missing authorization) classification is consistent with the described logic flaw. Two vector points warrant scrutiny: the vendor sets AC:L, but exploitation depends on a specific precondition - two distinct users owning resources with the identical name AND the UMA feature being enabled - which more realistically maps to AC:H; and UI:R is questionable since the described merge occurs when the attacker requests an authorization token, with no obvious victim interaction required. The C:N assignment is also arguable, as gaining unintended access scopes on a victim resource could permit reads (confidentiality), not just integrity. These are refinements, not escalations - the overall risk remains low. The 'Authentication Bypass' tag is a mislabel; this is an authorization/broken-access-control defect, not an authentication bypass.

An authenticated Keycloak user on a realm with UMA enabled creates a resource whose name exactly matches the name of a resource owned by a victim user. When the attacker requests an authorization token via the permission-ticket flow, the endpoint merges permissions across the two same-named resources, granting the attacker access scopes on the victim's resource that were never shared. No public exploit code is identified at time of analysis.