Keycloak 26.7.4: 6 CVEs, 5 rated CVSS 7+, and the end of the 26.6.2 CPU spikes

Sep 17, 2026 · Security · IDPTrust

Keycloak 26.7.4 was released on September 16, 2026. It fixes only 6 CVEs, compared with 20 in 26.7.3, but the smaller number is misleading: five of them score CVSS 7 or higher. The list includes an authorization bypass, two denial-of-service flaws that need no authentication, a flaw that lets attackers replay DPoP proofs, JWT assertions and TOTP codes, and an escalation that turns the impersonation role into full control of the realm.

The release also fixes the CPU busy-loop that has been hitting clusters since 26.6.2. Production reports about that bug have been piling up in the Keycloak tracker all summer.

This guide covers the 6 CVEs in Keycloak 26.7.4 ranked by severity, what to do until you can upgrade, and how to prioritize the upgrade.

Quick answer: what does Keycloak 26.7.4 fix?

Keycloak 26.7.4 fixes 6 CVEs, ships one enhancement (Quarkus 3.33.3.2) and resolves several bugs. The most severe issue is CVE-2026-74909 (CVSS 8.1). It is an incomplete fix for the PathMatcher bypass that 26.7.1 tried to close: an encoded semicolon (%3B) still tricks the policy enforcer. Next come two unauthenticated DoS flaws at CVSS 7.5 (an unbounded locale cache and a native memory leak in SAML), a replay protection bypass in stateless mode with MySQL/MariaDB (7.4) and realm administrator impersonation (7.2). Upgrade as soon as possible, especially if Keycloak is exposed to the internet, you use SAML, or your applications are protected by the policy enforcer.

CVEs fixed in Keycloak 26.7.4

CVE	CVSS	Severity	Component	Authentication?
CVE-2026-74909	8.1	High	Authorization Services (PathMatcher)	Yes (user)
CVE-2026-79651	7.5	High	Theme localization	No
CVE-2026-18212	7.5	High	SAML Redirect Binding	No
CVE-2026-90997	7.4	High	Stateless mode (MySQL/MariaDB)	No
CVE-2026-17526	7.2	High	Impersonation	Yes (`impersonation` role)
CVE-2026-19607	5.3	Medium	First broker login	No

Scores come from the Red Hat entries in NVD. For CVE-2026-90997, the score comes from GitHub advisory GHSA-xpwp-2pcm-8xq3. The release notes don't include scores. One caveat: the Keycloak issue labels CVE-2026-18212 as medium severity, even though its CVSS score is 7.5. As of September 17, CVE-2026-90997 is the only one of the six with a published GitHub advisory. With Keycloak 26.7.1, the advisories arrived a day after the release notes, so check the advisories page again over the next few days.

The most severe vulnerabilities in Keycloak 26.7.4

CVE-2026-74909 (CVSS 8.1): the PathMatcher bypass returns with an encoded semicolon

Keycloak 26.7.1 fixed CVE-2026-15573 (CVSS 8.1). The Authorization Services PathMatcher didn't normalize URIs, so adding a trailing slash or a matrix parameter (;foo) made the policy enforcer apply a less restrictive policy than intended.

That fix stripped matrix parameters, but only when the semicolon was a literal character. When it arrives percent-encoded as %3B, nothing gets stripped and the bypass works again. According to NVD, encoded directory traversal segments are also affected. An authenticated user can reach administrative or private endpoints of the protected application that their policy should block.

If your applications rely on the policy enforcer and you marked this issue as closed in August, reopen it. Upgrading the server is step one. If your applications embed the policy enforcer as a library, also check which version they ship, because path matching happens inside the application. In the meantime, rejecting paths that contain %3B, %2F or %2E%2E at your reverse proxy is a cheap compensating control.

CVE-2026-79651 and CVE-2026-18212 (CVSS 7.5): two ways to take Keycloak down without logging in

These are the two easiest flaws in this release to exploit. Both target public endpoints and require no credentials.

CVE-2026-79651: unbounded locale cache. The theme localization endpoints accept any locale tag sent in a request and store it in a permanent in-memory cache with no size limit. If an attacker sends thousands of unique tags, the heap grows until the process runs out of memory. A script running in a loop is enough.

CVE-2026-18212: native memory leak in SAML Redirect. The DEFLATE helpers in the SAML Redirect binding never call end() on their Deflater and Inflater instances. zlib allocates that memory outside the Java heap, so the garbage collector never frees it. Repeated malformed SAML requests make the process RSS grow until the OS or Kubernetes kills it.

