Three weeks ago this site covered Keycloak 26.7 as the identity layer community infrastructure was missing — SCIM provisioning, Shared Signals Framework, AuthZen, MCP authorization. The feature post ended with a recommendation to deploy it.

Now patch it.

Keycloak 26.7.2, released August 19, 2026, fixes nine security vulnerabilities. Two of them enable unauthenticated account takeover. The most severe is CVE-2026-18963, CVSS 9.1. Red Hat rates it Critical. It requires no authentication, no user interaction, and is remotely exploitable.

The Vulnerability

CVE-2026-18963 is in Keycloak's reset-credentials authentication flow. The password recovery process is supposed to work like this:

  1. User requests password reset.
  2. Keycloak generates recovery state and sends a verification link by email.
  3. User clicks the link, proving control of the email address.
  4. Keycloak validates the recovery state.
  5. User sets a new password.

The vulnerability is in step 4. The code fails to properly verify that the state parameter remains consistent throughout the reset sequence. An attacker can craft requests that skip or spoof the state validation — jumping directly from "recovery initiated" to "set new password" without ever presenting the email verification proof.

No email access needed. No prior credentials needed. No user interaction needed. The attacker picks a target account — any account, including admin — and resets its password.

This is not a brute force issue. It's not a weak password issue. It's not a phishing issue. The security failure happens before the password itself matters. An organization could require 30-character passwords with mandatory WebAuthn and still be vulnerable — the attacker replaces the password through a broken recovery process that never checks whether the person requesting the reset actually owns the account.

Why MFA Doesn't Automatically Save You

A common assumption is that MFA protects against password-related account takeover. It doesn't protect against this.

The attacker isn't stealing a password. They're replacing it. If the recovery flow allows setting a new credential without verifying email ownership, the attacker sets a password they know. Whether the account had MFA configured before is irrelevant to the takeover vector — the vulnerability is in the reset flow's state machine, not in the authentication step that follows.

Keycloak's recovery flow may or may not require MFA re-enrollment after a password reset, depending on how the realm is configured. The point is that the vulnerability bypasses the verification gate that should precede any credential change. MFA is a factor in the authentication step. The bypass is in the recovery step. They're different stages.

The Other CVEs in 26.7.2

CVE-2026-18963 is the headline. The rest of the 26.7.2 security fixes matter too.

CVE-2026-15571 — Account takeover via account-linking. Predictable protection in the account-linking flow allows a malicious OIDC client to take over a user's account. This is the second account takeover vulnerability in the same release. An attacker registers a malicious OIDC client, tricks a user through the account-linking flow, and gains control of their account. CVSS has not been published in the sources I reviewed, but the impact is account takeover through a crafted client — not a trivial exploit, but not a theoretical one either.

CVE-2026-17048 — Vault-resolved rotated client secret disclosure. When Keycloak rotates a client secret that was resolved from a vault, the rotated secret can be disclosed. Client secrets are how applications authenticate to Keycloak. If those secrets leak, an attacker can impersonate the application in OAuth flows.

CVE-2026-15945 — FGAP group hierarchy authorization failure. Fine-Grained Admin Permissions (FGAP) are Keycloak's delegated administration model — you can let a user manage some groups without giving them realm admin. This CVE means the group hierarchy search under FGAP v2 can disclose information about groups the delegated admin shouldn't see. Not a takeover, but an information disclosure that breaks the trust model of delegated administration.

CVE-2026-14613 — FGAP role-group permission bypass. Another FGAP bypass — delegated admins can access role-group mappings they shouldn't. Same category: the permission boundaries that make delegated administration safe have holes.

CVE-2026-59888, CVE-2026-59889 — two additional CVEs referenced in the release without detailed public descriptions yet. Given the pattern, check the Keycloak advisory for full details.

The 26.6.4 Patch Before It

Keycloak 26.6.4, released earlier in August, fixed eight security issues. Several are worth attention even if you've already moved to 26.7.x:

CVE-2026-11800 — JWT algorithm confusion. Authentication bypass via forged tokens. JWT algorithm confusion attacks exploit servers that accept multiple signing algorithms — an attacker signs a token with a symmetric algorithm using the server's public key as the HMAC secret, and the server accepts it. This is a well-known class of attack and finding it in Keycloak is significant.

CVE-2026-9099 — Group admin to realm admin escalation. A delegated group administrator can escalate to realm administrator. This is the worst kind of FGAP failure — not information disclosure but privilege escalation to full administrative control.

CVE-2026-9795 — Improper scope mapping enforcement. Privilege escalation through scope mappings that aren't properly enforced.

CVE-2026-9705 — Disabled client reactivation. A disabled client can be reactivated using a Registration Access Token (RAT). Client takeover through a token that should have been invalidated when the client was disabled.

The pattern across both releases is consistent. The vulnerabilities cluster at trust boundaries — the points where Keycloak decides whether to trust a token, a session, a redirect URI, a client, a delegated admin, or an authentication state transition. These are the exact boundaries that make an identity provider valuable, and they're the boundaries where a failure is most expensive.

What This Means for Community Infrastructure

If you followed the recommendation in the Keycloak 26.7 post and deployed it, you need to be on 26.7.2. Not 26.7.0. Not 26.7.1. If you're on 26.6.x, you need 26.6.4 at minimum, and you should be planning the move to 26.7.2.

