Last updated: September 2026
Keycloak 26.7.4, released on 16 September 2026, fixes six CVEs: two unauthenticated denial-of-service bugs (CVE-2026-79651 and CVE-2026-18212), a policy enforcer bypass (CVE-2026-74909), an impersonation escalation to realm administrator (CVE-2026-17526), a brokered-login lockout (CVE-2026-19607), and a replay protection bypass in stateless mode on MySQL and MariaDB (CVE-2026-90997). Five of the six were also tagged on the 26.6 and 26.4 lines as 26.6.7 and 26.4.16, and the sixth only affects 26.7. The release also carries one intentional breaking change in how Authorization Services match resource URIs, so read that section before you roll it out.
This is a release-tied brief for teams that run Keycloak themselves. It groups the fixes by how urgently they apply to you, shows which release line carries each one, and lists what to re-test in staging. The previous release has its own 26.7.3 patch checklist, and the general production baseline lives in the Keycloak security hardening checklist.
What did Keycloak 26.7.4 fix?
The 26.7.4 release notes list six CVEs under “Security fixes”, and Red Hat published five of the six CVE records on 16 September 2026, with CVE-2026-90997 following on 17 September. Their CVSS 3.1 base scores run from 5.3 to 8.1, and four of the six need no authentication at all (Keycloak 26.7.4 release notes, 2026).
| CVE | What it allowed | CVSS 3.1 | Auth needed |
|---|---|---|---|
| CVE-2026-74909 | Percent-encoded URI segments let a request dodge the policy enforcer’s intended resource | 8.1 | Any user |
| CVE-2026-79651 | Unbounded locale caching on public theme endpoints exhausts the heap | 7.5 | None |
| CVE-2026-18212 | SAML Redirect binding DEFLATE helpers leak native zlib memory | 7.5 | None |
| CVE-2026-90997 | Stateless mode on MySQL or MariaDB accepts replayed single-use artifacts | 7.4 | None |
| CVE-2026-17526 | The impersonation role could impersonate a realm administrator |
7.2 | impersonation role |
| CVE-2026-19607 | A brokered email matching a username shadows that user and locks them out | 5.3 | None |
The scores come from the CVE records in the CVE Program’s public list. The sections below group them by the part of your deployment they touch, because that is also how the re-testing work groups.
Unauthenticated denial of service: CVE-2026-79651 and CVE-2026-18212
Both of these let anyone who can reach your Keycloak hostname run it out of memory, which makes them the most urgent pair for internet-facing deployments.
CVE-2026-79651 is in the theme localization endpoints. They accepted any locale tag a client sent and cached a copy of the messages for each distinct tag with no upper bound, so a stream of made-up locales grows the heap until the JVM fails. We covered it in detail, including a reverse proxy rule that filters locales until you patch, in our CVE-2026-79651 write-up.
CVE-2026-18212 is in the SAML Redirect binding. The CVE record says the custom DEFLATE compression and decompression helpers “fail to release native zlib memory after use”, so repeated malformed SAML requests exhaust native memory, meaning memory outside the Java heap, which heap limits and heap dashboards do not show. The fix, in DeflateUtil, releases that state after each use. If you do not use SAML at all, blocking the /realms/{realm}/protocol/saml path at your proxy is a reasonable interim control. That rule does not cover SAML identity brokering, whose endpoint lives under /realms/{realm}/broker/{alias}/endpoint, so if you broker to a SAML identity provider you are using SAML and should patch. If you do, our Keycloak SAML security guide covers the wider hardening picture.
Authorization Services: CVE-2026-74909
CVE-2026-74909 exists because the fix for an earlier CVE, CVE-2026-15573, was incomplete. Keycloak’s policy enforcer, and the UMA permission endpoint, match an incoming request path against the resources you configured in Authorization Services. The CVE record explains that the matcher failed to normalize encoded characters such as semicolons or dot segments, so an authenticated user could make a request match “a less restrictive security policy than intended”. A typical case is a request that fails to match /api/admin and falls through to a permissive catch-all /* resource.
This one matters only if you use Authorization Services with path-based resources. It is also the source of the release’s breaking change, covered below. For background on how resources, scopes and policies fit together, see Keycloak Authorization Services policy types explained.
Admin boundaries: CVE-2026-17526
CVE-2026-17526 let a user holding the impersonation role impersonate a realm administrator and so inherit full control of the realm. It needs an existing privileged role, but impersonation is often granted to support staff precisely because they are not administrators. The fix refuses impersonation when the target holds admin roles the caller does not. Our CVE-2026-17526 brief walks through the patch, and secure user impersonation for support teams covers how to grant the role safely.
Brokered logins: CVE-2026-19607
CVE-2026-19607 is in the first broker login flow. If an external identity provider asserts an email that matches the username of an existing Keycloak user, Keycloak created a second account instead of detecting the duplicate, and that account’s email then shadows the original user’s username at login. It needs no credentials and applies to realms with identity brokering and login with email enabled. Our CVE-2026-19607 post explains who is exposed and includes a script to find the users at risk.
Stateless mode on MySQL and MariaDB: CVE-2026-90997
CVE-2026-90997 affects only deployments running the stateless feature, which arrived as a preview in Keycloak 26.7 for multi-cluster deployments, on MySQL or MariaDB. The CVE record describes “a mismatch in row-count semantics between the database driver and Keycloak’s application logic” that lets an attacker replay single-use artifacts such as JWT client assertions, DPoP proofs or TOTP codes. On MySQL and MariaDB, the fix replaces the upsert in the single-use object and revoked token stores with a delete of expired rows followed by a plain insert, so the returned row count reliably says whether the artifact was new. If you run stateless mode on PostgreSQL, or do not run it at all, this CVE does not apply. Our post on Keycloak 26.7 stateless mode covers what the feature does.
Which release lines carry the fixes?
Five of the six fixes were tagged on the 26.6 and 26.4 lines on 7 September 2026, nine days before 26.7.4 shipped, which confirms again that Keycloak patches older minor lines. We checked this against the commit history between consecutive tags in the Keycloak repository.
| Fix | 26.7.4 | 26.6.7 | 26.4.16 |
|---|---|---|---|
| CVE-2026-79651 locale cache DoS | Yes | Yes | Yes |
| CVE-2026-18212 SAML DEFLATE leak | Yes | Yes | Yes |
| CVE-2026-74909 policy enforcer normalization | Yes | Yes | Yes |
| CVE-2026-17526 impersonation of admins | Yes | Yes | Yes |
| CVE-2026-19607 brokered username collision | Yes | Yes | Yes |
| CVE-2026-90997 stateless replay on MySQL/MariaDB | Yes | Not needed | Not needed |
“Not needed” means the vulnerable code path does not exist on that line: the stateless feature is not defined in the 26.6.7 or 26.4.16 source. The 26.5 line received none of these fixes, since its last tag is 26.5.7, so if you run 26.5 or anything older than 26.4, upgrading to a fixed line is the fix.
One practical detail affects how you get those older-line fixes: the 26.6.7 and 26.4.16 tags exist in the Keycloak repository, but keycloak.org’s download list for those lines stops earlier, at 26.6.4 and 26.4.7 as of late September 2026, so a fix being tagged does not mean a download is published for your line. If you run community builds, 26.7.4 is the published release to move to. If you run a vendor build or build from a maintenance branch, check that channel for the matching patch, and if you use the Red Hat build of Keycloak, follow Red Hat’s advisories rather than mapping community version numbers yourself.
What breaks when I upgrade to 26.7.4?
The fix for CVE-2026-74909 changes how Authorization Services match request paths against resource URIs, and the Keycloak upgrading guide lists it as a breaking change for 26.7.4. According to that note, paths are now normalized before comparison, in five ways:
- Matrix parameters such as
;jsessionid=..., including the encoded%3Bform, are stripped. - Dot segments such as
/foo/../admin, including encoded forms like%2E%2E, are resolved. - Encoded slashes (
%2F) are decoded, and the duplicate slashes this creates are collapsed. - A trailing slash is stripped.
- The query string and fragment are dropped, so a resource for
/api/adminalso matches/api/admin?foo=bar.
If any of your resources rely on telling paths apart by those details, for example separate resources for /api/items and /api/items/, they now collapse into one, and whichever policy wins may change. Export your Authorization Services settings for each resource server and review path-based resources before you upgrade. Resources configured with a full absolute URI keep their scheme and host, and only the path part is normalized. The server-side fix is in PathMatcher, in the keycloak-common module. If your applications embed the Java policy enforcer, note that it ships separately, as keycloak-policy-enforcer from the keycloak-client repository, and it carries its own copy of PathMatcher in keycloak-client-common-synced. Upgrading the server does not patch that copy. As of 27 September 2026, the keycloak-client main branch (last changed on 2 September) still has the older PathMatcher, so watch the keycloak-client releases for one built against 26.7.4 or later.
Self-hosted patch checklist
Work through this in staging first, then production. The order puts the checks with the widest exposure first.
1. Confirm what you are running. Check the version in the admin console’s server info, or call GET /admin/serverinfo and read systemInfo.version. Note the release line, because it decides your target version from the table above.
2. Decide your target. For community builds, that is 26.7.4. If you are on 26.6 or 26.4 and your distribution channel provides 26.6.7 or 26.4.16, those carry the fixes that apply to your line. Our Keycloak upgrade strategy guide covers rolling upgrades and rollback planning.
3. Review Authorization Services resources. Do this before the upgrade, using the breaking-change list above. Skip it if you do not use Authorization Services.
4. Upgrade staging and re-test the fixed paths.
| Area | What to test | Expected after the upgrade |
|---|---|---|
| Brokered login | First login through an IdP whose email matches an existing user’s username | “Account already exists” page, no new user created |
| Impersonation | A support user with only impersonation tries to impersonate a realm admin |
Request refused |
| Policy enforcer | Protected paths with ;x=1, %2e%2e, a trailing slash or a query string |
Same decision as the plain path |
| Locale endpoints | Localized theme message requests with a stream of invented locale tags (staging only) | Responses fall back to the realm’s default locale, and heap stays flat |
| SAML | A normal SAML login, then a sustained run of Redirect-binding requests, including malformed ones, while watching process memory | Login works, and process memory stays flat |
| Stateless on MySQL/MariaDB | Replay a used client assertion or TOTP code | Replay rejected |
5. Watch memory after the rollout. The two denial-of-service fixes change memory behaviour, so compare heap and process memory against your pre-upgrade baseline for a few days. The SAML leak was in native memory, so watch the container’s total memory, not just JVM heap metrics.
6. Check for past abuse where it is cheap to do. Search user events of type IMPERSONATE, whose impersonator detail names the caller, for cases where a non-admin impersonated an admin account. Then search user events of type REGISTER with register_method set to broker for new accounts whose email matches another user’s username. The Keycloak auditing and event logging guide covers where those events live.
What does managed Keycloak cover here?
A managed service takes the patching off your plate, but not the realm-level review. Skycloak runs upstream Keycloak as identity management as a service, and applying releases like 26.7.4 to customer clusters is part of that service, along with watching memory after the rollout. The Authorization Services breaking change and the account audits are about your configuration and your users, so steps 3 and 6 still apply to a managed realm. If you are weighing whether to keep running this cycle yourself, is self-hosting Keycloak worth it in 2026 looks at the trade-off.
Frequently asked questions
How many CVEs does Keycloak 26.7.4 fix?
The release fixes six. The 26.7.4 release notes, published on 16 September 2026, list CVE-2026-90997, CVE-2026-79651, CVE-2026-74909, CVE-2026-19607, CVE-2026-17526 and CVE-2026-18212 under “Security fixes”. Their CVSS 3.1 base scores range from 5.3 to 8.1, and four of them need no authentication to exploit.
Do I have to move to 26.7 to get these fixes?
No. Five of the six fixes were tagged on the older lines as 26.6.7 and 26.4.16 on 7 September 2026, and the sixth only affects the stateless feature that exists in 26.7. Those two tags are not yet listed as downloads on keycloak.org, so community users may still find 26.7.4 the practical target.
Which 26.7.4 fix should I worry about most?
For an internet-facing deployment, the two unauthenticated denial-of-service bugs, CVE-2026-79651 and CVE-2026-18212, both scored 7.5, because anyone who can reach the hostname can use them. If you rely on Authorization Services path matching, CVE-2026-74909 is the highest score in the release at 8.1.
Is the Authorization Services change in 26.7.4 safe to roll out?
It usually is, but check your resources first. The upgrading guide lists URI normalization as a breaking change, so resources that differ only by a trailing slash, matrix parameters, dot segments or query string will now match the same requests. Review path-based resources in staging before production.
Is there a newer Keycloak security release after 26.7.4?
Not as of 27 September 2026, when 26.7.4 was still the newest tag. Several Keycloak CVEs have been published since, including CVE-2026-97177 on 24 September and CVE-2026-96448 on 25 September, and neither has a fixed release yet. Our posts on the FGAP password reset bypass and the FGAP composite role escalation cover the interim controls.
Sources
- Keycloak, “Keycloak 26.7.4” release notes, keycloak/keycloak on GitHub, 16 September 2026, retrieved 2026-09-27, https://github.com/keycloak/keycloak/releases/tag/26.7.4
- Keycloak, upgrading guide, “Migrating to 26.7.4” (
changes-26_7_4.adoc), keycloak/keycloak on GitHub, retrieved 2026-09-27, https://github.com/keycloak/keycloak/blob/main/docs/documentation/upgrading/topics/changes/changes-26_7_4.adoc - CVE Program, CVE records for CVE-2026-90997, CVE-2026-79651, CVE-2026-74909, CVE-2026-19607, CVE-2026-17526 and CVE-2026-18212, CNA records from Red Hat, published 16 September 2026 (CVE-2026-90997 on 17 September), retrieved 2026-09-27, https://www.cve.org/CVERecord?id=CVE-2026-74909 (record JSON for all six: https://github.com/CVEProject/cvelistV5/tree/main/cves/2026)
- Keycloak,
Profile.java(thestatelesspreview feature), keycloak/keycloak on GitHub, tag 26.7.4, retrieved 2026-09-27, https://github.com/keycloak/keycloak/blob/26.7.4/common/src/main/java/org/keycloak/common/Profile.java - Keycloak releases and tags 26.7.4, 26.6.7 and 26.4.16, commit history between consecutive tags, retrieved 2026-09-27, https://github.com/keycloak/keycloak/tags
- Keycloak client libraries,
PathMatcher.javainclient-common-syncedand thekeycloak-policy-enforcermodule, keycloak/keycloak-client on GitHub, main branch as of 2026-09-02, retrieved 2026-09-27, https://github.com/keycloak/keycloak-client - Keycloak website repository, published release list (
versions/keycloak), keycloak/keycloak-web on GitHub, retrieved 2026-09-27, https://github.com/keycloak/keycloak-web/tree/main/versions/keycloak