This second flaw is hard to spot in operations. Your JVM heap metrics won't show it, because the heap stays flat while the container runs out of memory. If you've seen Keycloak pods restart with OOMKilled while the heap looked healthy, look into this. And even if none of your clients use SAML, the endpoint is still exposed in every realm.

Until you upgrade, rate-limit the SAML endpoint and the theme endpoints at the proxy, and monitor container memory as well as JVM memory.

CVE-2026-90997 (CVSS 7.4): DPoP, JWT assertion and TOTP replay in stateless mode

This flaw only affects deployments that run stateless mode on MySQL or MariaDB, and only versions 26.7.0 through 26.7.3. If that's your setup, this is your top priority.

Keycloak blocks reuse of single-use artifacts by recording each use in the database and checking how many rows changed. With its default settings, the MySQL/MariaDB driver reports a row as affected when it matched the row, even if nothing changed. Keycloak reads that as a first use and accepts every replay.

Affected artifacts:

Client JWT assertions (private_key_jwt), which grant access to the token endpoint as the client.
DPoP proofs, which protect nothing once they can be replayed.
Non-reusable TOTP codes, which work again for as long as they remain valid.

An attacker who intercepts one of these artifacts can replay it to get tokens or complete a login. Token revocation is not affected. According to the advisory, the workaround is to disable the stateless feature until you can upgrade.

CVE-2026-17526 (CVSS 7.2): the `impersonation` role can impersonate a realm administrator

The realm-management impersonation role is often given to support teams so they can see the application "as the user" and reproduce issues. Nobody treats it as an admin role, and that's the problem.

Up to 26.7.3, anyone with that role can impersonate a realm administrator and take full control of the realm: users, clients, roles and configuration. The score requires high privileges (PR:H), but in practice far more people hold this role than hold realm-admin.

Until you upgrade, review who has impersonation, whether directly or through groups and composite roles, and remove it from anyone who doesn't need it every day. Also check your admin events for impersonation of privileged accounts. We've seen this pattern before, where a role grants more than it appears to, in the admin console privilege escalation with FGAP v2.

Not sure who can impersonate whom in your realms? We audit Keycloak admin roles and permissions as part of our support services.

CVE-2026-19607 (CVSS 5.3): account lockout through a username collision in first broker login

In the first broker login flow, an attacker can register a username at an external identity provider that matches an existing Keycloak account. The resulting collision locks the legitimate user out of their account.

The attacker can't take over the account, but they can deny service to specific users. If you accept logins from social IdPs or from any provider where users choose their own username, review how your brokers map usernames. Building the username from the provider alias plus the external identifier prevents collisions with local accounts.

The 26.6.2 CPU spikes are finally fixed

Many teams will upgrade for this bug alone, whether or not the CVEs worry them.

