# Keycloak UMA policy privilege escalation

Source: https://startwithidentity.com/cves/cve-2025-14778/
Last updated: 2026-08-29
License: content by Start with Identity. Cite the source URL.

---

## What broke

Keycloak's UMA (User-Managed Access) policy evaluation looked at the first resource and ignored the rest. A request that named an allowed resource first, then a denied one, passed. CWE-266. Red Hat patched.

## Why it matters

UMA is how some teams do resource-level authorization in [OAuth](https://startwithidentity.com/glossary/oauth/). Checking only the first item is the authorization equivalent of `skip_auth_routes` matching a prefix. Fine-grained access that is not fine.

## What to do

- Upgrade Keycloak.
- If you built UMA policies, add a regression test that names two resources, one allowed and one denied, in both orders.

## After you patch

Token-layer flaws produce credentials that keep working after the patch, so remediation is about invalidating what was issued.

- **Rotate the signing keys** published at your [JWKS](https://startwithidentity.com/glossary/jwks/) endpoint, then confirm relying parties refetch on an unknown key id rather than caching indefinitely.
- **Revoke [refresh tokens](https://startwithidentity.com/glossary/refresh-token/) and sessions.** Access tokens expire on their own; refresh tokens are the ones that turn a short compromise into months of access.
- **Audit client registrations and consent grants** created during the window, particularly any client with broad scopes or a redirect URI you do not recognize.
- **Verify validation on your side**: pinned algorithms, issuer and audience checks, and no acceptance of `alg: none`. See [JWT](https://startwithidentity.com/glossary/jwt/) and the [validate a JWT recipe](https://startwithidentity.com/recipes/validate-a-jwt/).

## Sources

- [NVD: CVE-2025-14778](https://nvd.nist.gov/vuln/detail/CVE-2025-14778)