CVE-2026-19607: Keycloak Username Takeover and Account Lockout

Last updated: September 2026

CVE-2026-19607 is a Keycloak bug in the first broker login flow, the step that runs the first time someone signs in through an external identity provider. If that provider asserts an email address that matches the username of an existing Keycloak user, Keycloak did not treat it as a duplicate and created a second account. Because login with email looks up email addresses before usernames, the new account then shadows the old one, and the real user can no longer sign in with their username. Red Hat published it on 16 September 2026 with a CVSS 3.1 base score of 5.3, and the fix shipped in Keycloak 26.7.4 the same day, with the same change tagged on the 26.6 and 26.4 lines as 26.6.7 and 26.4.16.

The upstream release notes call it “Username Takeover Leading to Account Lockout”. The word takeover is about the username, not the account: the attacker ends up owning the login name, not the victim’s data or sessions. That is why Red Hat scores it with no confidentiality or integrity impact and low availability impact. That score describes Keycloak itself, though. The attacker’s tokens now carry the victim’s login name as their email claim, so any application that identifies people by email deserves a look, as we explain below. It is still worth fixing promptly, because it needs no credentials and it lands on exactly the users whose accounts were set up in a slightly unusual way.

What does CVE-2026-19607 allow?

It allows someone who can sign in through one of your brokered identity providers, with an email address of their choosing, to lock a specific user out of username-based login. The CVE record Red Hat published on 16 September 2026 describes it as an attacker registering “a matching username on an external provider to trigger a collision in Keycloak, which results in the legitimate user being locked out of their account” (CVE Program, CVE-2026-19607 record, 2026).

The collision check that had a gap

When a brokered user signs in for the first time, the default first broker login flow runs an authenticator called Create User If Unique. Its job is to decide whether this person already has a Keycloak account. Before the fix, it asked two questions: does an existing user have the same email as the brokered email, and does an existing user have the same username as the brokered username? If neither matched, it created a new user.

The fix commit, written by Stan Silvert and merged on 4 September 2026, explains what those two questions miss. When the realm’s Login with email setting is on, “both values identify a user at login time, so that pair of comparisons leaves a gap: a brokered e-mail matching the username of an existing account is not recognized as a duplication” (keycloak/keycloak commit c8159693, 2026).

How the shadow account locks the real user out

Keycloak’s login lookup, KeycloakModelUtils.findUserByNameOrEmail, checks for an email match first whenever login with email is allowed and the input contains an @, and only falls back to a username match if no email matches. Here is the sequence that produces the lockout:

An existing user has the username [email protected], but their email attribute is a different address, or is empty.
Someone signs in through a brokered provider that asserts the email [email protected].
First broker login finds no user with that email, and the attacker’s username at the provider (for example a GitHub login or an Entra ID user principal name) matches no existing username either, so it creates a new account whose email is [email protected].
When the real user types [email protected] on the login page, Keycloak resolves it to the new account’s email before it ever checks usernames. Their password no longer matches, and the account they own is unreachable by its username.

The real user can still sign in with their actual email address, if they have one, because that resolves to their own account. In practice that is little comfort, because users who have always typed their username rarely know that the other address works, and the help desk usually sees it as a forgotten password. A password reset does not help either. The reset form looks the user up by username first, so a reset for [email protected] targets the real user’s account (and reaches them only if an email address is on file), but even after the password changes, the login form still resolves [email protected] to the shadow account.

Who is exposed to CVE-2026-19607?

You are exposed on a Keycloak version before the fix if identity brokering is enabled, Email as username is off, and some of your users have a username that looks like an email address but differs from their email attribute. Red Hat’s vector is CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L, classified CWE-287 Improper Authentication.

Brokering with the default first broker login flow. The flaw is in the Create User If Unique authenticator, which the built-in first broker login flow uses. Realms without any identity provider configured are not affected.

Login with email on and duplicate emails off. The added check in the fix only runs when Login with email is enabled and Duplicate emails is disabled on the realm’s login settings. Both are the defaults.

Users whose username and email differ. Accounts where the username is itself an email address, but not the one on file, are the targets. This happens more often than it sounds: users imported from an older system that used addresses as login names, people who changed their email but kept the old address as their username, and accounts created by an admin who typed an address into the username field. Realms with Email as username turned on were not exposed, because in that mode Keycloak uses the brokered email as the username it checks, so the existing username check already caught the collision. The gap only exists with Email as username off, which is the default.