For a community deployment — fire hall, town office, small organization — Keycloak is the identity layer for everything. Nextcloud, Matrix, Gitea, any custom application. An account takeover in Keycloak is not a breach of one service. It's a breach of all services. An attacker who takes over an admin account in Keycloak gets admin access to every application that trusts it. The blast radius is the entire infrastructure.

The password reset bypass is particularly dangerous for community infrastructure because these deployments often have small user bases with predictable email addresses. A fire hall's admin account is likely admin@firehall.example or a named individual at a known domain. The attack doesn't require social engineering or network access — just knowledge of the target email and a vulnerable Keycloak instance.

What to Do

1. Upgrade to 26.7.2. This is the primary fix. Download from keycloak.org/downloads. If you're running the container image, pull quay.io/keycloak/keycloak:26.7.2. If you're running on Kubernetes with the Keycloak Operator, set the image tag and let the operator handle the rolling update — 26.6.0 introduced zero-downtime patch releases, so a 26.7.0 → 26.7.2 upgrade within the same minor stream should roll without service interruption.

2. Take a Proxmox snapshot first. Standard practice for any upgrade. If you're running Keycloak in an LXC container or VM on Proxmox, snapshot before upgrading. The upgrade is a patch release — it should be low-risk — but security patches sometimes change behavior in the recovery flow.

3. Check your reset-credentials flow. After upgrading, test the password reset flow end-to-end. Request a reset, verify that the email link works, verify that you cannot skip the verification step. If you customized the reset-credentials flow in your realm — added steps, removed steps, changed required actions — review those customizations against the patched flow.

4. Audit for signs of exploitation. CVE-2026-18963 doesn't require user interaction, so there may be no obvious indicators. But check:

  • Keycloak's events table for password reset events on accounts where the user didn't request one.
  • Admin events for credential changes you didn't authorize.
  • Login events from IPs or user agents that don't match the account owner's patterns.
  • Newly registered OIDC clients you didn't create (relevant to CVE-2026-15571).

If you find suspicious activity, the attacker may have already taken over accounts. Reset credentials for affected users, revoke active sessions, and check downstream applications for unauthorized access.

5. Review FGAP configurations. CVE-2026-15945 and CVE-2026-14613 both affect Fine-Grained Admin Permissions. If you use delegated administration — letting non-admin users manage specific groups — audit what those delegated admins could see or do while the vulnerabilities were present. The information disclosure may have exposed group membership or role assignments that were supposed to be restricted.

6. Check for JWT algorithm confusion exposure. CVE-2026-11800 (fixed in 26.6.4) allows token forgery. If you were running 26.6.0–26.6.3 and have clients that accept JWTs from Keycloak, an attacker may have forged tokens. Check application logs for tokens with unexpected algorithm headers (HS256 when RS256 was expected, for example).

The FOSS Security Model in Practice

This is what the FOSS security model looks like in practice, and it's worth saying plainly.

The vulnerability was found through code audit and reported through responsible disclosure. Red Hat and the Keycloak team issued a patch. The CVE is public. The CVSS vector is public. The affected versions are public. The fix is in a release that anyone can download, inspect, and deploy. The release notes list every CVE by number. The commits are in a public Git repository.

An organization running Keycloak can read the patch, understand exactly what was broken, verify that the fix addresses it, and confirm their deployment is no longer vulnerable. They can do this without trusting a vendor's assurance. They can inspect the code.

Compare this to a proprietary identity provider. When a proprietary IDP has a vulnerability, you find out when the vendor's security team decides to publish an advisory. The advisory may or may not describe the root cause. The patch is a binary you install and trust. You cannot inspect what changed. You cannot verify that the fix is complete. You cannot audit whether the vulnerability was exploited before the patch was available. The timeline from discovery to disclosure is controlled by the vendor's PR calculus, not by the community's need to know.

The CRA post on this site made the point that FOSS infrastructure is more auditable than proprietary infrastructure. This Keycloak patch is a concrete example. Nine CVEs, publicly documented, with fixes anyone can inspect. The same week, Microsoft published a blog post about "landmark" investments in Canadian sovereign cloud. Microsoft's security advisories do not list CVEs by number with CVSS vectors. They say "we've addressed an issue" and link to a KB article that says "this update addresses a vulnerability." Which model would you rather depend on for your community's identity layer?

The vulnerability is bad. The response is good. That's the FOSS security model working as intended.

The Broader Lesson

Two account takeover CVEs in one release. Eight more in the previous patch. A JWT forgery vulnerability. A delegated-admin escalation. This is not a sign that Keycloak is insecure. It's a sign that identity is hard, that trust boundaries are where the hardest bugs live, and that a mature FOSS project with active security research finds and fixes these issues in the open.

Every identity provider has these bugs. The question is which ones find them, fix them, and tell you about them. Keycloak does all three. A proprietary provider may do the first two. The third depends on their disclosure policy.

For community infrastructure operators: upgrade to 26.7.2, audit your flows, and take a snapshot before you start. The tools are the same ones we recommend everywhere. The practice is the same: know what you run, track vulnerabilities, patch promptly, verify the fix. The FOSS model gives you the tools to do all four. Use them.

Sources: Keycloak 26.7.2 release, NVD CVE-2026-18963, Red Hat security advisory, Keycloak GitHub releases, Penligent — Keycloak CVE analysis