A flaw was found in the first-broker-login flow of the Keycloak identity management service. When a user links a social identity provider account to their local account, the verification proof generated is not strictly bound to the specific upstream identity being verified. This allows an attacker with a different account on the same social provider to intercept the process and link their own account to the victim's local profile, gaining unauthorized access.

A flaw was found in the backchannel logout endpoint of the keycloak-services component, which is part of the Red Hat Build of Keycloak. This component handles authentication and session management for applications. The issue occurs when an OIDC identity provider is configured to skip signature validation. In this specific setup, the system incorrectly accepts logout requests that have no cryptographic signature. An attacker who knows certain technical details about a user's session can use this flaw to force that user to be logged out, potentially disrupting their work.

A vulnerability was found in Keycloak where authenticated users can bypass authorization services time policies. When requesting a User-Managed Access (UMA) permission, a caller can supply a claim token containing forged kc.time.datetime values. Keycloak merges these caller-supplied claims after the server-generated time attributes, allowing the forged values to overwrite the server clock during policy evaluation. This allows an attacker to obtain Resource Permission Tokens (RPTs) outside of the time windows configured by administrators, effectively defeating temporal access controls such as maintenance windows or off-hours access denials.

A Missing Authorization vulnerability was identified in Keycloak Google Identity Provider implementation. The flaw exists in the external access-token exchange code path, which is used when the Token Exchange V1 feature is enabled. While the standard Google ID-token login flow correctly validates the hd hosted domain claim against the configured hostedDomain setting, the access-token exchange flow skips this validation. When an external access token is provided, Keycloak retrieves the user profile from the Google user-info endpoint but fails to verify that the domain associated with the user matches the restricted domain configured in the Identity Provider settings. An attacker with a valid Google access token for any domain can exploit this flaw if they have access to a confidential client authorized to perform token exchange. Successful exploitation allows the attacker to bypass domain restrictions, obtain a Keycloak access token, and potentially create or link a brokered identity that should have been restricted.

A flaw was found in the secure-client-uris client policy executor in Keycloak. The executor permits non-HTTPS redirect URIs when allow-http-on-localhost is enabled by performing a simple string prefix check for http://localhost or http://127.0.0.1 instead of parsing the URI to validate the host component. An attacker can exploit this by registering a client via Dynamic Client Registration using a redirect URI that starts with the allowed prefix but points to an attacker-controlled domain (e.g., http://localhost.evil.test). If the policy is scoped to authorizationcode requests, it fails to block the registration or the subsequent use of the malicious URI. When a victim authenticates through the attacker's client, the authorization code is transmitted over cleartext HTTP to the attacker's server. This allows the attacker to intercept the authorization code and potentially gain unauthorized access to the victim's session.

A flaw was found in the hostname matching logic within the ClientUpdaterSourceHostsCondition of Keycloak. When a wildcard domain (e.g., .example.com) is configured as a trusted source host in a client policy, the matching mechanism performs a simple suffix check without ensuring a proper subdomain boundary (a preceding dot). An unauthenticated attacker whose connecting IP address reverse-resolves to a crafted hostname ending in the trusted suffix (e.g., attackerexample.com) can satisfy the condition. This allows the attacker to bypass source-host restrictions intended to limit client registration or update operations to trusted domains. Successful exploitation causes policy executors to run as if the request originated from a legitimate trusted source, which can weaken or bypass security constraints applied to client management.

A flaw was found in the OIDC token introspection endpoint of the keycloak-services component. Keycloak is an open-source identity and access management solution used to secure modern applications and services. The issue occurs when a confidential client, configured to receive signed JWT introspection responses, attempts to introspect a token issued for a different audience. Although the endpoint correctly identifies the token as inactive for that client, it still returns the full set of token claims within a signed JWT field. This allows an unauthorized client to bypass audience-based restrictions and access sensitive information contained in the token.

A flaw was found in the group policy evaluation logic of Keycloak, an identity and access management solution. When a group policy is set to extend permissions to child groups, the system incorrectly uses a simple text-based prefix check to verify group membership. This allows a user who belongs to a different group with a similar starting name to bypass security checks and gain unauthorized access to administrative functions or protected resources.

A flaw was found in the client policy enforcement mechanism of Keycloak. The issue occurs when the system checks group membership by name instead of a unique identifier. An attacker with client management privileges could bypass security policies by joining a group with a matching name in a different part of the group hierarchy, potentially allowing them to register or update clients without following required security hardening profiles.

