Keycloak Latest Version: 26.8.1 (13 Oct 2026) and History

The latest version of Keycloak is 26.8.1, released on 13 October 2026. It is the first patch of the 26.8 line, which began with 26.8.0 on 1 October 2026, and 26.8.x is the only line that still receives fixes (GitHub releases, Keycloak 26.8.1 announcement). Keycloak plans four minor releases a year, roughly one a quarter, with patch releases in between, and when a new minor ships the previous one stops being supported (release strategy, endoflife.date).

If you run Keycloak yourself, that last sentence is the one that shapes your year: there is no long-term support branch, so staying on a supported version means taking a minor upgrade about every three months. This post gives you the current version, the full history back to 24.0 with what each release changed, how to check which version you run, how long a version is supported, and how to upgrade from one minor to the next.

Version facts in this post were last verified on 18 October 2026. We review the post at every new Keycloak minor release, and update the version, dates and history table when a new minor or patch ships.

What is the latest version of Keycloak?

Keycloak 26.8.1 is the current release. The project tagged it on 13 October 2026, twelve days after 26.8.0, and the announcement lists 22 security fixes, 15 weaknesses and 23 bugs, across authentication, identity brokering and fine-grained admin permissions (Keycloak 26.8.1 released). The downloads page offers 26.8.1 (keycloak.org/downloads).

The feature content of the line arrived with 26.8.0 on 1 October 2026. The project’s own highlights for that release are issuing and verifying digital wallet credentials with OID4VCI and OID4VP, the SCIM API, multi-cluster deployments in stateless mode without an external cache, automatic index creation with what the announcement calls reduced memory usage, and delegated token exchange, which lets AI agents and automation act for a user with that user’s consent (Keycloak 26.8.0 released).

Three of those names are acronyms worth unpacking. OID4VCI, OpenID for Verifiable Credential Issuance, is a specification that defines an API for issuing verifiable credentials, and OID4VP, OpenID for Verifiable Presentations, defines a protocol for requesting and presenting those credentials. SCIM, the System for Cross-domain Identity Management (RFC 7644), is an HTTP-based protocol for managing identities across systems, which is what lets other software provision users into Keycloak.

We cover three of the 26.8 changes in separate posts: the 26.8 SCIM API, token exchange delegation in 26.8 and client secret rotation in 26.8. For provisioning on Skycloak itself, see the SCIM feature page.

If Keycloak itself is new to you, start with What is Keycloak? and come back here when you need version specifics.

Keycloak version history from 24.0 to 26.8

The table lists every minor release since early 2024 with its tag date and the changes that defined it. Dates come from the project’s GitHub releases and the endoflife.date Keycloak page, and the highlights come from the official release notes.

Two patterns in that table help with planning. The first is that many features move through experimental and preview labels before they are supported, and the release notes mark each stage: Organizations was a technology preview in 25.0 and fully supported from 26.0, and the SCIM API was a preview in 26.7 and promoted to supported in 26.8 (release notes). The project’s release strategy says: “Preview features or preview APIs, as well as non-public APIs may change at any time” (Keycloak release updates), so a preview label tells you a feature is in progress, not when it will be supported or what it will look like then.

The second pattern is how much of the recent work is standards work. Token exchange under RFC 8693, JWT authorization grants under RFC 7523, FAPI 2, DPoP, OpenID4VCI and now OID4VP all landed within about two years. Minor releases since 26.0 are also meant to be safe to take: the project’s release strategy says that “when a minor comes with breaking changes, such changes will be opt-in”, driven by versioned features whose default cannot change inside a minor (Keycloak release updates, October 2024). That guarantee has two limits. The same post says backwards compatibility “will only be given to Features and APIs that are fully supported”, so anything in preview can change between minors, and the upgrading guide says that “in minor or patch releases, Keycloak will only introduce breaking changes to fix bugs”, which means a security fix can still change behavior you rely on (upgrading guide). The 26.8.0 list of breaking changes shows what that looks like: callers with only the view-clients permission now see a masked placeholder instead of the client secret, disabled clients are no longer added to a token’s audience, and identity provider mappers no longer grant administrative roles unless the provider’s allowAdminRoleMapping setting is turned on (26.8.0 migration changes).

What changed in the 26.7 patches and in 26.8.1?

