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 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 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.

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 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 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 vulnerability was found in Keycloak-services package. If untrusted data is passed to the method (SearchQueryUtils), it could lead to a denial-of-service scenario by exhausting system resources.

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 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 the logging format is configured to a verbose, user-supplied pattern (such as the pre-defined 'long' pattern), sensitive headers including Authorization and Cookie are disclosed to the logs in cleartext. An attacker with read access to the log files can extract these credentials (e.g., bearer tokens, session cookies) and use them to impersonate users, leading to a full account compromise.

Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-gvgg-2r3r-53x7. This link is maintained to preserve external references.

Original Description A flaw was found in the Keycloak organization feature, which allows the incorrect assignment of an organization to a user if their username or email matches the organization’s domain pattern. This issue occurs at the mapper level, leading to misrepresentation in tokens. If an application relies on these claims for authorization, it may incorrectly assume a user belongs to an organization they are not a member of, potentially granting unauthorized access or privileges.

A flaw was found in Keycloak where the default Dynamic Client Registration (DCR) policy permits the use of User Property mappers without validating the target claim path. While the policy checks the mapper provider type, it does not restrict where the mapper can write data within the resulting token. An attacker with a standard user account and a limited Initial Access Token (IAT) can register a new client and configure User Property mappers (such as firstName or lastName) to target the resourceaccess.realm-management.roles claim path. By setting their user profile properties to administrative role names (e.g., manage-clients, realm-admin), the attacker can produce a forged access token containing these roles. Although recent mitigations (CVE-2026-4629) protect the Admin REST API from such forged tokens, the Client Registration API remains vulnerable because it reads the resourceaccess claim directly during authorization. An attacker can use this bypass to perform unauthorized DCR operations, including reading confidential client secrets, modifying redirect URIs, and impersonating service accounts to achieve full realm compromise.

A flaw was found in Keycloak. The Keycloak guides recommend to not expose /admin path to the outside in case the installation is using a proxy. The issue occurs at least via ha-proxy, as it can be tricked to using relative/non-normalized paths to access the /admin application path relative to /realms which is expected to be exposed.

Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-xhpr-465j-7p9q. This link is maintained to preserve external references.

Original Description A flaw was found in Keycloak. When an authenticated attacker attempts to merge accounts with another existing account during an identity provider (IdP) login, the attacker will subsequently be prompted to "review profile" information. This vulnerability allows the attacker to modify their email address to match that of a victim's account, triggering a verification email sent to the victim's email address. The attacker's email address is not present in the verification email content, making it a potential phishing opportunity. If the victim clicks the verification link, the attacker can gain access to the victim's account.

A flaw was found in Keycloak. A remote attacker could bypass security controls by sending a valid SAML response from an external Identity Provider (IdP) to the Keycloak SAML endpoint for IdP-initiated broker logins. This allows the attacker to complete broker logins even when the SAML Identity Provider is disabled, leading to unauthorized authentication.

Critical: Red Hat build of Keycloak 26.6.6 Security Update

A flaw was found in the SAML metadata import functionality of the keycloak-services component, which is the core engine for identity brokering in Red Hat Build of Keycloak. When importing identity provider metadata that lacks specific usage attributes for keys, the system incorrectly disables signature validation for SAML responses even if a signing certificate is provided. This issue allows an unauthenticated attacker to forge a SAML response and gain unauthorized access to a user account by knowing their external identifier.

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

Red Hat build of Keycloak 26.4.14 is a standalone server, based onthe Keycloak project, that provides authentication andstandards-based single sign-on capabilities for web and mobileapplications.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)

Improper input validation vulnerability in Keycloak related to the handling of matrix parameters in URL paths. The issue occurs because Keycloak, via its JAX-RS routing layer, accepts RFC-compliant matrix parameters (e.g., ;param) in path segments, while common reverse proxy configurations may ignore or mishandle them when enforcing access restrictions. A remote attacker can craft requests such as /realms;abc/master/account to mask path segments and bypass proxy-level path filtering. Although authentication is still required, this may expose administrative or sensitive endpoints that operators believe are not externally reachable. Exploitation is network-based, requires no authentication, and depends on the reverse proxy configuration in front of Keycloak.

The issue arises because Keycloak does not perform an LDAP bind after a password reset, leading to potential authentication bypass for expired or disabled AD accounts. A fix should enforce LDAP validation after password updates to ensure consistency with AD authentication policies.

Deployments of Keycloak with a reverse proxy not using pass-through termination of TLS, with mTLS enabled, are affected by an issue where an attacker on the local network can authenticate as any user or client that leverages mTLS as the authentication mechanism.

Trusted proxies introduced in Keycloak 26 can mitigate this to some extent by only accepting certificates from proxy headers if the request is coming from the IP address of the proxy. However, this is a very weak form of authentication as IP addresses can in many cases be spoofed.

The attacker would need to have access to the local network, and in addition gain access to the corresponding public certificates, which in many cases is not the hardest thing to do, especially considering that we are assuming an insider, or an attacker that has gained access to the local network.

Additionally, Keycloak can further be configured to not only obtain certificates through HTTP headers, but also to not validate the certificates. If this option is enabled for a deployment the attacker does not have to obtain the actual public certificate, and can simply generate a random one with for example openssl with whatever subject they want.

The SAML signature validation method in Keycloak uses the position of the signature within the XML document to determine if the signature is for the full document or an assertion. This approach can be exploited by attackers to bypass signature validation and perform unauthorized actions.

A flaw was found in Keycloak in the OAuth 2.0 Pushed Authorization Requests (PAR). Client provided parameters were found to be included in plain text in the KCRESTART cookie returned by the authorization server's HTTP response to a requesturi authorization request. This could lead to an information disclosure vulnerability.

A flaw was found in Keycloak. An active keycloak session can be hijacked by initiating a new authentication (having the query parameter prompt=login) and forcing the user to enter his credentials once again. If the user cancels this re-authentication by clicking Restart login, the account takeover could take place as the new session, with a different SUB, will have the same SID as the previous session.