Keycloak Security Update: Upgrade to 26.7.5 or Later

Keycloak 26.7.4 and 26.7.5 close a series of vulnerabilities, including a privilege escalation via the impersonation role. Target: 26.7.5 or later.

The Keycloak project has published two maintenance releases with security fixes in quick succession. 26.7.4 (16 September) closes the six flaws described here, 26.7.5 (30 September) further ones: its release notes list 14 security fixes, four of them in dependencies. On 1 October, 26.8.0 followed as well. The target for operators is therefore 26.7.5 or later. One of the flaws from 26.7.4 allows an account with restricted administrative rights to pose as a realm administrator.

This article is aimed at organisations that run Keycloak themselves – as the central login for employees, for customer portals or for line-of-business applications. It assesses the six vulnerabilities from 26.7.4 and describes what to do before and after the update.

Why an identity provider deserves special attention

An identity provider (IdP) is not one service among many. It issues the tokens that all connected applications trust. Whoever controls the IdP does not need to attack any application individually: they can log in to any of them as whoever they like, and they can alter logins in a way nobody notices.

In security architectures, such a system is therefore assigned to the highest protection level. Microsoft, for example, places central identity systems in its enterprise access model in the control plane, which emerged from the former “Tier 0”. An IdP is thus comparably critical to domain controllers. Three practical rules follow from this: updates are not postponed there, administrative rights are granted especially sparingly there, and management access is not reachable from the internet there. A vulnerability that would “only” be a privilege escalation in a line-of-business application is, in the IdP, a privilege escalation for everything that depends on it.

The six vulnerabilities from 26.7.4

The ratings come from the project’s issues and the GitHub Advisory Database.

CVE-2026-17526 – privilege escalation via the impersonation role (high, CVSS 7.2). A user with the “impersonation” role can impersonate a realm administrator and, according to the description in the advisory, thereby gains full administrative control over the realm – including the management of users, clients and roles. This is the flaw with the greatest leverage, because it turns a deliberately restricted role into an unrestricted one.

CVE-2026-74909 – bypass of the policy enforcer (high, CVSS 8.1). The policy enforcer does not correctly normalise paths with certain encoded characters, such as a percent-encoded semicolon. A logged-in user can thereby trigger a less strict policy than intended and access protected endpoints. The project explicitly describes the correction as a follow-up to an incomplete earlier fix. This is relevant for applications that enforce their access rules via the Keycloak policy enforcer.

CVE-2026-90997 – reuse of one-time artefacts (high). Affected is the stateless operating mode with MySQL or MariaDB. Because of a different way of counting affected database rows, the replay protection does not recognise artefacts that have already been used. JWT client assertions, DPoP proofs and non-reusable TOTP codes are named: anyone who intercepts such an artefact can reuse it at the token endpoint or in the login flow. According to the issue, token revocation is not affected.

CVE-2026-79651 – denial of service via language tags (high, CVSS 7.5). The localisation endpoints take arbitrary language tags from unauthenticated requests into an unbounded in-memory cache. Many different tags are enough to crash the server.

CVE-2026-18212 – memory leak in the SAML redirect binding (CVSS 7.5 in the GitHub Advisory Database, marked as “medium” in the project issue). Native memory is not released when processing SAML requests. Repeated malformed requests without authentication exhaust the memory until the operating system terminates the process.

CVE-2026-19607 – account lockout via username collision (medium, CVSS 5.3). In the first-login flow via an external identity provider, an attacker can register a matching username with the external provider and thereby trigger a collision that locks out the legitimate user. This is relevant for all realms in which users log in via an external identity provider – for example via a federation with a partner or a social login.

Two of the six flaws can be exploited without authentication to crash the service. For a central login service, an outage is no side issue either: if the IdP is down, everything that depends on it is down.

What to do now

  • Upgrade to 26.7.5 or later. Before the update, the project refers to the migration guide with the complete list of changes. Read it before the update, not afterwards, and test the update on a staging instance with a realistic configuration – especially identity provider connections, SAML clients and custom themes.
  • Determine your version. The release notes name no affected version ranges. So assume that any version before 26.7.4 may be affected, and check for the 26.4 and 26.6 lines whether the vendor provides fixed releases.
  • Review the impersonation role, and do so before the update. The “impersonation” role is a client role of the built-in “realm-management” client in every realm; for cross-realm administration, there are corresponding roles on the <Realm-Name>-realm clients in the master realm. Establish which users, groups and composite roles contain it directly or indirectly. The documentation names support as the typical purpose: reproducing a problem from the affected user’s point of view. So review helpdesk and support accounts in particular. In affected versions, every account with this role could make itself realm administrator.
  • Look for traces. In impersonated sessions, Keycloak records the ID and username of the impersonating account as a session note. Insofar as you log admin events and login events, check whether administrator accounts were impersonated and whether roles, clients or identity provider settings were changed in that context.
  • Keep the role scarce afterwards. Even after the update: whoever may impersonate may log in as another person. Grant the role only where it is needed, and use the fine-grained admin permissions to rule out impersonating administrators altogether.
  • Check database and operating mode. If you run the stateless mode with MySQL or MariaDB, CVE-2026-90997 affects you directly.

Plan the update without postponing it

An IdP update affects every login, and that is exactly why it tends to be postponed. The project’s upgrading guide sets the guardrails. From Keycloak 26.6.0, rolling updates are supported for patch releases; whether they are possible in your environment is described in the guide on rolling updates. Anyone already on 26.7 may be able to update within this line without interruption; the move from 26.6 to 26.7 is a minor upgrade and, according to the upgrading guide, requires a stop.

The guide also states that the server is updated first and the adapters afterwards. Before every update, the guide requires a backup of the installation – configuration, themes – and of the database. The background matters for fallback planning: Keycloak does not support rolling back database changes. Anyone who has to go back restores the old installation and the database from the backup. This backup is therefore not an extra but the only way back. Create it before you start, and check that it can be restored.

Administration does not belong on the internet

The privilege escalation requires an account with administrative rights. The fewer such accounts there are and the fewer paths lead to the administration console, the smaller the attack surface – not only for this flaw, but for the next one. The login pages must be reachable; the administration console, as a rule, need not be. Administrative accounts belong behind multi-factor authentication, and their assignment belongs in a regular recertification.

How sector7 supports you

We support you with role and permission concepts, the management of privileged accounts and secure login processes with multi-factor authentication. This includes recurring vulnerability scans with prioritised remediation through patch management. More under cyber security.

Sources

Let's talk about your situation.