Since 26.6.2, many clusters have shown the same pattern (issue #49635). A node runs normally, then at a random moment and under no unusual load, it gets stuck in a CPU busy-loop that lasts until the pod restarts. Reports range from 3-node clusters to 15-pod deployments serving hundreds of requests per second. The root cause is an HTTP streaming bug in Quarkus.

26.7.4 includes a targeted fix for the 26.6 and 26.7 branches, along with the upgrade to Quarkus 3.33.3.2. If you can't upgrade yet, the workaround confirmed by the community in the issue is to enable request buffering at the load balancer. In HAProxy, that's option http-buffer-request.

Don't confuse this bug with the Admin API regression introduced in 26.7.1, which scaled with the number of realms. That one was fixed in 26.7.3. If you run many realms on a single instance, both bugs affect you. We explain why realm count is an architectural decision in our realm strategy guide.

Other notable fixes in 26.7.4:

Oracle 19 with the full OCI driver failed to start from 26.6.0 onwards (SQLFeatureNotSupportedException on setNetworkTimeout) because of the new socket timeout on database connections.
The cached RealmAdapter.isUserManagedAccessAllowed() returned the value of isEnabled(). After a realm update, User-Managed Access could appear enabled when it wasn't, or the other way round.
The computed realm_client attribute was being persisted into client attributes on save through the Admin API.
The admin console threw an exception when you clicked a subgroup.

Which version are you on? The CVEs you're still exposed to

Keycloak only patches the latest minor, so each 26.7 release adds to the ones before it:

From 26.7.3: 6 CVEs, the ones in this release.
From 26.7.2: 26 CVEs, because 26.7.3 fixed 20, including two token exchange bypasses with the Google and Microsoft IdPs and missing hostname verification in LDAPS.
From 26.7.1: 34 CVEs. 26.7.2 added 8, including CVE-2026-18963 (CVSS 9.1), an unauthenticated account takeover through the reset-credentials flow.
From 26.7.0: 46 CVEs, including the two escalations to realm admin via Dynamic Client Registration (up to CVSS 8.8) fixed in 26.7.1.

Whichever version you're on, go straight to 26.7.4. You don't need to install the releases in between.

How to upgrade to Keycloak 26.7.4

Start with the official migration guide. From any 26.7.x version, this is a patch upgrade. From 26.6.x or earlier, you also take on the 26.7.0 migration.

A practical order of work:

Back up your database and confirm your rollback plan.
If you run stateless mode on MySQL/MariaDB and can't upgrade today, disable the stateless feature as a temporary measure.
Review who has the impersonation role in each realm and remove it wherever it isn't essential. Search admin events for impersonation of privileged accounts.
Upgrade a non-production environment first and test federated login, SAML and every application protected by the policy enforcer end to end.
If your applications embed the policy enforcer, check that library's version too.
After the upgrade, monitor CPU and container memory (not just the heap) on every node. If the 26.6.2 CPU loop was affecting you, you'll see the difference within hours.

Should you upgrade to Keycloak 26.7.4?

Yes, and don't leave it for next quarter's maintenance window. Five CVEs at CVSS 7 or above, two of them exploitable without credentials, justify an upgrade in the next few days.

Priority order:

Stateless mode on MySQL/MariaDB. CVE-2026-90997 defeats replay protection for DPoP, private_key_jwt and TOTP. Upgrade or disable the stateless feature today.
Keycloak exposed to the internet. CVE-2026-79651 and CVE-2026-18212 let anyone take your nodes down. Rate-limit at the proxy while you upgrade.
Applications protected by the policy enforcer. CVE-2026-74909 reopens a CVSS 8.1 authorization bypass you thought was closed.
The impersonation role spread across support teams. CVE-2026-17526 turns that role into full realm administration.
Still on 26.7.0, 26.7.1 or 26.7.2. You're exposed to between 26 and 46 CVEs, including a CVSS 9.1 unauthenticated account takeover.
Nodes with unexplained CPU spikes since 26.6.2. It's not a CVE, but you're paying for it in infrastructure costs and incidents.

Keycloak 26.7.4 FAQ

How many CVEs does Keycloak 26.7.4 fix?

Keycloak 26.7.4 fixes 6 CVEs: CVE-2026-74909, CVE-2026-79651, CVE-2026-18212, CVE-2026-90997, CVE-2026-17526 and CVE-2026-19607. Five of them score CVSS 7.0 or higher.

What is the most severe vulnerability in Keycloak 26.7.4?

CVE-2026-74909 (CVSS 8.1), an incomplete fix for the PathMatcher bypass (CVE-2026-15573, fixed in 26.7.1). A semicolon encoded as %3B skips matrix parameter stripping and lets an authenticated user get around Authorization Services policy enforcer rules.

Does Keycloak 26.7.4 fix any vulnerabilities that don't require authentication?

Yes. CVE-2026-79651 (unbounded locale cache) and CVE-2026-18212 (native memory leak in SAML Redirect) allow denial of service without credentials, and both score CVSS 7.5. CVE-2026-90997 also requires no authentication, but the attacker first has to intercept a single-use artifact, and it only affects stateless mode on MySQL or MariaDB.

Does Keycloak 26.7.4 fix the high CPU problem from 26.6.2?

Yes. 26.7.4 includes a targeted fix for the CPU busy-loop in issue #49635, which has been present since 26.6.2 and is caused by a Quarkus HTTP streaming bug. The release also upgrades to Quarkus 3.33.3.2. If you can't upgrade yet, enabling request buffering at the load balancer (option http-buffer-request in HAProxy) avoids the problem.

Full release notes: keycloak.org/2026/09/keycloak-2674-released

Security advisories: github.com/keycloak/keycloak/security/advisories

Get help with this upgrade

This release brings six CVEs, two of them exploitable by anyone on the internet, a support role that turns out to grant admin access, and a CPU bug that has been in production for months. And this is only the fourth patch release on the 26.7 branch. Keeping Keycloak up to date is no longer a once-a-year task.

At IDPTrust we run Keycloak in production every day. We assess how each release affects your configuration, put compensating controls in place until your maintenance window, plan the upgrade with a rollback path and stay with you through the cutover.

Talk to our Keycloak support team and stop chasing every release.