Three weeks ago this site called Keycloak 26.7 the identity layer community infrastructure was missing — SCIM provisioning, Shared Signals, AuthZen, one place to manage accounts across Nextcloud, Matrix, and Gitea. Nine days ago we covered 26.7.2, the CVSS 9.1 password-reset takeover, and told readers to be on 26.7.2.

That advice had a shelf life measured in days.

Keycloak 26.7.3 shipped August 31 with fixes for twenty CVEs — after a 26.7.2 that fixed nine. Twelve days between patch batches on the same point release. This is what running an identity provider looks like now, and community operators need to plan around it rather than be surprised by it.

Where the CVEs Cluster

The densest cluster is in fine-grained admin permissions (FGAP v2) — Keycloak's delegated administration model. This is the feature that lets you hand a volunteer control over their own group without giving them realm admin. For community deployments it's the whole argument for centralized identity: the fire hall's captain manages the fire hall's group, the town office's clerk manages theirs, and nobody holds the master key who doesn't need it.

Five of the twenty CVEs are in that boundary directly, and a sixth sits in the adjacent RBAC surface:

  • CVE-2026-16108 — realm default-group reads disclose hidden groups under FGAP v2.
  • CVE-2026-16105 — missing per-role authorization on RoleContainerResource composite endpoints.
  • CVE-2026-16106 — delegated admin can remove privileged child roles via role-composite deletion.
  • CVE-2026-16104 — authenticator config surfaces expose raw reCAPTCHA secrets to delegated admins.
  • CVE-2026-17059 — GET /roles/{role}/users returns user PII without the per-user view filter.
  • CVE-2026-18571 — group assignment bypass during user creation (POST /users).

The release's separate "Weaknesses" section — hardening fixes without CVE numbers — adds five more FGAP items. That's eleven changes to one subsystem in a single point release.

Read that honestly. It does not mean delegation is a bad idea. It means the delegated-admin boundary is young software under active repair, and every release rewrites some of what delegated admins could see or touch. If you use FGAP v2, your delegation assumptions from last month are already stale. Re-review who holds what after upgrading, and assume the disclosure-class endpoints above were readable by delegated admins before this patch — because some of them were.

Two Fixes That Didn't Hold

Two of the twenty are corrections to earlier fixes. This is the part worth dwelling on.

CVE-2026-18209 — the redirect_uri OIDC response-parameter injection. The previous fix (commit 18832bca) checked that forbidden parameters appear only in the query string. It didn't check the URL fragment. A parameter the server refuses in the query sails through in the fragment.

CVE-2026-19729 — an incomplete fix for CVE-2026-9083. The original fix, shipped in 26.4.13 and 26.6.4, restricted the java-keystore key provider's keystore parameter to a per-realm directory using a startsWith check. Relative path traversal walks around startsWith. Filesystem probing remained possible on 26.6.4 — a version released specifically as a security-response patch.

The lesson generalizes past Keycloak: a CVE number disappearing from your scanner is not the same as the flaw going away. Advisory lists are append-only truth. The fix that ships in the emergency patch is not always the fix that holds, and the follow-up lands weeks later in a release nobody headlines. This is another reason the "patch on schedule, not on headline" habit matters — the headline is where the first attempt lands, not the last.

The Rest, Briefly

  • CVE-2026-16093 — client policies: required signed-JWT assertion enforcement can be bypassed with a fake unsigned assertion header. The attacker needs valid client credentials, and the effect is a silent downgrade — a client authenticates with a plain secret even though the administrator mandated signed assertions. If you use client policies to require private_key_jwt for machine clients, that mandate was not binding until this release.
  • CVE-2026-16089 — authorization codes can be retargeted to another client session.
  • CVE-2026-16072 — organization managers can create managed members through stored registration links without the manage-users permission.
  • CVE-2026-18218 — client not-before revocation is ignored when the realm not-before is older but nonzero. A revocation-window bug: tokens you believed revoked were still valid in some orderings.
  • CVE-2026-18215 / CVE-2026-18214 — external access-token exchange via Microsoft and Google bypasses configured tenant and hosted-domain restrictions. Relevant if you federate login through Entra ID or Google Workspace and rely on Keycloak to scope what those brokers can exchange.
  • CVE-2026-18201 — generic identity-provider creation can bind brokers to organizations without manage-organizations.
  • CVE-2026-18572 — a UMA claim token can override the authorization time-policy clock.
  • CVE-2026-18573 — client access-type condition evaluates updates against the old client type.
  • CVE-2026-18570 — full-scope-disabled client policy validation can be bypassed by omitting fullScopeAllowed.
  • CVE-2026-79652 — the jwt-bearer authorization grant does not enforce consentRequired.
  • CVE-2026-35563 — the Apache Directory LDAP API hostname-verification flaw (missing endpoint identification, CVSS 8.8, MITM-exploitable). In Keycloak it appears only in test/development dependencies (ApacheDS) — production LDAP federation is not affected. Listed here so nobody burns an evening grepping their LDAP config for it.

What This Says About Running Identity

The release sequence since July: 26.7.0 shipped July 9 with the feature set worth deploying. Then 26.7.1. Then 26.7.2 on August 19 with nine security fixes. Then 26.7.3 on August 31 with twenty. Twenty-nine security fixes in eight weeks on a point release.

That's not Keycloak being sloppy. That's what identity software is: the component every other component believes. Delegated admin, token exchange, brokers, client policies, recovery flows — every feature that makes an identity provider valuable is a trust boundary, and trust boundaries collect CVEs faster than file servers do. You cannot opt out of the cadence by choosing conservative settings, because some of these bugs are in defaults and in flows every deployment runs.

The community-ops reality is that the volunteer who set up Keycloak in March is not reading keycloak.org in September. So make the patching mechanical instead of heroic:

  • Put the identity-layer upgrade on the same schedule as backups — monthly, calendared, boring. The batch you skip between headlines is where the next password-reset bug lives.
  • Pin the exact patch version in your compose file or k8s manifest, so "latest" doesn't decide for you and rollback is a one-line change.
  • Subscribe to the Keycloak release feed and let the notification do the remembering.

What To Do

  1. Upgrade to 26.7.3. Follow the migration guide. If you're on the 26.6.x line: these fixes are tagged upstream for a future 26.6.7, which has not shipped as of this writing — the released version carrying them is 26.7.3.
  2. If you use FGAP v2 delegation, re-review every delegated role assignment after upgrading, and check admin audit logs for the disclosure-class endpoints listed above. Rotate anything a delegated admin shouldn't have been able to read, if your threat model says that matters.
  3. If you mandate signed-JWT client policies, verify enforcement with a test client after the upgrade. Pre-26.7.3, the mandate was bypassable, and you should know whether it was used.
  4. CVE-2026-35563 requires no action unless you build Keycloak from source and pull in ApacheDS test dependencies.

The identity layer is still worth running. Single sign-on with real provisioning and shared signals beats five separate user databases and five places to forget a departing member. But it is the component every other component believes, and belief is expensive to maintain. Patch it on a schedule, not on a headline.