A flaw was found in Keycloak. The generic identity-provider REST endpoint (/admin/realms/{realm}/identity-provider/instances) allows a user with only manage-identity-providers permission to bind a newly created identity provider to an organization by including an organizationId in the request payload. While the organization-scoped endpoint correctly requires both manage-identity-providers and manage-organizations permissions, the generic endpoint fails to enforce the manage-organizations check. This allows an IdP operator to associate brokers with organizations they are not authorized to manage, influencing organization login flows and broker selection. Additionally, this path skips organization IdP-list cache invalidation, making the newly bound broker invisible in cached organization IdP listings.

A flaw was found in the default-groups REST endpoint and realm representation of Keycloak. This component is responsible for managing groups that are automatically assigned to new users within a realm. The issue allows a delegated administrator with realm-viewing permissions to see the names and identifiers of hidden default groups, even if they lack the specific permissions to view those groups. This can lead to the exposure of sensitive organizational structures or internal group names.

A denial of service vulnerability was discovered in Keycloak metrics implementation. When user-event metrics are enabled, the EventMetricsProvider records the verbatim error message from failed account operations as a Prometheus metric label. The account consent endpoint specifically embeds caller-supplied input, such as nonexistent client IDs or invalid scope names, directly into these error messages. An authenticated attacker with manage-account or manage-consent permissions can exploit this by repeatedly calling the account consent delete endpoint with unique, randomized client ID values. Each request results in a distinct error message and a corresponding new Prometheus metric time series. This leads to unbounded metric cardinality, which can exhaust the memory of both the Keycloak instance and the connected monitoring system, resulting in a denial of service and degradation of metrics availability.

A flaw was found in the authentication configuration endpoint of the keycloak-services component, which is the core engine for Red Hat Build of Keycloak identity and access management. The issue occurs because the system fails to mask sensitive configuration values, such as reCAPTCHA secret keys, when they are requested by administrators with view-only permissions. This can lead to the exposure of third-party service credentials to unauthorized personnel or through administrative logs.

A flaw was found in the Secure Client Registration executor within the keycloak-services component. The vulnerability exists in the logic that enforces the signed-JWT assertion policy for client registration and updates. When the SecureSigningAlgorithmForSignedJwtExecutor is configured to require a client assertion, it only checks the alg field in the raw client assertion JWT header. It fails to validate that the client assertion type is present or that the client's actual authenticator is assertion-based. By providing a specially crafted request with an unsigned assertion header containing a valid alg field, an attacker with valid client credentials can bypass the signature verification check. This allows the attacker to successfully authenticate or update a client without providing the required cryptographic proof of identity. Successful exploitation allows an attacker to circumvent administrative security policies intended to restrict client authentication to trusted assertion-based methods.

A flaw was found in the organization management component of Keycloak. A delegated administrator with permission to manage organizations can create an invitation for a non-existent email address and then retrieve the secret registration link directly through the application programming interface. By using this link, the administrator can create new user accounts and add them to the organization without having the required user management permissions or access to the invited email account. This allows an administrator to bypass security boundaries and add unauthorized members to an organization.

A flaw was found in the LDAP storage provider of Keycloak, which is used to federate user identities from external directories. The issue occurs when a delegated administrator performs a search using a specific LDAP entry Distinguished Name (DN). Due to missing validation, the system allows lookups for users located outside the configured search boundary, leading to the disclosure of account information from unauthorized parts of the directory and unintended importing of those users into local storage.

A flaw was found in the Keycloak keycloak-services component, which handles the management of identity providers. The issue occurs when a delegated administrator updates an OIDC identity provider using a masked client secret sentinel value. Due to improper validation, Keycloak reuses the existing real secret even if security-sensitive fields like the token URL have been changed, allowing an attacker to redirect and capture the secret.

A flaw was found in the keycloak-services component of Keycloak. This issue is an incomplete fix for CVE-2026-9798, where brute-force protection checks were added to the Client-Initiated Backchannel Authentication (CIBA) initiation handler but were omitted from the token redemption handler. This allows an attacker with valid client credentials to obtain access and refresh tokens for a user account that has been locked due to brute-force protection, provided the authentication request was started before the lockout occurred and was approved by the user.

A denial of service vulnerability was discovered in Keycloak metrics implementation. When user-event metrics are enabled, the EventMetricsProvider records the verbatim error message from failed account operations as a Prometheus metric label. The account consent endpoint specifically embeds caller-supplied input, such as nonexistent client IDs or invalid scope names, directly into these error messages. An authenticated attacker with manage-account or manage-consent permissions can exploit this by repeatedly calling the account consent delete endpoint with unique, randomized client ID values. Each request results in a distinct error message and a corresponding new Prometheus metric time series. This leads to unbounded metric cardinality, which can exhaust the memory of both the Keycloak instance and the connected monitoring system, resulting in a denial of service and degradation of metrics availability.

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 vulnerability was found in Keycloak where the LDAP storage provider fails to validate the search base during specific entry-DN queries. A delegated administrator with user-query permissions can invoke the admin users endpoint with a crafted query parameter (q=LDAPENTRYDN:target-dn). The LDAP provider replaces the configured users DN with the caller-supplied DN and performs an object-scope lookup. If the target object matches the user schema, Keycloak returns the UserRepresentation and may import the user into local storage. This allows an attacker to bypass organizational unit boundaries within the same LDAP directory to disclose user attributes and metadata for accounts they should not be able to access.