The 26.7 line had five patch releases in under three months: 26.7.1 on 5 August, 26.7.2 on 19 August, 26.7.3 on 31 August, 26.7.4 on 16 September and 26.7.5 on 30 September 2026. The 26.7.3 announcement alone lists 20 security fixes, including CVE-2026-35563, where the LDAP client did not verify that the server certificate matched the intended LDAP hostname, CVE-2026-16093, where the required signed-JWT assertion policy could be bypassed with unsigned assertion headers, and CVE-2026-18209, where a redirect URI parameter check inspected only the query string and not the URL fragment (Keycloak 26.7.3 released). The next patch in that line has its own post, Keycloak 26.7.4 Security Fixes: A Self-Hosted Patch Checklist.

The 26.8.1 patch lists 22 security fixes (Keycloak 26.8.1 released), and several of them change behavior you may depend on. The upgrading guide’s 26.8.1 breaking changes say that when StartTLS is enabled for a realm’s SMTP server, Keycloak now requires the StartTLS upgrade to succeed before it sends credentials, and fails the email rather than falling back to plaintext (CVE-2026-107121); that Keycloak now always validates the signature of backchannel logout tokens from an external OIDC provider, which closes the forged unsigned (alg=none) tokens of CVE-2026-18569; that CRL files for X.509 authentication can only be loaded from inside the conf directory; and that a masked identity provider client secret must be re-entered when the token URL or client ID of that provider changes (CVE-2026-15943) (26.8.1 migration changes). Three of the 26.8.1 fixes have their own posts: CVE-2026-107121: Keycloak SMTP StartTLS Plaintext Downgrade, Keycloak CVE-2026-103884: X.509 CRL Path Traversal and the Keycloak 26.8.1 SAML logout fix.

How often does Keycloak release a new version?

Four minors a year is the stated plan. Since October 2024 the project has committed to “4 minor releases every year, and a major release every 2-3 years” (Keycloak release updates), and the recent minors have landed close to that schedule: 26.4 on 30 September 2025, 26.5 on 6 January 2026, 26.6 on 8 April, 26.7 on 9 July and 26.8 on 1 October 2026. Between minors come patch releases: the 26.5, 26.6 and 26.7 lines received seven, four and five patches respectively before the next minor replaced them (GitHub releases, endoflife.date).

Plan for one minor upgrade a quarter and several patches in between. Since 26.6, patch releases inside the same minor can be applied as rolling updates without downtime, which takes most of the pain out of the patches, while minor upgrades still need the full shutdown procedure described below.

How long is each Keycloak version supported?

Until the next minor ships. The project’s security policy says a vulnerability “may be fixed in the current major.minor release of Keycloak, or for lower severity vulnerabilities or hardening in the following major.minor release” (SECURITY.md). There is no community long-term support branch, and endoflife.date records 26.7 support as ended on 1 October 2026, the day 26.8.0 was tagged, with 26.7.5 the day before as its final patch (endoflife.date).

This is the part of self-hosting that surprises teams. Depending on its severity, a vulnerability found now may be fixed in the current release, 26.8.x, or, for lower severity issues and hardening, in the following release, and endoflife.date lists 26.6 and 26.7 as no longer supported (endoflife.date). So if you are still on 26.6 the fix is a minor upgrade away rather than a drop-in patch, and a minor upgrade comes with migration notes to read and configuration changes to absorb. Budgeting engineering time for quarterly upgrades is part of the honest cost of self-hosting Keycloak.

If you need a guaranteed support window, that is what Red Hat sells. Red Hat build of Keycloak gives its 26.x line a support life cycle of at least two years and 27.x and later at least three. Its minor versions are based on the even-numbered community minors (26.0, 26.2, 26.4 and so on), skipping the odd-numbered ones, and each minor receives patches until the second following minor, which Red Hat describes as roughly twelve months (Red Hat build of Keycloak life cycle).

How do I check which Keycloak version I am running?

You have three quick options:

1. The command line. From the Keycloak installation directory, run the version flag, which the kc.sh command defines as “Show version information” and which prints a first line of the form Keycloak 26.8.1 (kc.sh source):

   bin/kc.sh --version

2. The Admin Console. In the master realm, open the Dashboard and switch to the Server Info tab, the tab the server administration guide uses to check what the running server has enabled (server administration guide).

3. The container tag. The container guide builds on the image at quay.io/keycloak/keycloak (running Keycloak in a container), and the current releases there carry a full tag such as 26.8.1, a minor tag such as 26.8, and a latest tag (Quay tags). If your deployment pins a full tag, that tag names the release you run. If it uses 26.8 or latest, the tag is not tied to one patch release, so run the version command inside the container to be sure.

Pinning matters more with Keycloak than with most software, because an upgrade is supposed to follow the review-then-shutdown procedure below. A surprise minor upgrade because latest moved under you is the failure mode to avoid. Our Docker Compose generator outputs a pinned version with a working database configuration if you are putting a stack together.

