A flaw was found in Keycloaks implementation of the Client-Initiated Backchannel Authentication CIBA grant. Although the CIBA specification and Keycloaks internal contract intend for this flow to be restricted to confidential clients, the enforcement mechanism is missing at both the backchannel-authentication and token endpoints. While bearer-only clients are correctly rejected, public clients which authenticate using only a client-id are permitted to proceed. An attacker can exploit this by using a public client to initiate a CIBA flow for a known user via login-hint. If the targeted user approves the resulting push notification on their authentication device, the attacker can redeem the auth-req-id at the token endpoint to obtain a valid user access token. This allows the attacker to perform any action the user is authorized to do and access their private information, all without ever possessing a client secret or valid credentials.

A flaw was found in Keycloaks implementation of the Client-Initiated Backchannel Authentication CIBA grant. Although the CIBA specification and Keycloaks internal contract intend for this flow to be restricted to confidential clients, the enforcement mechanism is missing at both the backchannel-authentication and token endpoints. While bearer-only clients are correctly rejected, public clients which authenticate using only a client-id are permitted to proceed. An attacker can exploit this by using a public client to initiate a CIBA flow for a known user via login-hint. If the targeted user approves the resulting push notification on their authentication device, the attacker can redeem the auth-req-id at the token endpoint to obtain a valid user access token. This allows the attacker to perform any action the user is authorized to do and access their private information, all without ever possessing a client secret or valid credentials.

A flaw was found in the login theme rendering component of Keycloak. The issue occurs because the security filter responsible for cleaning user input can be bypassed, allowing a realm administrator to store malicious scripts in display fields. This could result in unauthorized JavaScript execution in the browsers of users visiting the login page, potentially leading to data exposure or session interference.

A flaw was found in the keycloak-services component. A copy-paste error in the OIDC Dynamic Client Registration response serialization prevents the backchannellogoutrevokeofflinetokens setting from being included in GET responses. When an authorized user or client performs a standard read-modify-write update (GET followed by PUT), the missing field is interpreted as false, silently disabling the revocation of offline tokens. An attacker with manage-clients or registration access can exploit this to ensure offline tokens survive backchannel logout events, maintaining unauthorized access after a session should have been terminated. Additionally, this bug causes the backchannellogoutsessionrequired status to be incorrectly overwritten.

A flaw was found in the keycloak-services component. A copy-paste error in the OIDC Dynamic Client Registration response serialization prevents the backchannellogoutrevokeofflinetokens setting from being included in GET responses. When an authorized user or client performs a standard read-modify-write update (GET followed by PUT), the missing field is interpreted as false, silently disabling the revocation of offline tokens. An attacker with manage-clients or registration access can exploit this to ensure offline tokens survive backchannel logout events, maintaining unauthorized access after a session should have been terminated. Additionally, this bug causes the backchannellogoutsessionrequired status to be incorrectly overwritten.

A flaw was found in the Admin REST installation provider endpoints and the Client Registration install endpoint in Keycloak. While the dedicated client-secret endpoint correctly enforces authorization, these specific endpoints fail to mask the client secret when accessed by a user with the realm-management:view-clients role. An authenticated attacker with this role can retrieve the cleartext secret of any confidential client using the client-secret authenticator. Successful exploitation allows the attacker to obtain a client-credentials access token and exercise the target client's service account permissions. This issue represents an incomplete fix for CVE-2026-89298.

A flaw was found in the Admin REST installation provider endpoints and the Client Registration install endpoint in Keycloak. While the dedicated client-secret endpoint correctly enforces authorization, these specific endpoints fail to mask the client secret when accessed by a user with the realm-management:view-clients role. An authenticated attacker with this role can retrieve the cleartext secret of any confidential client using the client-secret authenticator. Successful exploitation allows the attacker to obtain a client-credentials access token and exercise the target client's service account permissions. This issue represents an incomplete fix for CVE-2026-89298.

