Keycloak 26.7.3 fixes 20 CVEs. Here's which ones can actually reach you.

2026-09-01 · keelinfra

"20 CVEs fixed" is the kind of release note that gets forwarded to a CISO with no further context. Most of the time, three of those twenty can reach your cluster and the rest are gated behind features you never turned on. Nobody tells you which three. We did the sorting for 26.7.3 — released 2026-08-31 — and we're publishing the method, not just the answer, so you can redo it on the next release yourself.

There's a second problem 26.7.3 fixes that the CVE count doesn't cover at all: six functional regressions introduced inside the 26.7 stream itself, including one that pins CPU high on every node after upgrade. If you're running 26.7.0–26.7.2, that alone is worth reading past the CVE table for.

The three questions, cheapest first

Before treating any CVE in a batch as urgent, ask in this order:

1. Is your version before the fix? On the fixed release or later — stop here.
2. Is the feature it touches turned on? Most Keycloak CVEs live inside a subsystem — fine-grained admin permissions, organizations, token exchange, SAML brokering, LDAP federation, dynamic client registration. A cluster that never enabled it cannot be reached through it.
3. Who can reach the surface? An admin-API flaw exploitable by a delegated admin is a different risk with three admins than with three hundred realm managers. An unauthenticated endpoint doesn't care how many admins you have.

Full method and the reasoning behind it: CVE-POLICY.md.

26.7.3, sorted

Twenty CVEs, grouped by what has to be true for each one to matter (upstream release notes):

Two rows are worth reading twice. 2026-16105 sits under upstream's admin/rbac label, not fine-grained permissions — a quick skim of "these are all FGAP issues" skips it, and it reaches any deployment that delegates role management through the admin API, FGAP on or off. And the "any OIDC deployment" row is seven flaws, not one — including an authorization code retargetable to another client session and an incomplete fix for redirect_uri parameter injection. Nobody who runs OIDC (which is nearly everyone) walks away from that row clean.

Add the one "any deployment" path-traversal flaw and you have eight CVEs that apply regardless of what you've configured. If you're on 26.7.0–26.7.2, those eight alone are the upgrade argument, before you even look at the gated rows.

The other reason not to sit on 26.7.0-26.7.2

26.7.3 also repairs six regressions that shipped inside the 26.7 stream — none of them CVEs, all of them the kind of thing that pages someone at 3am:

A CVE scanner won't flag any of these. We only found the full list because we run every supported path in CI and read what actually happens, not just what the release notes summarize.

The tested way off it

We don't list an upgrade path we haven't run end-to-end — install, log in, upgrade, assert the pre-upgrade session survives. Two paths land you on 26.7.3:

./upgrade --to 26.7.3   # from 26.6.2 (stop-start) or 26.7.0 (rolling)

Both are single-node CI-verified nightly as of 2026-08-31; the 3-node HA drill hasn't run against this specific target yet, so if you're on HA, drill it in staging first. Full matrix, updated as paths get verified: UPGRADES.md.

What we will and won't do about a CVE

We track upstream, do this triage for every release, and point you at a drilled upgrade path. We do not backport patches to old branches — a real backport program means rewriting a 26.7 fix for a 26.2 codebase and owning the regression risk of that rewrite, release after release, which is a different business than the one we're running. When upstream tags a maintenance release with no community artifact, we build the unmodified tag and publish it — see the LTS builds — but that's compiling, not patching. Full boundary, including what a subscription adds on top: CVE-POLICY.md.

Run the triage yourself

git clone https://github.com/keelinfra/keycloak && cd keycloak
./configure -c examples/single-node.yml
./install
./upgrade --to 26.7.3
./verify --drill session   # pre-upgrade session must still refresh

Then read the 26.7.3 release notes against the three questions above for your own configuration — the table in this post is a starting point, not a substitute for reading the advisory when a specific CVE is load-bearing for a decision you're making.

keelinfra is an open-source (Apache-2.0), production-ready self-hosted Keycloak distribution. A subscription adds CVE notification matched to the version you actually run, and upgrade help along a path we've already drilled: keelinfra.io/pricing · hello@keelinfra.io.

Keycloak is a trademark of The Linux Foundation. keelinfra is an independent project, not affiliated with or endorsed by The Linux Foundation or the Keycloak project.