Keycloak 26.7.3 Security Fixes: A Self-Hosted Patch Checklist

Keycloak 26.7.3, released on 31 August 2026, is a security release. The release notes list twenty CVEs, concentrated in fine-grained admin permissions (FGAP v2), OIDC and token handling, external token exchange, Organizations, and client policy enforcement. For self-hosted teams the headline is not any single CVE, it is where the fixes landed: this set went into 26.7.3, and the current builds on the 26.4, 26.5 and 26.6 lines do not carry it. If you run one of those, the upgrade to 26.7.3 is how you get these fixes.

This is a release-tied ops brief, not a general hardening guide. If you want the broader production checklist, we keep one at the Keycloak security hardening checklist, and the version-strategy question is covered in our Keycloak upgrade strategy post. What follows is specific to this patch set: what changed, what to re-test, and which items are quieter than their CVE titles suggest.

What did Keycloak 26.7.3 actually fix?

The 26.7.3 release notes on GitHub enumerate the full set. Grouping them by the part of the system they touch is more useful than reading them in CVE-number order, because the re-testing work groups the same way.

Fine-grained admin permissions (FGAP v2). This is the largest cluster, and it matters most to anyone running delegated administration:

OIDC and token handling:

External token exchange. Two bypasses in the same family, both worth attention if you exchange external provider tokens: CVE-2026-18215 (Microsoft external access-token exchange bypasses the configured tenant) and CVE-2026-18214 (Google external access-token exchange bypasses the hosted-domain restriction). If you use either provider as a trust boundary for a corporate tenant or domain, those restrictions were not being enforced the way the config implied. Our token exchange practical guide covers the mechanics if you need background on the flow.

Organizations. CVE-2026-16072 and CVE-2026-18201 both let an actor act outside the permission the admin model implies. We wrote those up separately in the Keycloak Organizations CVE brief, since B2B tenants are the ones affected.

Client policy, UMA and path traversal. The remainder do not group as neatly, and they are the ones most likely to be skipped in a quick read of the release notes:

Together with the LDAP entry covered further down, that is the full twenty. If you are working from a scanner report rather than the release notes, CVE-2026-19729 is the one worth reading first: it is a follow-up to an earlier path-traversal fix that turned out to be incomplete.

Which of these are remotely exploitable by an anonymous attacker?

Mostly none of them, though this is a place to check your own configuration rather than take a blanket answer. The FGAP and Organizations items are authorization gaps inside administrative surfaces, so the realistic threat model is privilege escalation or over-disclosure by an account you already handed a limited admin role to, not an outsider walking in. That makes them serious for anyone running multi-tenant delegated administration and largely theoretical for a single-team realm where every admin is already a full admin. Each CVE in the release notes links to its own advisory with a CVSS vector, and if you need to justify a specific patch window to a change board, those vectors rather than this summary are what you should be quoting.

The OIDC items are the ones to prioritize if you have to sequence the work. CVE-2026-16093 undermines a control you explicitly turned on, which is worse than it sounds: a client configured to require signed JWT client assertions was accepting unsigned ones. CVE-2026-16089 and CVE-2026-18209 both live in the authorization-code path that every browser login goes through.

Do I need an emergency patch window?

For most self-hosted deployments, no. This is a scheduled-maintenance patch set, not a drop-everything one. Move it to the front of the queue, inside your normal change process, if any of these are true:

• You run delegated administration with FGAP v2 and non-trivial admin scoping
• You use Microsoft or Google external token exchange and rely on tenant or hosted-domain restriction as a security boundary
• You use Organizations for B2B tenant isolation
• You have clients configured to require signed JWT assertions

If none of those apply, patch on your normal cadence, but do not let it slide a quarter. The FGAP fixes in particular tend to matter more later, when someone adds a delegated admin role and assumes the permission model held all along.

The patch checklist

1. Confirm what you are actually running

Check the running version rather than the version you think you deployed:

kubectl exec -it deploy/keycloak -- /opt/keycloak/bin/kc.sh --version

Container image tags drift from what is deployed more often than anyone likes to admit.

2. Understand which line the fix actually landed on

This is the part that surprises teams, and it is worth stating precisely because the common shorthand is wrong. Keycloak does keep publishing point releases on older minor lines: 26.4.15 and 26.6.6 both shipped on 11 August 2026, well after 26.7.0 arrived in July, and they carried their own backported security fixes. So “Keycloak only ever patches the newest minor” is not true, and you should not plan around it.

What is true is narrower and more useful: this particular set of fixes went into 26.7.3, and the current builds on the 26.4, 26.5 and 26.6 lines do not include it. Upstream’s security policy explains why the outcome varies. Depending on severity, an issue may be fixed in the current major.minor release, or, for lower severity vulnerabilities and hardening, in the following one. Since most of this release is moderate-severity hardening, it landed forward rather than backward.