A Cleartext Transmission of Sensitive Information vulnerability was found in the keycloak-services component. The issue exists in the SMTP configuration handling where setting starttls=true results in opportunistic TLS rather than mandatory TLS. An active Man-in-the-Middle attacker can strip the STARTTLS capability from the SMTP server response during the EHLO exchange. Because Keycloak does not enforce the upgrade to TLS, it proceeds to fall back to an unencrypted plaintext connection. This allows the attacker to capture SMTP authentication credentials and the full content of email messages transmitted by the server.

A flaw was found in the Dynamic Client Registration flow of the Keycloak identity and access management server. The issue occurs because the registration process fails to filter security-sensitive client attributes when a new client is created. An attacker with a valid Initial Access Token can register a client that bypasses audience checks during token introspection. This allows the attacker to view sensitive identity information, roles, and session details from access tokens belonging to other applications in the same realm.

A vulnerability was found in Keycloak where the Dynamic Client Registration (DCR) flow does not properly filter sensitive client attributes. Specifically, a registrant using an Initial Access Token can set the internal attribute allow.token.introspection.without.audience.check during the registration process. This attribute disables the mandatory audience verification on the token introspection endpoint. To exploit this flaw, an attacker must possess a valid Initial Access Token for a realm where DCR is enabled. By registering a malicious client with this attribute, the attacker can then use that client's credentials to introspect any active access token they have obtained or intercepted from other clients in the same realm. Successful exploitation results in the disclosure of the full claim set of the token, including user identity, roles, scopes, and session IDs, regardless of whether the introspecting client was the intended audience. This is a bypass of the security controls introduced to fix CVE-2026-37979.

A flaw was found in the OIDC implementation of Keycloak, specifically within the Device Authorization Grant flow. This component allows devices with limited input capabilities to obtain security tokens. The issue occurs because the flow fails to check the minimum authentication level required by a client configuration. This allows an attacker who has stolen a user's password to bypass mandatory multi-factor authentication and gain unauthorized access to the Keycloak Admin REST API.

A flaw was found in the User Session Note mapper of the Keycloak identity and access management solution. The issue occurs because the mapper does not validate whether a requested session note contains sensitive internal credentials, such as federated access tokens from external identity providers. This allows a delegated client administrator to leak a user's upstream bearer tokens into the tokens issued to their managed application, potentially leading to unauthorized access to the user's data on external platforms.

A vulnerability was found in Keycloak where the User Session Note mapper (oidc-usersessionmodel-note-mapper) fails to restrict access to sensitive internal session notes. When a user authenticates through an external identity provider (IdP), Keycloak stores the upstream access and refresh tokens as internal user session notes (FEDERATEDACCESSTOKEN and FEDERATEDREFRESHTOKEN). A delegated administrator with manage permissions for an OIDC client can configure a mapper to copy these internal notes into the client's issued tokens. Because the mapper accepts any note name without validation, it allows a client manager to bypass the dedicated broker-token retrieval API and its associated security checks (such as the broker.read-token role). Successful exploitation requires the attacker to have Fine-Grained Admin Permission (FGAP) to manage at least one OIDC client and for the deployment to have session token storage enabled (default in Identity Brokering API v1). An attacker can then observe the tokens issued to their managed application to obtain a victim's upstream bearer tokens, which are directly usable against the external identity provider to access the victim's account information or perform actions on their behalf.

A flaw was found in the X.509 client certificate authenticator of Keycloak. When CRL Distribution Point checking is enabled, the server fails to properly validate the file paths provided in a client certificate. An attacker can provide a specially crafted certificate that causes the server to attempt to read sensitive files from the local system or exhaust memory by loading extremely large files, potentially leading to information disclosure or a system crash.

Latest version: 26.8.1

A flaw was found in the Fine-Grained Admin Permissions (FGAP v2) feature of Keycloak, an identity and access management solution. The issue occurs when the system checks if a delegated administrator has permission to assign a specific role to a user. Because the check does not look inside composite roles to see what other permissions they contain, an administrator with limited rights can assign a role that secretly includes full administrative control. This allows the attacker to gain complete management access over the entire realm.

