Upstream CVEs
Every Keycloak release fixes a batch of CVEs. A 20-CVE release sounds like an emergency; usually three of them can reach your cluster and the rest are gated behind features you never turned on. This page is about telling those apart, and about what we will and will not do on your behalf.
Vulnerabilities in this distribution — our playbooks, roles and defaults — are a different thing, covered by SECURITY.md. This page is about CVEs in upstream Keycloak and the other components we deploy.
What we commit to
- Tracking. We follow upstream releases and work out which CVEs affect the versions we support, including the streams where upstream has stopped publishing community artifacts.
- Impact analysis. Not "26.7.3 fixes 20 CVEs" but "of those 20, these are reachable given how you run it". The method is below; you can run it yourself.
- Mitigation advice where a configuration change closes the gap without an upgrade — turning a feature off, restricting who reaches an endpoint.
- A tested way out. When a CVE matters to you, the upgrade to a fixed version runs along a path in UPGRADES.md that we have actually executed, not one we assume works.
What we do not commit to
We do not backport security patches to old versions.
Upstream ships fixes on the current stream. A real backport programme means taking a patch written against 26.7, rewriting it for a 26.2 codebase, and owning the regression risk of that rewrite — for every CVE, for years. That is what Red Hat staffs a team to do, and it is priced accordingly.
What we do instead is narrower and worth being precise about: when upstream cuts a maintenance tag but publishes no community artifact, we build that tag from unmodified upstream sources and publish the result (see the KeelInfra LTS builds section of UPGRADES.md). Every fix in those builds was written by upstream. We compile and verify; we do not patch.
This boundary does not move for subscribers. A subscription buys earlier notification and analysis against your actual configuration — not a different engineering capability.
How to tell whether a CVE affects you
Three questions, cheapest first.
1. Is your version before the fix? If you are on the fixed release or later, stop here.
2. Is the feature it touches turned on? This eliminates the most. Most Keycloak CVEs live in a subsystem — fine-grained admin permissions, organizations, token exchange, SAML brokering, LDAP federation, dynamic client registration — and a cluster that never enabled it cannot be reached through it.
3. Who can reach the surface? An admin REST API flaw exploitable by a delegated admin is a different risk on a cluster where three people hold admin roles than on one with hundreds of realm managers. An unauthenticated endpoint flaw does not care.
Worked example: Keycloak 26.7.3
20 CVEs, grouped by what has to be true for them to matter (release notes):
| Only relevant if you run | CVEs |
|---|---|
| Fine-grained admin permissions (FGAP v2) | 2026-16108, 16104, 16106, 17059, 18571 |
| Delegated admin over roles (any admin API role management) | 2026-16105 |
| Organizations | 2026-16072, 18201 |
| Token exchange with Microsoft or Google IdPs | 2026-18215, 18214 |
| UMA / authorization services | 2026-18572 |
| LDAP user federation | 2026-35563 |
| Any OIDC deployment | 2026-16093, 16089, 18218, 18209, 18573, 18570, 79652 |
| Any deployment | 2026-19729 |
Grouping follows upstream's own component labels. Note that 2026-16105 sits
under admin/rbac, not fine-grained permissions — missing per-role
authorization on composite-role endpoints reaches any deployment that delegates
role management through the admin API, whether or not FGAP is enabled. It is the
kind of entry that a quick read of "these are all FGAP issues" would skip.
The last two rows are the ones nobody escapes: seven OIDC flaws — including authorization codes retargetable to another client session and an incomplete fix for redirect_uri parameter injection — plus a path traversal usable for filesystem probing. If you run 26.7.0–26.7.2, those eight alone settle it.
Worked example: the 26.6 stream
26.6.4 is the last community release on that branch; 26.6.5 and 26.6.6 exist as tags only. 26.6.4 → 26.6.6 carries 12 CVEs:
| Only relevant if you run | CVE | What it is |
|---|---|---|
| Fine-grained admin permissions | 2026-14614 | Bypass in client scope assignment |
| Identity brokering | 2026-15571 | Legacy client-initiated account linking |
| Dynamic client registration | 2026-15572 | Mapper-type swap via DCR |
| Dynamic client registration | 2026-16102 | Admin role assignment through protocol mappers |
| Authorization services / policy enforcer | 2026-15573 | Authorization bypass via mutated paths |
| LDAP user federation | 2026-16071 | LDAP_ENTRY_DN not validated against the configured usersDn |
| SAML identity brokering | 2026-16442 | Link-only restriction not enforced on IdP-initiated login |
| SAML identity brokering | 2026-16443 | Signature validation skipped when the metadata KeyDescriptor has no use |
| Vault + rotated client secrets | 2026-17048 | Admin REST API leaks vault-resolved rotated secrets |
| Metrics enabled | 2026-16100 | Out-of-memory via request-controlled error text |
| Tracing enabled | 2026-45292 | Unbounded baggage propagation |
| Authentication flow selection | 2026-18963 | Auth note set from the wrong identifier — upstream did not document the trigger conditions |
This one is unusually configuration-dependent: a plain OIDC deployment with no LDAP, no SAML brokering, no DCR and no fine-grained permissions is genuinely outside most of it. A cluster doing enterprise SSO with LDAP and SAML federation is inside half the table.
Build evidence for the published artifacts: VERIFICATION-26.6.6.md.
What this analysis is not
Read the tables as triage, not clearance.
- "Gated on a feature you don't run" means that route is closed. It is not a statement that the code is unreachable by some other path.
- Upstream does not always publish full exploitation conditions at release time, and details get corrected afterwards. Our grouping comes from upstream's own component labels and commit subjects — good enough to sort 20 CVEs into "act now" and "act at the next window", not good enough to be the only input to a risk decision.
- Incomplete fixes are common. Several entries above are second attempts at a CVE that was already declared fixed once. Being on the release that first claimed a fix is not the same as being fixed.
If a CVE is load-bearing for a decision, read upstream's advisory rather than our summary of it.
If your stream has no community artifacts
Two of them are in that state right now — 26.2 past 26.2.5, and 26.6 past 26.6.4. Upstream keeps tagging fixes on those branches, but the artifacts ship only in Red Hat's commercial build.
Staying put means accumulating unfixed CVEs with no supported way out. The
KeelInfra LTS builds listed in UPGRADES.md are the alternative:
the same upstream tags, built from source and published, installable with
./upgrade --dist-url <release url>, with the upgrade path drilled in CI first.
What a subscription adds
The analysis on this page is public, and the upgrade matrix that backs it runs nightly whether or not you pay. A subscription adds:
- Notification when a release lands that affects the version you run, so tracking upstream is not your job
- Analysis against your configuration rather than the generic tables above — which of this batch actually reaches your cluster
- Upgrade assistance when something high-severity means moving now, along a path that has been drilled
Scope of that access: email, best effort, no response-time guarantee. If you need a contractual SLA, this is not the tier for it — say so and we will tell you honestly whether we can serve you.
Synced from keelinfra/keycloak/CVE-POLICY.md @ f86d62b — to change it, edit it there.