CVE-2026-18207Keycloak client policy enforcement flaw

What broke

Keycloak did not enforce a client policy the way the realm configuration said it would. Client policies are the control that requires PKCE, blocks implicit flow, or asserts FAPI. A policy that does not fire is a paper control. Red Hat patched in 2026. Keycloak advisories in the same period also document a WebAuthn attestation-policy bypass (fmt:none).

Why it matters

Most Keycloak hard-won lessons live in client policies, not in the default realm. If those policies are skippable, every "we are FAPI-grade" statement in an audit package is wrong.

What to do

• Upgrade Keycloak to the 2026 build that names CVE-2026-18207.
• Add a test client that violates each policy (no PKCE, implicit, fmt:none) and assert it is rejected.
• Read the OAuth 2.0 pitfalls section before you relax a policy to "make a vendor integration work."

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-2026-18207
• Red Hat Keycloak advisories, including WebAuthn fmt:none