Four weeks ago this site covered 26.7.3 — twenty CVEs twelve days after 26.7.2's nine. On September 16, 26.7.4 landed with six more. That is thirty-five security fixes across three point releases in four weeks on the same minor line. The cadence is no longer a pattern you can describe; it is the operating condition. This post is the third in the series and the advice has not changed: patch on schedule, not on headline. What has changed is which specific delegation you need to re-examine this week.

CVE-2026-17526: the impersonation role had no ceiling

Red Hat's advisory (Bugzilla 2507409) lays out the mechanics plainly. A user holding only the impersonation realm-management client role could call the impersonation endpoint against any enabled, non-service-account user in the realm — including full realm administrators. The endpoint does two checks: it blocks service-account targets, and it performs no privilege-level check on the target. CWE-862, missing authorization.

The post-exploitation path matters as much as the bug. Impersonating an administrator yields a valid SSO session — not just a look at someone's screen. That session can be exchanged for a fully signed access token through a standard OIDC authorization-code flow, and from there the attacker holds the realm: all users, all clients, all roles, password resets for anyone.

CVSS 7.2, and the score is honest about the gate: PR:H — the attacker must already hold the impersonation role. This is not a remote-unauthenticated bug and nobody should panic-patch at 3am for it. But look at what the gate actually is: a role assignment decision. Role assignments are the part of identity systems that drift. The support volunteer from March, the consultant who helped with the migration, the "temporarily elevated" account that was never demoted — every one of them was one API call from full realm control, and none of your configs would have shown it, because impersonation is supposed to be the lesser role. That is precisely what the design intent said and precisely what the flaw defeated.

Community deployments should read this as a specific instruction, not a general warning. If you granted impersonation to non-administrators — and handing it to whoever "helps with accounts" is exactly the pattern community infrastructure produces — then:

  1. Upgrade first (see below), then audit who holds the role. In the admin console: Realm Settings → the realm-management client roles → check every user and group carrying impersonation. Default posture going forward: nobody holds it except break-glass accounts, and impersonation duties stay separated from administrative duties.
  2. Turn on admin event logging if it isn't already, and alert on impersonation events. Red Hat's remediation guidance asks for exactly this; post-patch, every impersonation call in your logs is either you or a bug you want to know about.

Two unauthenticated DoS on paths you actually run

  • CVE-2026-79651 (7.5) — unbounded locale caching lets an unauthenticated request drive an out-of-memory condition. If your realm serves a login page to the public internet — and for most community deployments that is the entire point of the thing — this is reachable by anyone who can load that page.
  • CVE-2026-18212 (7.5) — the SAML DEFLATE helpers leak native zlib memory on the redirect-binding endpoints. If you expose SAML endpoints, same reachability, and native memory leaks take the JVM down with them.

PhaseTwo's triage table puts both in the "this week" column for public-facing realms, alongside the impersonation fix. One honest counterpoint from the same table: if your Keycloak is reachable only from inside your network, these two can wait for the next normal cycle without drama. Prioritize by exposure, not by CVE count.

The replay gate that never worked on one stack

CVE-2026-90997 (7.4): on MySQL/MariaDB, row counts made the replay-protection gates accept reused artifacts. Per PhaseTwo's analysis, replay protection was not working in stateless mode on that stack, and only 26.7.4 carries the fix. If you run stateless Keycloak against MySQL or MariaDB, this is not a hardening item — it is a broken control.

CVE-2026-19607 (5.3): a brokered username collision locks the legitimate user out. Not theft — lockout. For an identity layer, locking a person out of their account is an availability failure with an account-takeover shadow: the collision also means someone else arrived claiming a name that was already yours.

CVE-2026-74909: the policy enforcer accepts a weaker policy

The highest-scored CVE in the batch (8.1): encoded characters trick the policy enforcer into evaluating a weaker policy. If you use the policy enforcer or UMA permissions to protect resources, two actions: patch, then re-read your resource URIs — the fix changes enforcement behavior, and a protection you configured by exact URI match may now be evaluated differently than you assume. This is the CVE most likely to produce a silent regression in a deployment that patches and walks away.

What To Do

  1. Upgrade to 26.7.4. Follow the migration guide. Red Hat Build of Keycloak users: fixes landed as 26.4.16 and 26.6.7 per the RHSA errata — match your stream.
  2. Audit the impersonation role (step 1 above) — this is the action unique to this release, and it is a config review, not just a version bump.
  3. Public login page or exposed SAML? 26.7.4 this week. Internal-only? Batch it with the next cycle.
  4. Stateless + MySQL/MariaDB? 26.7.4, and treat replay protection as newly restored — re-verify any assumptions built on it.
  5. Policy enforcer in use? After patching, test that protected resources are still protected the way you configured them.
  6. Pin the exact version in your compose file or manifest. Same advice as last time, same reason.

Thirty-five security fixes in twenty-eight days is the identity layer doing what identity layers do: collecting trust-boundary bugs faster than everything around them, because everything around them believes what they say. The community-ops reality is unchanged — the volunteer who set up Keycloak in March is not reading keycloak.org in September, and the apps in front of it break on their own schedule too. Make the upgrade calendared and boring, review delegation assignments while you're in there, and let the notification feed do the remembering.

Sources: Keycloak 26.7.4 release; PhaseTwo: Keycloak 26.7.4 — 6 CVEs, Two Unauthenticated DoS; Red Hat CVE-2026-17526 advisory; Red Hat Bugzilla 2507409; elest.io Self-Hosted Weekly, week 38.