A vulnerability was found in Keycloak where the Standard Token Exchange V2 grant path fails to enforce mTLS holder-of-key token binding. When a confidential client is configured with tls.client.certificate.bound.access.tokens set to true, Keycloak correctly rejects standard token grants if no client certificate is provided. However, an attacker who possesses the client credentials and a valid subject token can use the Standard Token Exchange V2 endpoint to obtain an active Bearer access token without presenting a TLS client certificate. The resulting token lacks the cnf.x5t#S256 claim, effectively bypassing the configured sender-constraint and allowing unauthorized access to protected resources.

A flaw was found in the Admin REST API of Keycloak, an identity and access management solution. The endpoints used to retrieve groups associated with a specific role do not properly check for individual group visibility permissions. This allows a delegated administrator with basic search privileges to view detailed information about all groups assigned to a role, bypassing intended security restrictions that should limit their view to specific groups.

A Missing Authorization flaw was found in the org.keycloak.services.resources.admin package of Keycloak. The Admin REST API endpoint for updating user information (PUT /admin/realms/{realm}/users/{id}) enforces generic user management permissions (requireManage) but fails to validate fine-grained reset-password authorization (requireResetPassword). In environments where Fine-Grained Admin Permissions (FGAP) are enabled, a delegated administrator who has been granted manage permissions but is explicitly denied reset-password authority can include a credentials object in the user update payload. Because the specific permission check is missing in this code path, the password update is processed successfully. Successful exploitation allows a restricted administrator to: Set a new password for any managed user.

Gain full unauthorized access to victim accounts (account takeover).

Lock legitimate users out of their accounts.

A flaw was found in Keycloak's Level of Authentication (LoA) enforcement within the ConditionalLoaAuthenticator component. When a client requests a specific acr level as essential:true via the OIDC claims request parameter and an existing SSO session is present, Keycloak can silently issue a token asserting a lower acr level than required without triggering the mandatory forced-level failure. The vulnerability exists because when the browser flow re-evaluates an existing session via the Cookie authenticator, LoA-gated Conditional sub-flows may be disabled (e.g., if the user lacks the required credentials for the higher level). In this scenario, the ConditionalLoaAuthenticator fails to register its top-flow-success callback. Consequently, the onTopFlowSuccess() method is never executed, and the mandatory forced-level check is bypassed. An authenticated attacker with a valid low-level session can exploit this to obtain tokens for clients requiring higher authentication levels (essential:true) without providing the necessary additional factors. This results in an authentication level bypass for relying parties that trust the acr claim to guarantee the level was verified during the current authentication.

A flaw was found in Keycloaks Pushed Authorization Request PAR implementation. The single-use enforcement for PAR request URIs, as required by RFC 9126 section 4, is bypassed when using the silent authentication path prompt=none. When an existing SSO session is present, the authorization endpoint short-circuits directly to the successful-flow redirect handler. In this specific code path, the PAR consumption logic is never triggered, meaning the pushed request object is not removed from storage after use. Exploitation requires that the realm has PAR enabled, the attacker has valid client credentials to push an authorization request, and an active SSO session exists for the target user. A successful attacker can replay the requesturi multiple times to mint distinct, fully redeemable authorization codes for the same user without requiring the resource owner to re-authenticate. This allows for unauthorized token generation and violates the single-use guarantee required for FAPI-2 and RFC 9126 compliant deployments.

A flaw was found in the Conditional OTP authenticator of Keycloak, an identity and access management solution. The issue occurs when the system evaluates specific HTTP headers to determine if a one-time password (OTP) should be skipped, but fails to verify if those headers came from a trusted source. This could allow an attacker who already has a user's password to bypass the second-factor authentication by providing a specially crafted header in their request.

A flaw was found in the ConditionalOtpFormAuthenticator component of Keycloak. The vulnerability exists because the skip-header policy evaluates configured header patterns against raw request headers without verifying whether the request originates from a trusted proxy via the isProxyTrusted check. Exploitation requires that the target realm has a Conditional OTP flow configured with a skip rule for a specific HTTP header and that the attacker has already obtained a victim's password. By injecting the matching header directly into the login request, an attacker can cause Keycloak to treat the request as if it came from a trusted environment where OTP is not required. Successful exploitation allows an attacker to bypass multi-factor authentication, gain full access to the victim's account, modify user data, and perform administrative actions if the victim has elevated privileges.

