Brief Summary: Keycloak CVE-2026-112208 Organization Login Authentication Bypass Enabling Account Takeover

Introduction

A state-handling flaw in Keycloak's Organization login flow lets an authenticated user who belongs to more than one organization finish a login as somebody else, receiving the victim's authorization code, access tokens, and a valid SSO session. Because Keycloak sits in front of every application it federates, a bypass at this layer translates directly into access to the victim's connected services.

Keycloak is an open-source identity and access management server that handles login, single sign-on, and token issuance for applications and services. It was accepted into the CNCF at the Incubating maturity level on April 10, 2023, and Red Hat ships a commercially supported distribution called Red Hat Build of Keycloak. Deployments can be large. A CNCF case study describes the Austrian Federal Computing Center (BRZ) running the Austrian Business Service Portal on Keycloak with over 2 million registered users, around 650,000 registered organizations, and access to over 130 digital public services. Those numbers show how much access one identity server can concentrate, though they are not evidence that BRZ uses the vulnerable configuration.

Key facts at a glance:

CVSS 3.1: 8.1 High, assigned by Red Hat (severity: Important). NVD displays Red Hat's score. NIST has not supplied its own assessment, and the record is awaiting enrichment.
Weakness: CWE-305, Authentication Bypass by Primary Weakness.
Prerequisites: the Organization feature must be enabled, and the attacker must hold valid credentials in at least two organizations.
Remediation status: no fixed version identified and no qualifying vendor workaround published.
Exploitation status: no confirmed exploitation in the wild and no attributed threat actor. OpenCVE shows KEV status as No.

Technical information

Keycloak's Organization feature provides organization contexts within a realm. Its identity first login process identifies a user before requesting credentials or redirecting authentication to an organization's identity provider. That ordering makes the distinction between identifying a username and authenticating that identity especially important, and this bug erodes exactly that distinction.

Root cause: a stale SSO_AUTH note

Red Hat Bugzilla 2555473 identifies the defective state as the SSO_AUTH note, an authentication session note representing successful SSO reauthentication. The sequence of state changes is:

During an organization-scoped login, the authentication session holds an authenticated user and the SSO_AUTH note is set.
When the flow changes to registration or credential reset, Keycloak removes the authenticated user from the authentication session.
Keycloak does not clear the SSO_AUTH note at the same time.
The Organization authenticator later reads that note and treats it as proof of identity for whatever username is now supplied.

The attacker never learns or guesses the victim's password. Keycloak keeps trusting authentication state produced for one identity after the session's user has changed to another. Red Hat summarizes the root cause as improper management of internal authentication state during login flow transitions. No vulnerable code excerpt has been published in the reviewed sources, so we do not reproduce one here.

Attack flow

The vendor documents the following sequence, without publishing a full request transcript or executable exploit:

An attacker with valid credentials in two or more organizations initiates an authorization request scoped to an organization.
The attacker switches the flow to registration or credential reset. The authenticated user is removed from the session, but the SSO_AUTH note remains.
The attacker submits the victim's username.
The Organization authenticator accepts the stale note as proof of the victim's identity.
The attacker obtains the victim's authorization code, access tokens, and an SSO session usable against downstream applications.

The outcome is impersonation of the victim rather than a leak of their data. Once a valid SSO session exists for the victim, every client application relying on that realm will treat the attacker as the victim.

Scoring breakdown

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

The vector describes network exploitation with low complexity, low privileges (the attacker needs their own accounts), no user interaction from the victim, unchanged scope, high confidentiality and integrity impact, and no scored availability impact.

What the sources do not establish

The reviewed material does not say whether additional realm boundaries, particular identity providers, or specific multifactor authentication configurations change the outcome. It also does not describe arbitrary code execution. The documented impact is account and application access compromise.

Affected systems and versions

Keycloak Organization identity first login flow: the vulnerable flow described by the vendor. The reviewed technical description gives no bounded upstream version range.
Red Hat Build of Keycloak: listed as affected in the CVE record, defaulting to all versions affected without enumerated version entries.
Red Hat Single Sign On 7: listed as unaffected in the CVE record.

The CVE product defaults should not be read as a published introduction version or a complete upstream release history.

Vulnerable configuration: the Organization feature must be enabled, and an attacker must be able to hold valid accounts in at least two organizations. Deployments that do not meet both conditions are not exposed to the documented scenario.

Remediation status: the Bugzilla Fixed In Version field is empty and the CVE record supplies no remedy. Red Hat's statement reads:

"Mitigation for this issue is either not available or the currently available options do not meet the Red Hat Product Security criteria comprising ease of use and deployment, applicability to widespread installation base, or stability."

Keycloak's security policy places security fixes in the current or a subsequent major.minor release depending on severity, and Red Hat's lifecycle policy covers Important fixes during Full Support and Maintenance Support. Neither is a patch announcement for this CVE, so we recommend tracking the Red Hat advisory and Bugzilla issue directly.

Separately, Keycloak does not store events by default. Enabling Save events under Realm settings, Events, User events settings records Login, Register, Code to Token, and Refresh Token activity. That improves general visibility but is not a fix, and no CVE-specific log signature has been published.

Vendor security history

Two recent Keycloak advisories involve different authentication trust failures, and both shipped with published fixes:

CVE-2026-11800: JWT algorithm confusion in the JWT Authorization Grant flow lets an attacker with valid client credentials bypass signature verification and forge access tokens. Patched in 26.6.4.
CVE-2026-2092: the SAML broker improperly validates encrypted assertions when the overall response is unsigned, allowing an attacker with a valid signed assertion to inject an encrypted assertion for another principal. Patched in 26.2.14, 26.4.10, 26.5.5, and 26.6.0.
CVE-2026-112208: stale authentication state is trusted after the session user changes. No fixed version identified.

In all three, Keycloak accepts legitimate authentication material in the wrong verification context. Do not assume the patched versions for the earlier advisories fix CVE-2026-112208. Keycloak publishes a coordinated disclosure process with acknowledgment of reports within seven business days. Red Hat credits LHeiakim for reporting this issue, which was filed in Bugzilla on October 19, 2026, ahead of NVD publication on November 5, 2026.

CVE Analysis

Experimental AI-Generated Content

Introduction