How do I upgrade Keycloak from one minor to the next?

The official upgrading guide prescribes a fixed order: review the migration changes from your current version, upgrade the server, upgrade the adapters, then upgrade the client libraries, which are released separately and are normally compatible with the latest server. The order matters because the migration changes for a release can include configuration you have to adjust, and finding that out from a crash loop is no fun.

Before you touch the server, the guide’s preparation steps are:

1. Shut Keycloak down if no rolling update is supported, which the guide gives as the case “if you perform a minor or major upgrade”. The database migration section repeats this: “Before you migrate the database, shut down all Keycloak nodes running the old version of Keycloak” (upgrading guide).
2. Back up the old installation, meaning configuration, themes and any providers you added.
3. Back up the database. The guide warns that the schema “will no longer be compatible with the old server after the upgrade” and that Keycloak does not support rolling the database changes back, so to roll back you “first restore the old installation, and then restore the database from the backup copy” (upgrading guide). For the backup itself, see Keycloak Backup and Restore: A Practical Guide.
4. Read the migration changes for every version between yours and the target. The guide lists them per release, and you own every list you skip over.

By default the database is migrated automatically when you start the new installation for the first time, and the transaction timeout used for schema migration defaults to 30 minutes (migrating the database). Two details are worth knowing. When a table has more than 300,000 entries, the automatic migration skips creating a new index on it by default and logs the SQL statement to apply after startup instead, and in 26.8 Keycloak creates those skipped indexes in the background after startup on databases that support non-blocking index creation: PostgreSQL, Oracle, MySQL and MariaDB, and the Enterprise, Developer and Azure SQL editions of Microsoft SQL Server (upgrading guide). And if your database team wants to review changes first, with --migration-strategy=manual the server writes the required changes to a keycloak-database-update.sql file in its working directory, for you to review and run against the database yourself (migrating the database).

Patch releases are the exception to the shutdown rule. The guide says that “starting with Keycloak 26.6.0 rolling updates of patch releases are supported”, and the kc.sh update-compatibility check command compares the metadata of your running configuration with the new one and tells you whether a rolling update is possible or a full recreate is needed (rolling updates guide). Enable sticky sessions on your load balancer during the roll so users do not bounce between versions.

For version-specific detail, these posts each cover one release or feature:

• Keycloak 26.0.0: what’s new and key migration steps, on the move to the 26 line.
• Keycloak Workflows in 26.6 and later, on the workflows feature.
• Keycloak 26.7 stateless mode, on stateless mode for multi-cluster deployments.
• Keycloak 26.7.4 security fixes patch checklist, on applying a patch release to a self-hosted cluster.
• Migrating Keycloak from WildFly to Quarkus, if you are still on a release older than 17 and need to cross that boundary first.

Some changes land at the network edge: the hostname v1 options, deprecated in 25 and replaced by hostname v2, were removed in 26.0 (release notes). Our posts on running Keycloak behind a reverse proxy and on strategies to upgrade a Keycloak cluster go with this section.

How does Skycloak handle Keycloak versions?

On Skycloak Dedicated, our managed Keycloak, you pick the Keycloak version when you create a cluster (cluster documentation). To change it later, the Keycloak Version section of the cluster’s Edit page lays the available versions out on a visual timeline, with a Current badge on yours and an Upgrade button on the next one (version upgrades). Skycloak enforces sequential upgrades, one version at a time, which the documentation describes as safer and more predictable when releases carry database schema migrations; moving to a lower version is not possible, because of database schema compatibility; and a major version upgrade such as 25.x to 26.x shows a warning and needs you to confirm it with a checkbox (version upgrade notes).

If you would rather not schedule the quarterly upgrade yourself, you can enable auto-upgrade on the Edit page: patch and minor versions are then applied automatically when there are no breaking changes, always inside the cluster’s maintenance window, while major upgrades still ask for your confirmation. For those automatic updates, Skycloak updates the instances one by one, so that sign-ins remain available (auto-upgrade and maintenance windows). The cluster’s Overview page also shows a timeline of past upgrades, with each version transition, its status and its timestamps (upgrade history). Version upgrades are one of the things managed Keycloak hosting exists to take off your plate.

Frequently asked questions

What is the latest version of Keycloak?

Keycloak 26.8.1, released on 13 October 2026. It is a security and bug fix patch for the 26.8 line, which started with 26.8.0 on 1 October 2026 and made the SCIM API, stateless multi-cluster and client secret rotation supported features.

Is there a Keycloak LTS version?