An identity provider that will assert that address. The attacker needs an account at one of your brokered providers whose email is the victim’s username. Providers that verify email ownership make that hard, unless the address has been abandoned or its domain has lapsed. Providers that let users set any email, and customer-managed identity providers in a multi-tenant setup, make it easy. If you broker to tenant IdPs through Organizations, treat this as the likely path.

A brokered username that differs from that address. Before the fix, Keycloak already compared the brokered username with existing usernames. The OIDC broker falls back to the email as the username when a provider sends no preferred_username, so a plain Google broker, for example, hands Keycloak [email protected] as the username too, and the old check caught it. The gap opens with providers that send a separate username, such as Entra ID’s user principal name, GitHub logins, another Keycloak or a SAML NameID, and with any Username Template Importer mapper that rewrites the username.

The fix also adds the mirror-image check: a brokered username that contains an @ and matches an existing user’s email is now routed to the existing account as well.

How do I fix CVE-2026-19607?

Upgrade to a release that contains the fix. The published community release is 26.7.4, released on 16 September 2026 and listing CVE-2026-19607 under “Security fixes” in its release notes. The same change was cherry-picked onto the 26.6 and 26.4 maintenance lines, and is in the 26.6.7 and 26.4.16 tags from 7 September 2026.

Release line	First tag with the fix
26.7.x	26.7.4
26.6.x	26.6.7
26.4.x	26.4.16

The 26.5 line received no fix tag (its last release is 26.5.7), so 26.5 users should move to 26.7.4.

There is one caveat on the older lines. Keycloak does ship point releases on older minor versions, but those two tags do not yet have their own download pages on keycloak.org, whose release list for the 26.6 and 26.4 lines stops earlier (at 26.6.4 and 26.4.7 as of late September 2026). If you run community builds, 26.7.4 is the published version to move to. If you run a vendor build or track a maintenance branch, check that channel for the corresponding patch, and if you use the Red Hat build of Keycloak, follow Red Hat’s advisory.

After the upgrade, a brokered sign-in that collides with an existing username is sent to the “account already exists” page instead of creating a new user. From there the person has to prove they own the existing account, by re-authenticating or by email verification, before the two are linked. That is the same path a normal email collision already took.

What can I do before I upgrade?

Close the mismatch between usernames and emails, because that is the condition the attack depends on. You can find the affected users with the Admin REST API:

KC=https://auth.example.com
REALM=myrealm

curl -s -H "Authorization: Bearer $TOKEN" 
  "$KC/admin/realms/$REALM/users?briefRepresentation=true&first=0&max=1000" |
