CVE-2025-14778Keycloak UMA policy privilege escalation

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. 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 endpoint, then confirm relying parties refetch on an unknown key id rather than caching indefinitely.
• Revoke refresh tokens 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 and the validate a JWT recipe.

Sources

• NVD: CVE-2025-14778