Introduction
An authentication flaw in Keycloak's identity brokering lets a user who controls an account at a federated identity provider be linked to, and log in as, someone else's existing Keycloak account. Red Hat describes the result as full account takeover, including changing the victim's email and password. Because the failure happens inside the identity provider itself, the compromised account carries whatever access the victim's identity grants to the applications and APIs that rely on that Keycloak realm.
Keycloak is an open-source identity and access management solution that provides centralized authentication and authorization for applications and APIs. It entered the CNCF at the Incubating maturity level on April 10, 2023, and Red Hat ships a supported downstream distribution, Red Hat Build of Keycloak. The sources we reviewed do not provide deployment counts or market share figures, so we make no claim about how many installations are exposed. Keycloak is central identity infrastructure, though, so a flaw in account linking affects every relying application in a realm.
Technical information
Root cause
The issue is classified as CWE-287, Improper Authentication, and lives in the idp-auto-link authenticator of the keycloak-services component.
When a user arrives through an external identity provider for the first time, Keycloak's first login flow decides whether to create a new local user or associate the incoming identity with an existing one. The idp-auto-link authenticator performs that association automatically by matching the email address supplied by the external provider against existing local accounts.
This matching happens without verifying whether the provider has validated that email. An email address presented by a brokered provider is, in that state, just an attribute the external account holder may have chosen. Treating it as proof of ownership of a local account turns an unverified, attacker-controlled claim into an authentication decision.
Keycloak's own documentation describes the underlying tradeoff. The Automatically Set Existing User behavior establishes the existing user in the authentication context without verification, and the documentation warns against using AutoLink unless registration and assignment of usernames and email addresses are carefully curated. The documented alternatives (confirming the link by email, or requiring authentication to the existing account) add a step that proves or confirms the association instead of accepting it automatically.
Attack flow
Based on Red Hat's advisory, the mechanism works as follows (this is a description of the advisory, not an exploit):
- The attacker holds an account at an external identity provider that the target Keycloak realm brokers.
- That external identity presents an email address matching the victim's existing local account, and the provider has not verified this email.
- The automatic linking authenticator links the incoming identity to the victim's account and authenticates it, without checking the provider's email verification.
- The attacker is now authenticated as the victim and can change the victim's email and password, completing the takeover.
The prerequisite is an account at a brokered provider, which aligns with the Low privileges rating in the CVSS vector.
Severity
Red Hat, acting as CNA, assigns a CVSS 3.1 base score of 8.8 (High) and its own severity rating of Important. NVD has not published an independent assessment and lists enrichment as pending.
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
The vector specifies network access, low complexity, low privileges, no user interaction, unchanged scope, and high impact to confidentiality, integrity and availability. The published narrative documents account takeover. It does not describe a separate denial-of-service condition, despite the high availability rating.
A related issue that is not this CVE
Public issue #53041 also discusses idp-auto-link, but it describes the opposite verification direction: linking to a local account whose email was never verified, in a scenario where the brokered provider supplies a verified email. It is not identified as CVE-2026-97175, and its reproduction steps should not be read as a proof of concept for this CVE. The tracking issue for this CVE is #54707, which is closed as completed. Its public description does not expose the underlying code change.
Exploitation status
We found no confirmed exploitation in the wild, named threat actor, or public proof of concept for this CVE in the reviewed records. OpenCVE reports that it is not in the KEV catalog and that no EPSS score is available. Red Hat credits ProofSpear Security Labs with reporting the issue. That is a reporting credit, not attribution. The absence of threat reporting is a gap in the evidence, and it does not show that exploitation has not occurred.
Affected systems and versions
- Upstream Keycloak: The public records do not establish an exact affected version range. Keycloak 26.8.2, released November 5, 2026, explicitly lists CVE-2026-97175 among its security fixes in both the GitHub release and the official announcement, which also directs administrators to review the migration guide before upgrading.
- Red Hat Build of Keycloak: Listed as affected, including
keycloak-servicesand therhbk/keycloak-rhel9container. The reviewed records do not identify a fixed downstream package version, and OpenCVE reports no advisory yet. The upstream 26.8.2 version number should not be read as a Red Hat package identifier. - Red Hat Single Sign On 7: Listed as not affected.
Vulnerable configuration
Exposure depends on the broker login flow, not merely on having an external identity provider configured. The documented risk is in realms where the first login flow for a brokered provider uses automatic linking (idp-auto-link) to associate incoming identities with existing local accounts by email.
Keycloak's First Login Flow documentation describes general safeguards relevant to this pattern. These are product guidance, not a workaround Red Hat has validated for this CVE:
- Restrict automatic linking: do not use AutoLink unless registration and assignment of usernames and email addresses are carefully curated.
- Verify Existing Account By Email: sends an email asking the user to confirm linking the provider to the existing account.
- Authenticate to the existing account before linking: requires the user to authenticate as the existing account (or through another already linked provider) before the link is created.
The Upgrading Guide adds a qualification. When a user modifies linking attributes during profile review, authentication to the existing account becomes the available linking alternative, so email confirmation is not available in every linking situation.
Red Hat states that mitigation is either unavailable or that available options do not meet its Product Security criteria for ease of deployment, broad applicability or stability. No reviewed source establishes that changing the Trust Email setting alone addresses this CVE. The published root cause is the missing validation before automatic linking.
Vendor security history
Two recent Keycloak advisories show other failures at the boundary between external assertions and local authentication:
- CVE-2026-11800 (JWT algorithm confusion): In the JWT Authorization Grant flow, an attacker with valid client credentials can bypass signature verification, forge an assertion, and obtain unauthorized access tokens, potentially impersonating federated users. The advisory identifies 26.6.4 as patched.
- CVE-2026-2092 (encrypted SAML assertion validation): At the SAML broker endpoint, when the overall response is unsigned, an attacker possessing a valid signed assertion can inject an encrypted assertion for another principal, leading to unauthorized access and possible information disclosure. Patched versions are 26.2.14, 26.4.10, 26.5.5 and 26.6.0.
The mechanisms differ: CVE-2026-11800 accepts an improperly verified signature, CVE-2026-2092 accepts an improperly validated encrypted assertion, and CVE-2026-97175 accepts an unverified identity attribute during account association. In all three, an external identity claim can become unauthorized access to a local identity. These cases do not by themselves establish whether Keycloak's vulnerability rate is better or worse than comparable platforms.
On process, Keycloak publishes a security reporting address ([email protected]), commits to acknowledging reports within 7 business days, and rejects reports based only on scanners or AI output without a proof of concept. Its policy notes that lower-severity fixes or hardening may ship in a following release rather than the current one, and points organizations that cannot upgrade regularly to Red Hat Build of Keycloak for long-term support.
References
- NVD entry for CVE-2026-97175
- CVE.org record for CVE-2026-97175
- Red Hat Customer Portal: CVE-2026-97175
- Keycloak issue #54707: Unverified IdP email auto linking enables account takeover
- Keycloak 26.8.2 release on GitHub
- Keycloak 26.8.2 release announcement
- newreleases.io: keycloak 26.8.2
- OpenCVE: CVE-2026-97175
- VulDB: CVE-2026-97175
- Keycloak issue #53041 (related but distinct idp auto link issue)
- Keycloak docs: First Login Flow
- Keycloak Server Administration Guide
- Keycloak Upgrading Guide
- CNCF: Keycloak joins CNCF as an incubating project
- CNCF: Keycloak project page
- GitHub advisory: Authentication bypass via JWT algorithm confusion (CVE-2026-11800)
- GitHub advisory: Improper validation of encrypted SAML assertions (CVE-2026-2092)
- Keycloak Security Policy
- Red Hat Build of Keycloak 26.6 Release Notes