jq -r '.[] | select(.username | contains("@"))
            | select((.email // "" | ascii_downcase) != (.username | ascii_downcase))
            | "(.username)t(.email // "-")"'

Page through larger realms with first. Every user this prints is a potential target. For each one, either set the email attribute to match the username, if that address really belongs to them, or rename the username to something that is not an email address. Keycloak lowercases usernames and emails when it stores them, so the comparison above is case-insensitive to match. For users federated from LDAP or another user store, fix the mismatch at the source, since Keycloak will not let you rename them. Realms with Email as username on can skip this step.

If you run many realms or cannot change accounts quickly, prioritise the realms that broker to providers you do not control, because those are where an attacker can choose the asserted email most easily. Our explainer on shadow accounts in Keycloak brokering covers how brokered accounts relate to the local user store.

Check applications that key on email. The shadow account’s tokens carry the victim’s login name in the email claim, marked verified if the provider has Trust Email turned on. Any relying application, SCIM target or reporting system that matches people by email could link the attacker to the victim’s records there. Turning off Trust Email for providers that do not verify addresses does not stop the collision itself, but it limits what the shadow account’s email is worth downstream.

How do I tell if it has already happened?

Look for brokered registrations whose email matches another user’s username. When first broker login creates an account, Keycloak records a REGISTER user event with the details register_method set to broker, identity_provider set to the provider alias, and email set to the new user’s email. The event also carries username, the shadow account’s username, and identity_provider_identity, the attacker’s identity at the provider, both useful when you triage. Compare those emails against the list of usernames the script above produced.

A support pattern is the other signal. Users who suddenly report that their password stopped working, while the audit log shows no password change on their account, are worth checking for a second account holding their username as its email. Deleting the shadow account, after confirming nobody legitimate owns it, restores the original user’s access. For event storage and export, see our Keycloak auditing and event logging guide.

How is this different from other Keycloak lockout and account CVEs?

CVE-2026-19607 needs no credentials and changes nothing on the victim’s account, which separates it from most of this year’s account CVEs. CVE-2026-18963 was a genuine account takeover through password reset. CVE-2026-88770 was about the device flow ignoring a locked account, and CVE-2026-82968 was about social account linking. The lockout here is closer to the gaps we described in brute-force protection and IP-based limits: an availability problem that looks like user error from the help desk.

The fix commit notes that the user profile validators “already apply this cross check for self registration and profile updates”. In other words, self-registration was already guarded against this collision, and brokering was the one account-creation path that was not. When you review a realm, it is worth asking the same question of every path that creates users, including imports, SCIM provisioning and custom extensions, since each makes its own uniqueness decision.

CVE-2026-19607 is one of six security fixes in Keycloak 26.7.4. Our 26.7.4 patch checklist covers the full set and what to re-test, and the Keycloak security hardening checklist covers the broader baseline.

What does managed Keycloak change here?

On Skycloak, identity management as a service built on upstream Keycloak, we roll security releases like 26.7.4 onto customer clusters, so the fixed broker check is in place without you scheduling an upgrade. The data condition is yours to clean up either way: users whose username and email disagree were a latent problem before this CVE and remain one after it, so the audit above is worth running in a managed realm too.

Frequently asked questions

Is CVE-2026-19607 an account takeover?

Not in the usual sense of the phrase. The attacker gains an account whose email equals the victim’s username, which captures that login name, but they get no access to the victim’s Keycloak account, data or sessions. Applications that identify users by the email claim are the exception worth checking. Red Hat’s CVSS 3.1 vector sets confidentiality and integrity impact to None and availability to Low, for a base score of 5.3.

Which Keycloak versions fix CVE-2026-19607?

Keycloak 26.7.4, released on 16 September 2026, is the published community release with the fix. The same change is tagged on the older lines as 26.6.7 and 26.4.16, dated 7 September 2026. Versions before those on each line are affected when identity brokering and login with email are both in use.

Am I affected if I do not use identity providers?

No. The flaw is in the first broker login flow, which only runs when someone signs in through a configured identity provider such as Google, GitHub, Entra ID or a SAML IdP. A realm with no identity providers never runs that flow, so the collision cannot occur there.

It removes the condition, because the email-first lookup only happens when login with email is enabled, and the fix itself only adds its check in that case. It also changes the sign-in experience for every user who types an email address, so cleaning up mismatched usernames is usually the better short-term fix.

How do I restore a locked-out user?

Find the second account whose email equals the user’s username, confirm it was created by a brokered sign-in and is not a real person’s account, then delete it or change its email. The original user’s username then resolves to their own account again. Upgrade first so it cannot be recreated.

Sources

CVE Program, CVE-2026-19607, “Keycloak-services: keycloak-services: broker-originated username collision causes account lockout”, CNA record from Red Hat, reporter credited as Anurag Mondal (NetSPI), published 16 September 2026, retrieved 2026-09-27, https://www.cve.org/CVERecord?id=CVE-2026-19607 (record JSON: https://github.com/CVEProject/cvelistV5/blob/main/cves/2026/19xxx/CVE-2026-19607.json)
Keycloak, commit c8159693, “CVE-2026-19607 Detect brokered e-mail colliding with an existing username (26.7)”, keycloak/keycloak on GitHub, 4 September 2026, retrieved 2026-09-27, https://github.com/keycloak/keycloak/commit/c815969382db28c10cb52aa4f10330e6e44dbda9
Keycloak, IdpCreateUserIfUniqueAuthenticator.java, keycloak/keycloak on GitHub, retrieved 2026-09-27, https://github.com/keycloak/keycloak/blob/main/services/src/main/java/org/keycloak/authentication/authenticators/broker/IdpCreateUserIfUniqueAuthenticator.java
Keycloak, KeycloakModelUtils.java (findUserByNameOrEmail), keycloak/keycloak on GitHub, retrieved 2026-09-27, https://github.com/keycloak/keycloak/blob/main/server-spi-private/src/main/java/org/keycloak/models/utils/KeycloakModelUtils.java
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 releases, tags 26.6.7 and 26.4.16, retrieved 2026-09-27, https://github.com/keycloak/keycloak/tags