No. The community project fixes vulnerabilities in the current minor, or in the following one for lower-severity issues, and older minors stop receiving patches when a new minor ships. The closest thing to an LTS is the commercial Red Hat build of Keycloak, which supports the 26.x line for at least two years and tracks the even-numbered community minors.

How do I check which Keycloak version I am running?

Run bin/kc.sh --version from the installation directory, or open the Server Info tab on the master realm’s Dashboard in the Admin Console. In a container, a pinned image tag such as 26.8.1 names the release; a floating tag such as 26.8 or latest does not, so run the version command inside the container.

Can I skip versions when upgrading Keycloak?

The upstream upgrading guide gives one procedure: review the migration changes, shut down, back up, and start the new version, which migrates the database on its first start (upgrading guide). The guide lists migration changes per release, so read the list for every version between yours and the target. On Skycloak, upgrades are sequential only, one version at a time (version upgrade notes).

Can I upgrade Keycloak without downtime?

For patch releases within the same minor, yes, since 26.6.0: the rolling updates guide and the update-compatibility check command confirm whether your change qualifies. For minor and major upgrades, no: the guide requires all old-version nodes to be shut down before the database migrates.

What is the difference between Keycloak and Red Hat build of Keycloak versions?

Red Hat build of Keycloak is Red Hat’s commercially supported build of Keycloak. Its minors are based on the even-numbered community minors, each minor is patched until the second following minor (about twelve months), and the 26.x line carries a minimum two-year life cycle. Community Keycloak patches only the current minor.

What to do next

Check which minor your cluster runs, using the command, the Admin Console or your image tag. If it is anything other than 26.8.x, it is no longer receiving fixes, so read the migration changes between your version and 26.8.1, take a database backup you have tested restoring, and move one minor at a time using the per-version guides above. If you would rather not run identity upgrades at all, try Skycloak free: it runs real upstream Keycloak and takes the upgrades off your team.

Sources

• Keycloak, GitHub releases, https://github.com/keycloak/keycloak/releases
• Keycloak, “Keycloak 26.8.1 released”, 13 October 2026, https://www.keycloak.org/2026/10/keycloak-2681-released
• Keycloak, “Keycloak 26.8.0 released”, 1 October 2026, https://www.keycloak.org/2026/10/keycloak-2680-released
• Keycloak, “Keycloak 26.7.3 released”, 31 August 2026, https://www.keycloak.org/2026/08/keycloak-2673-released
• Keycloak, “Keycloak 26.7.0 released”, 9 July 2026, https://www.keycloak.org/2026/07/keycloak-2670-released
• Keycloak, Release notes, https://www.keycloak.org/docs/latest/release_notes/index.html
• Keycloak, Upgrading guide (preparing for an upgrade, migrating the database, migration changes for 26.8.0 and 26.8.1), https://www.keycloak.org/docs/latest/upgrading/index.html
• Keycloak, “Checking if rolling updates are possible”, https://www.keycloak.org/server/update-compatibility
• Keycloak, Downloads, https://www.keycloak.org/downloads
• Keycloak, “Keycloak release updates”, October 2024, https://www.keycloak.org/2024/10/release-updates
• Keycloak, Security policy, https://github.com/keycloak/keycloak/blob/main/SECURITY.md
• Quay, keycloak/keycloak image tags, https://quay.io/repository/keycloak/keycloak?tab=tags
• endoflife.date, Keycloak, https://endoflife.date/keycloak
• Red Hat, “Red Hat build of Keycloak Life Cycle and Support Policies”, https://access.redhat.com/node/7092877
• Skycloak, Cluster documentation, https://skycloak.io/docs/features/clusters/
• Keycloak, kc.sh command definition (Main.java), https://github.com/keycloak/keycloak/blob/main/quarkus/runtime/src/main/java/org/keycloak/quarkus/runtime/cli/command/Main.java
• Keycloak, “Running Keycloak in a container”, https://www.keycloak.org/server/containers
• Keycloak, Server Administration Guide, https://www.keycloak.org/docs/latest/server_admin/index.html
• OpenID Foundation, “OpenID for Verifiable Credential Issuance”, https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html
• OpenID Foundation, “OpenID for Verifiable Presentations”, https://openid.net/specs/openid-4-verifiable-presentations-1_0.html
• IETF, RFC 7644, “System for Cross-domain Identity Management: Protocol”, https://www.rfc-editor.org/rfc/rfc7644
• IETF, RFC 8693, “OAuth 2.0 Token Exchange”, https://www.rfc-editor.org/rfc/rfc8693
• IETF, RFC 7523, “JSON Web Token (JWT) Profile for OAuth 2.0 Client Authentication and Authorization Grants”, https://www.rfc-editor.org/rfc/rfc7523