A flaw was found in the admin REST API of Keycloak, a solution for identity and access management. The issue occurs when a delegated administrator attempts to remove a child role from a composite role. Due to missing authorization checks, an attacker with limited administrative permissions can remove privileged roles they are not authorized to manage, leading to a loss of access for other users and administrators.

A flaw was found in the RoleContainerResource component of Keycloak. The issue occurs because certain name-based endpoints in the admin REST API do not properly enforce authorization checks when managing composite roles. This allows a delegated administrator with manage-realm permissions to remove essential child roles from built-in admin roles, potentially disrupting administrative functions within a realm.

A flaw was found in Keycloak's Fine-Grained Admin Permissions v2 (FGAP v2) implementation. When FGAP v2 is enabled, the role groups endpoints (GET /admin/realms/{realm}/clients/{clientUuid}/roles/{roleName}/groups and GET /admin/realms/{realm}/roles/{roleName}/groups) fail to correctly enforce per-group view permissions. The RoleContainerResource.getGroupsInRole() method only verifies that the caller has permission to view the role itself (auth.roles().requireView(roleContainer)). It then returns representations for all groups mapped to that role without verifying if the caller has permission to view each individual group (auth.groups().canView(group)). This allows a delegated administrator with role view access to enumerate hidden groups and retrieve their metadata, including names, paths, and custom attributes, even if direct access to those groups is correctly denied with a 403 Forbidden error.

A flaw was found in Keycloak's Authorization Services. The component responsible for matching request paths to security policies (PathMatcher) does not properly normalize URIs before comparison. By adding extra characters like a trailing slash or matrix parameters to a URL, an attacker can trick the system into applying a less restrictive security policy than intended. This allows an authenticated user to access administrative or restricted areas they should not have permission to see.

Keycloak Authorization Services resolves request URIs to protected Resources using PathMatcher (org.keycloak.common.util.PathMatcher), which performs purely lexical segment comparison with no URI normalization. Appending a matrix parameter (;x=1) or trailing / to a restricted resource URI causes it to miss the exact match and fall through to a broader, more permissive resource (e.g., the default / catch-all). An authenticated low-privilege user can obtain a granted RPT or positive authorization decision for resources the policy explicitly denies them. The vulnerability affects the UMA grant endpoint, the Protection API matchingUri resolution, and the client-side policy enforcer—all of which share the same unguarded PathMatcher.

A vulnerability was found in Keycloak-services. Special characters used during e-mail registration may perform SMTP Injection and unexpectedly send short unwanted e-mails. The email is limited to 64 characters (limited local part of the email), so the attack is limited to very shorts emails (subject and little data, the example is 60 chars). This flaw's only direct consequence is an unsolicited email being sent from the Keycloak server. However, this action could be a precursor for more sophisticated attacks.

Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-2p82-5wwr-43cw. This link is maintained to preserve external references.

Original Description

A flaw was found in Keycloak. When an Active Directory user resets their password, the system updates it without performing an LDAP bind to validate the new credentials against AD. This vulnerability allows users whose AD accounts are expired or disabled to regain access in Keycloak, bypassing AD restrictions. The issue enables authentication bypass and could allow unauthorized access under certain conditions.

A flaw was found in Keycloak. A remote, unauthenticated attacker can send a specially crafted XML input to the Security Assertion Markup Language (SAML) endpoint. This malicious input can cause high CPU usage and worker thread starvation, leading to a Denial of Service (DoS) where the server becomes unavailable.

A Missing Authorization flaw (CWE-862) was identified in the JWT Bearer authorization grant (urn:ietf:params:oauth:grant-type:jwt-bearer) in Keycloak. The vulnerability exists in the JWTAuthorizationGrantType.process function, which fails to verify the client.isConsentRequired flag or check for a stored UserConsentModel before issuing an access token. While other user-facing grants like Resource Owner Password Credentials (ROPC) explicitly refuse consent-required clients, and interactive grants verify stored consent, the JWT Bearer grant bypasses these checks entirely. To exploit this flaw, an attacker must have access to a confidential client credentials and a valid JWT assertion for a target user signed by an allow-listed Identity Provider (IdP). Successful exploitation allows an attacker to: Obtain a valid access token for a target user without their consent.

Access protected resources and APIs on behalf of the user.

Bypass administrative security policies intended to gate client access behind explicit user approval.