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. An authenticated administrator with the manage-clients role can exploit a Time-of-check to time-of-use (TOCTOU) vulnerability in the name-based admin role checks. This allows the attacker to escalate their privileges to realm-admin for all users within the realm, granting them extensive control over the system. The composite role relationship persists even after the attacker's own permissions are revoked and across system reboots.
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 the SAML broker component of Keycloak, an identity and access management solution. When configured as a SAML broker using the IdP-Initiated flow, Keycloak fails to enforce the OneTimeUse condition in SAML assertions. This allows an attacker who captures a valid, unused assertion to replay it multiple times. Successful exploitation could allow an attacker to hijack a user's session and gain unauthorized access to the system as that user.
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 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. When the JSON Web Token (JWT) authorization grant preview feature is enabled and a user account is disabled, Keycloak fails to validate the user’s disabled status during JWT authorization grant processing. A remote attacker with low privileges can exploit this improper access control vulnerability by presenting a valid assertion token from an external identity provider to obtain a JWT for a disabled user. This allows unauthorized access to sensitive resources.
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 Broken Access Control vulnerability was identified in Keycloaks Fine-Grained Admin Permissions V2 (FGAP V2) implementation. The flaw exists in the POST /admin/realms/{realm}/users endpoint, where the server fails to validate group membership permissions within the user creation payload. While Keycloak correctly enforces manage-membership scopes for existing users, it misses this check during the initial user creation process. A sub-administrator with user create scope but restricted group manage-membership scope can successfully assign a new user to unauthorized groups by including them in the creation request. Concrete impact: An attacker with sub-admin privileges can elevate the permissions of new users, grant them access to restricted data by placing them in sensitive groups, and bypass the security boundaries established by FGAP V2.
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 flaw was found in the SAML protocol implementation of Keycloak, an open-source identity and access management solution. The issue occurs when Keycloak handles SAML authentication requests using the HTTP-Redirect binding. If a client is configured with a wildcard redirect URL, an attacker can craft a request that includes malicious parameters. When a user authenticates, Keycloak appends its legitimate response to the attacker's parameters. This can cause some service providers to process the attacker's data instead of the real login information, potentially leading to a user being logged into the wrong account.
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 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 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 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 Keycloak, an open-source identity and access management solution. When a user account is temporarily locked due to repeated failed login attempts, an attacker with valid client credentials can exploit the Client-Initiated Backchannel Authentication (CIBA) flow to bypass this brute-force protection. This allows continued authentication attempts and token issuance even when the account should be locked, potentially enabling further unauthorized access attempts.
A flaw was found in Keycloak, an open-source identity and access management solution. When a client application is configured to accept broad redirect Uniform Resource Identifiers (URIs), a remote attacker can manipulate the authentication process by crafting a special web address. If a user clicks this link, the client application might incorrectly prioritize attacker-controlled information over legitimate data. This vulnerability, known as HTTP parameter pollution, could allow an attacker to bypass security measures or gain unauthorized access to resources.
A flaw was found in Keycloak. When a JSON Web Encryption (JWE) encrypted request object is submitted, Keycloak may incorrectly process unsigned claims if the decrypted content is raw JSON, bypassing the configured signature policy. This allows a remote attacker to submit unauthorized claims, leading to a compromise of data integrity within the OpenID Connect (OIDC) authorization flow. While a redirect URI allowlist acts as a compensating control, this vulnerability violates OIDC Core and Financial-grade API (FAPI) signing requirements.
A flaw was found in Keycloak. A highly privileged user with manage-clients permission can exploit this vulnerability by injecting a hardcoded role mapper into any client. This action allows the user to bypass existing scope restrictions and inject the realm-admin role into generated tokens, resulting in privilege escalation and full administrative access to the realm.
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 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 identified in Keycloak where the SAML Identity Provider IdP metadata parser incorrectly configures signature validation. When a metadata document is imported that sets WantAuthnRequestsSigned to false and includes a KeyDescriptor without an explicit use attribute, the parser stores the certificate but fails to enable the validateSignature setting. As a result, the broker endpoint /realms/realm/broker/alias/endpoint does not verify the cryptographic signature of incoming SAML responses. An unauthenticated remote attacker can exploit this by capturing a valid RelayState and SAML request ID through a standard login flow and then submitting a forged, unsigned SAML response. By providing the external SAML NameID of a target user, the attacker can successfully authenticate as that user. Successful exploitation allows an attacker to: Bypass authentication mechanisms.
Impersonate any user who has a federated identity link.
Access and modify data belonging to the compromised user account.
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. An IDOR (Broken Access Control) vulnerability exists in the admin API endpoints for authorization resource management, specifically in ResourceSetService and PermissionTicketService. The system checks authorization against the resourceServer (client) ID provided in the API request, but the backend database lookup and modification operations (findById, delete) only use the resourceId. This mismatch allows an authenticated attacker with fine-grained admin permissions for one client (e.g., Client A) to delete or update resources belonging to another client (Client B) within the same realm by supplying a valid resource ID.
The keycloak guides recommend to not expose /admin path to the outside in case the installation is using a proxy (see https://www.keycloak.org/server/reverseproxy#exposedpathrecommendations ). The problem is that, at least ha-proxy, can be tricked to using relative/non-normalized paths to access the /admin application path relative to /realms (which should be exposed). For example:
curl --path-as-is http://localhost:7080/realms/../admin/master/console/#/master/info <http://localhost:7080/admin/master/console/#/master/info>
The admin path requires authentication but, in the end, the final customer is exposing a path that he thinks is not accessible. Also note that this is more an issue in ha-proxy than keycloak. Keycloak does not even document how to configure ha-proxy or any other proxy, it just recommends to not expose the /admin app. For example mod-proxy correctly manages non-normalized URLs, because it normalizes the path before to be sure it's inside the prefix-path.
Nevertheless we have reached the conclusion that keycloak should return an error by default for non-normalized URLs.
The installation should use a proxy configuration with ha-proxy with the common configuration.
The LDAP testing endpoint allows to change the Connection URL independently of and without having to re-enter the currently configured LDAP bind credentials. An attacker with admin access (permission manage-realm) can change the LDAP host URL ("Connection URL") to a machine they control. The Keycloak server will connect to the attacker's host and try to authenticate with the configured credentials, thus leaking them to the attacker. As a consequence, an attacker who has compromised the admin console/compromised a user with sufficient privileges can leak domain credentials and can now attack the domain.
This requires: Access to the REST endpoint and the admin user needed with manage-realm permission (full access to LDAP configuration and all identity providers).
Version affected: <= 24.0.5
A vulnerability was found in Keycloak. A specially crafted URL can be constructed where the referrer and referreruri parameters are made to trick a user to visit a malicious webpage; this vulnerability is called an Open Redirect.
A trusted URL can fool both users and automation into believing that the URL is safe when in fact it redirects to a malicious server. This can result in a victim inadvertently trusting the destination of the redirect, potentially leading to a successful phishing attack or other types of attacks.
Once a crafted URL is made, it can be sent to a Keycloak admin via email for example, and it will trigger this vulnerability when the user visits the page and clicks the link. A malicious actor can target users whom they know are Keycloak admins for further attacks in this way. It may be possible to bypass other domain-related security checks, such as supplying this as a OAuth redirect uri. Finally, the malicious actor can further obfuscate the redirecturi using URL encoding, to hide the text of the actual malicious website domain.
Keycloak allows arbitrary URLs as SAML Assertion Consumer Service POST Binding URL (ACS), including JavaScript URIs (javascript:). Allowing JavaScript URIs in combination with HTML forms leads to JavaScript evaluation in the context of the embedding origin on form submission. Thus, Keycloak is vulnerable to Cross-Site Scripting (XXS) by registering a JavaScript URI as Assertion Consumer Service POST Binding URL.
A vulnerability was found in Keycloak. A user with high privileges could read sensitive information from a Vault file that is not within the expected context.
In Keycloak 24.0.8, a vulnerability allows unauthorized file access through path traversal in file vault configurations due to permissive regex validation. This weakness allows reading any file to the Keycloak server, but the admin user will not be able to access the contents unless they have also compromised the remote system that the password/secret is intended to be sent to. In practical terms, the only information leaked to the admin user is the existence of the file.
Version affected: <= 26.0.2