The practical move is to check the newest tag on your own line rather than assume either way. If it does not carry the CVEs you care about, your patch path is a minor-version upgrade with everything that implies: database migration, theme compatibility, and a real staging pass.

The same policy points teams that cannot upgrade regularly at Red Hat build of Keycloak, which offers long term support for specific versions. If you are on RHBK rather than upstream, your patch cadence follows Red Hat’s lifecycle instead and this section does not apply to you.

That is a structural cost of self-hosting Keycloak, and it is worth pricing honestly. We went through the arithmetic in is self-hosting Keycloak worth it in 2026.

3. Re-test token exchange policies, not just the upgrade

The Google and Microsoft fixes change enforcement, which means a configuration that quietly worked before may now correctly reject tokens it previously accepted. Before you upgrade production, in staging:

• Exchange a token from a user inside your configured Microsoft tenant and confirm it still succeeds
• Exchange one from outside it and confirm it now fails
• Repeat for the Google hosted-domain restriction

If step one fails after the upgrade, your tenant or hosted-domain configuration was wrong and the old behavior was masking it. That is a fix surfacing a latent misconfiguration, not a regression.

4. Re-check delegated admin assumptions

For each delegated admin role you have defined, confirm it still sees only what you intended, particularly group listings and the user lists behind roles. The FGAP fixes tighten what those endpoints return. A tightening can break internal tooling that was reading data it should never have had.

5. Verify signed-assertion clients

If any client is configured with a signed JWT client assertion requirement, send it an unsigned assertion in staging and confirm it is rejected. That is the direct regression test for CVE-2026-16093.

What about the LDAP CVE in this release?

CVE-2026-35563 appears in this release and reads alarmingly: an LDAP client that does not verify that the server certificate matches the intended hostname. Before you schedule a federation re-test, read the scope. Keycloak’s own tracking issue for it, issue #50785, describes it as present in Keycloak’s development dependencies, a transitive dependency of ApacheDS, which Keycloak uses as an embedded LDAP server in its test suite. It is not the code path your LDAP user federation runs on.

Keycloak’s production LDAP behavior is unchanged, and its documentation is explicit that secure LDAP connections require strict hostname checking regardless of the general tls-hostname-verifier setting. We went into that in more detail in the Keycloak LDAP certificate validation post, because the CVE title has been widely misread as a federation bug.

This is a good argument for reading scope before triaging by CVE title. A dependency-scope CVE in a test harness and an authorization bypass in a live admin endpoint both show up as red rows in a scanner report.

What managed Keycloak covers here, and what it does not

On Skycloak the platform upgrade is ours: we track upstream releases, roll patched builds, and you do not run the kc.sh upgrade yourself. That removes the version-tracking work and the minor-version upgrade itself, the database migration and staging pass described above, which is the expensive part when you are several minors behind.

It does not remove steps 3 through 5. Token exchange policies, delegated admin scoping and client assertion requirements are realm-level configuration that belongs to you, and a platform upgrade cannot validate your intent. A managed platform changes who owns the upgrade treadmill and how quickly the patched build is available to you, not whether your own realm configuration still expresses what you meant.

FAQ

Is Keycloak 26.7.3 a mandatory upgrade?
There is no mandatory upgrade mechanism in Keycloak. On upstream, moving to 26.7.3 is currently the way to receive this particular set, because the latest 26.4, 26.5 and 26.6 builds do not carry it. Those lines do still get their own point releases, so watch your line’s tags rather than assuming a fix will never arrive, and consider Red Hat build of Keycloak if you need long term support on a pinned version.

Which 26.7.3 CVEs are the most serious for a typical deployment?
Our reading, which is a judgment call rather than a severity ranking from upstream, is that the OIDC ones deserve attention first because they sit in code paths every deployment exercises: CVE-2026-16093 (signed-assertion bypass), CVE-2026-16089 (authorization code retargeting) and CVE-2026-18209 (redirect_uri response-parameter injection). CVE-2026-19729 is worth reading too, since it is a follow-up to an incomplete path-traversal fix. The FGAP cluster outranks all of those if you run delegated administration. For a formal severity call, use the CVSS vector on each advisory linked from the release notes.

Does CVE-2026-35563 mean my LDAP federation was insecure?
No. It is scoped to a test-suite dependency (ApacheDS), not the LDAP user federation client, per Keycloak’s own issue #50785. Your federation TLS configuration is worth auditing on its own merits, but this CVE is not the reason.

Can I skip straight from 26.4 to 26.7.3?
Keycloak supports upgrading across minors within a major, and the database migration runs on first start. Test it in staging against a production-sized database copy, because the migration duration is what usually surprises people, not the migration itself.

Do the token exchange fixes break existing integrations?
They can, and that is the intended behavior. If your Microsoft tenant or Google hosted-domain restriction was misconfigured, exchanges that previously succeeded will now fail. Test both the allowed and the denied case before production.