A flaw was found in the Kerberos federation provider of Keycloak, an open-source identity and access management solution. When Kerberos password authentication is used without SPNEGO, the system fails to verify the identity of the Key Distribution Center (KDC) by requesting a server ticket. This allows an attacker on the same network to spoof the KDC and bypass the authentication process, potentially gaining unauthorized access to user accounts.

A flaw was found in the keycloak-services component where it fails to properly validate the KDC identity during Kerberos password authentication. When Kerberos password mode is enabled without SPNEGO/negotiate authentication, Keycloak does not request a server ticket in the name of the authenticating user to verify the KDC response. An attacker capable of performing DNS, ARP, or DHCP spoofing on the local network can provide a fraudulent KDC response. Successful exploitation allows an attacker to bypass authentication entirely and impersonate any user, leading to unauthorized access to sensitive data and administrative functions.

A flaw was found in Keycloak. When deployed in stateless mode with MySQL or MariaDB, a mismatch in row-count semantics between the database driver and Keycloak's application logic allows an attacker to bypass replay protection. This vulnerability enables an attacker who intercepts single-use security artifacts, such as JWT client assertions, DPoP proofs, or one-time password (TOTP) codes, to replay them. Successful exploitation grants unauthorized access to the token endpoint or login flow.

Critical: Red Hat build of Keycloak 26.6.6 Security Update

Red Hat build of Keycloak is an integrated sign-on solution,available as a Red Hat JBoss Middleware for OpenShift containerizedimage. The Red Hat build of Keycloak for OpenShift image providesan authentication server that you can use to log in centrally, logout, and register. You can also manage user accounts for webapplications, mobile applications, and RESTful web services.Red Hat build of Keycloak Operator for OpenShift simplifiesdeployment and management of Keycloak 26.4.14 clusters.This erratum releases new images for Red Hat build of Keycloak26.4.14 for use within the OpenShift Container Platform cloudcomputing Platform-as-a-Service (PaaS) for on-premise or privatecloud deployments, aligning with the standalone product release.Security fixes: Admin UI extension brute-force-user endpoint bypasses FGAPv2 user view restrictions (CVE-2026-14209) FGAP v2 client scope assignment bypass via ClientResource (CVE-2026-14614) FGAP v2 parent group children endpoint bypasses per-child view permission filter (CVE-2026-14615) DCR protocol mapper type-swap policy bypass allows privilege escalation (CVE-2026-15572) Authorization bypass via unnormalized URI matching in PathMatcher (CVE-2026-15573) LDAP entry-DN user search bypasses configured users DN boundary (CVE-2026-16071) Default DCR policy allows role forgery via User Property mappers (CVE-2026-16102) Quarkus REST - Unbounded multipart MIME part-header accumulation allows remote OOM denial of service (CVE-2026-16308) SAML IdP-initiated broker login bypasses link-only restriction (CVE-2026-16442) SAML broker metadata import disables response signature validation (CVE-2026-16443) Privilege escalation through hardcoded role mapper injection (CVE-2026-4629) Arbitrary code execution via PolymorphicTypeValidator bypass (CVE-2026-54512) Security bypass allows arbitrary code execution (CVE-2026-54513) HTTP Parameter Pollution in OIDC redirect URI allows response parameter duplication - #GHI-604 (CVE-2026-9689) Security policy bypass in JWE-encrypted request object processing (CVE-2026-9793) Brute-force protection bypass in CIBA flow (CVE-2026-9798) Authorization bypass via incorrect URI comparison (CVE-2026-9800) Brute-force protection bypass in CIBA flow (CVE-2026-9798)

Important: Red Hat build of Keycloak 26.6.5 Security Update

Important: Red Hat build of Keycloak 26.6.5 Images Security Update