CVE-2026-109082: Keycloak CIBA Auth Bypass Vulnerability

CVE-2026-109082 Overview

CVE-2026-109082 is an authentication flaw in the Client-Initiated Backchannel Authentication (CIBA) implementation within the keycloak-services component of Keycloak. The CIBA flow permits a client application to initiate a login on behalf of a user through an out-of-band approval channel. Keycloak fails to verify that a client is authorized to use the CIBA flow, which allows public clients to bypass security requirements intended for confidential clients. An attacker who convinces a user to approve a backchannel login request can obtain full access to the user's account without presenting a client secret. The weakness is tracked under [CWE-287: Improper Authentication].

Critical Impact
Public clients can abuse the CIBA endpoint to obtain user tokens after a social-engineered approval, resulting in full account takeover without client credentials.

Affected Products

Red Hat build of Keycloak (see Red Hat CVE-2026-109082)
Keycloak keycloak-services component implementing the CIBA grant
Downstream distributions and container images bundling the affected Keycloak release

Discovery Timeline

2026-10-12 - CVE-2026-109082 published to the National Vulnerability Database
2026-10-15 - Last updated in the NVD database

Technical Details for CVE-2026-109082

Vulnerability Analysis

The flaw resides in how the keycloak-services module processes requests to the CIBA backchannel authentication endpoint. CIBA is defined in the OpenID Connect specification as a decoupled flow where a Consumption Device (the client) requests authentication, and the user approves on an Authentication Device such as a phone. The specification requires clients using CIBA to be confidential and to authenticate to the token endpoint with a secret, mTLS, or a signed JWT. Keycloak does not enforce that the requesting client is enabled for the CIBA grant and does not reject public clients at the /bc-authorize endpoint. As a result, a public client registered in the realm can issue CIBA requests and later retrieve tokens, bypassing the authentication requirements that normally gate backchannel flows.

Root Cause

The root cause is a missing authorization check for the CIBA grant type on the backchannel authentication endpoint. The component accepts the client identifier without validating that CIBA is permitted for that client and without enforcing confidential-client authentication. This maps to [CWE-287: Improper Authentication], where an access decision is made without verifying the full authentication context required by the protocol.

Attack Vector

Exploitation requires an attacker to control or register a public client in the target Keycloak realm and to persuade a legitimate user to approve a backchannel authentication prompt on their Authentication Device. The attacker sends a CIBA authentication request referencing the victim's identifier, waits for approval, and then polls the token endpoint. Because the server does not enforce client authentication for the flow, the attacker receives an access token and refresh token bound to the user. Attack complexity is high because it depends on user interaction and realm registration conditions, but the resulting impact to confidentiality and integrity is complete account takeover. Technical details are available in the Red Hat Bug Report #2549478.

Detection Methods for CVE-2026-109082

Indicators of Compromise

CIBA authentication requests to /realms/{realm}/protocol/openid-connect/ext/ciba/auth originating from clients configured as public rather than confidential.
Token issuance events in Keycloak audit logs where the grant_type is urn:openid:params:grant-type:ciba and the client has no secret configured.
Repeated auth_req_id polling from unexpected IP addresses or user-agents following a user approval event.
User approval prompts delivered to Authentication Devices that the user did not initiate.

Detection Strategies

Enable Keycloak event logging for LOGIN, CODE_TO_TOKEN, and CLIENT_LOGIN events and forward them to a central analytics platform for correlation.
Alert on any successful token issuance where the grant type is CIBA and the client access type is public.
Baseline CIBA usage per client and alert on new clients that begin issuing backchannel requests.

Monitoring Recommendations

Review all realm clients and flag those with the CIBA grant enabled but with public access type.
Monitor outbound notifications from the CIBA Authentication Channel Provider to identify unusual approval volume.
Track refresh token usage from sessions established via CIBA to detect post-compromise persistence.

How to Mitigate CVE-2026-109082

Immediate Actions Required

Inventory realms that have the CIBA feature enabled and disable it where it is not required.
Convert any client intended to use CIBA from public to confidential, and configure a client secret, mTLS, or signed-JWT authenticator.
Rotate credentials and revoke active sessions for any user account suspected of approving an unauthorized backchannel prompt.
Review Keycloak event logs for CIBA token issuance tied to public clients since the feature was enabled.

Patch Information

Apply updates provided by the Keycloak project and downstream vendors. Refer to Red Hat CVE-2026-109082 for fixed-version mapping across the Red Hat build of Keycloak, and apply the corresponding errata to each deployed instance. Rebuild and redeploy container images that embed Keycloak after the fixed release is available.

Workarounds

Disable the CIBA grant type at the realm level until the patched version is deployed.
Restrict client registration so that only administrators can create clients with the CIBA grant enabled.
Enforce confidential client authentication on all clients and remove the public access type from any client that must use CIBA.

bash

# Disable the CIBA grant for a client using kcadm.sh
kcadm.sh update clients/<client-uuid> -r <realm> \
  -s 'attributes."oidc.ciba.grant.enabled"=false'

# Enforce confidential access type on a CIBA-enabled client
kcadm.sh update clients/<client-uuid> -r <realm> \
  -s publicClient=false \
  -s clientAuthenticatorType=client-secret