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 state-based policy bypass vulnerability was discovered in Keycloak's client policy engine. The flaw exists in the way the access-type condition evaluates UPDATE operations. Specifically, the condition checks the old client state instead of the proposed new state during an update. An attacker with low privileges, such as delegated client management permissions or a valid dynamic registration token, can exploit this by creating a public client and subsequently updating it to a confidential client. Because the policy engine still perceives the client as public during the update process, it fails to trigger the confidential-client policy profile. This allows the attacker to configure a confidential client with weak authentication (e.g., client-secret) even when the realm policy mandates stronger methods like client-jwt. Successful exploitation allows an attacker to persist non-compliant confidential clients, undermining realm-level security hardening.

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 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 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 Missing Authorization vulnerability was found in the Keycloak full-scope-disabled client-policy executor. When the executor is configured with auto-configure disabled, it fails to properly validate client creation or update requests that omit the fullScopeAllowed field. Because the server defaults to fullScopeAllowed=true for non-consent clients, an attacker with delegated client creation privileges can bypass the intended restriction. Successful exploitation allows an attacker to create a client that possesses full scope access within the realm, even when a policy is active to prevent it. This results in the issuance of tokens containing role mappings that should have been restricted by the realm policy.

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 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 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 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 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 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 missing authorization filter flaw was found in Keycloaks role-users REST API endpoint. When an authenticated user with restricted administrative privileges such as query-users and view-realm requests the list of users assigned to a specific role via GET /admin/realms/{realm}/roles/{role-name}/users, the system returns the full representation of all member users. The root cause is that the RoleResource.getRoleUserMembers method verifies the callers permission to view the role but fails to apply the per-user view filter to the resulting list. This allows a delegated administrator to bypass intended access restrictions and perform unauthorized enumeration of user PII, including usernames, email addresses, and full names, for any user assigned to a role the administrator can view.

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.

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.

An incorrect authorization flaw was found in the Keycloak admin REST API endpoints responsible for removing child roles from composite roles. Specifically, the DELETE /admin/realms/{realm}/roles-by-id/{role-id}/composites and DELETE /admin/realms/{realm}/roles/{role-name}/composites endpoints only verify if the caller has manage permissions on the parent role container. They fail to enforce the per-child role check that is correctly implemented in the corresponding add operation. To exploit this, an attacker must have a delegated admin account with manage permissions on a parent role container (such as manage-realm or Fine-Grained Admin Permissions on a specific role container). No user interaction is required. A successful attack allows a delegated administrator to remove privileged child roles (like realm-admin) from existing composites. This results in stripping those roles from all users or groups assigned to the composite, effectively degrading the privileges of other administrators or disrupting realm-wide functionality by modifying default roles.

An Information Exposure vulnerability was found in the GET /admin/realms/{realm}/authentication/config/{id} endpoint of Keycloak. The root cause is located in the ModelToRepresentation.toRepresentation method, which copies the configuration map without filtering or masking entries marked as secret in the provider metadata. Consequently, an authenticated user with the view-realm role can retrieve raw secret values, such as secret.key for reCAPTCHA and api.key for reCAPTCHA Enterprise. Additionally, these unmasked secrets are serialized into admin events, making them visible to any user with permission to read administrative logs. An attacker can use these secrets to undermine the integrity of bot-detection mechanisms in the affected realm.

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 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 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 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 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 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 vulnerability was identified in Keycloak's admin API where the secret masking boundary is bypassed for OIDC identity-provider client secrets. The flaw exists in the IdentityProviderResource.updateIdpFromRep() function. When a PUT request is made to update an IdP configuration and the clientSecret is set to the masked sentinel value (ComponentRepresentation.SECRETVALUE), Keycloak unconditionally copies the actual stored secret into the update. The root cause is a lack of validation to check if security-sensitive destination fields—specifically tokenUrl, clientId, or clientAuthMethod}}—have been modified in the same request. A delegated IdP manager with {{manage-identity-providers permissions can exploit this by changing the tokenUrl to an attacker-controlled endpoint while providing the masked secret sentinel. Keycloak will then bind the real secret to the new, malicious endpoint, allowing the attacker to capture the secret through normal broker traffic.

An authorization bypass vulnerability exists in the GroupResource.getSubGroups() function of org.keycloak.services.resources.admin. The issue stems from a logic error where the auth.groups()::canView filter is only applied when the legacy permission schema is active. Under FGAP v2, AdminPermissionsSchema.SCHEMA.isAdminPermissionsEnabled(realm) returns true, causing the filter to be skipped. An attacker with a delegated admin role and Groups:view permission on a parent group can exploit this by calling the .../groups/{parentGroupId}/children endpoint. Successful exploitation allows the attacker to: Enumerate hidden child groups under the parent group.

Disclose child group UUIDs, names, and paths.

Access subgroup counts and custom attributes of unauthorized child groups.

Confirm the bypass via the access.view=false flag returned in the unauthorized data.

A write-path authorization bypass vulnerability exists in the ClientResource.addDefaultClientScope() and related endpoints in Keycloak when adminPermissionsEnabled is set to true (FGAP v2). The flaw stems from insufficient permission validation: the code only verifies that the caller has manage permissions on the target client but fails to check if the caller has any permissions (such as view or map) on the client scope being attached. An attacker with a delegated admin role (Clients:view and Clients:manage on at least one client) can exploit this by discovering the UUID of a "hidden" client scope (one they are otherwise restricted from accessing). By calling the client scope assignment endpoints, the attacker can successfully link these hidden scopes to their managed client. Concrete Impact: Unauthorized Claim Injection: Attacker can inject claims from restricted client scopes into end-user access tokens.

Authorization Bypass in Relying Apps: Applications relying on Keycloak token claims for internal authorization decisions may grant unauthorized access based on the injected claims.

Data Exposure: If the hidden scope contains sensitive hardcoded claims or mappers, these are exposed to the end-user and the relying application.

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. This JWT algorithm confusion vulnerability in the JWT Authorization Grant flow allows an attacker with valid client credentials to bypass signature verification. By forging an assertion, the attacker can create unauthorized access tokens. This enables the attacker to impersonate any federated user linked to the affected Identity Provider, leading to unauthorized access and potential privilege escalation.

A JWT algorithm confusion vulnerability was found in Keycloak's JWT Authorization Grant flow . A flaw in the signature verification logic allows an attacker with valid client credentials to submit a forged assertion using alg=HS256 with the Identity Provider's public key bytes as the HMAC secret, bypassing asymmetric signature verification. This enables the attacker to mint access tokens and impersonate any federated user linked to the affected IdP. The vulnerability requires an IdP configured with jwtAuthorizationGrantEnabled=true, a hardcoded public key (useJwksUrl=false), and no pinned assertion signature algorithm (the default).

A flaw was found in Keycloak. A remote attacker with high privileges, such as a realm administrator configuring a malicious Lightweight Directory Access Protocol (LDAP) server or an attacker compromising an upstream LDAP server, could exploit this vulnerability. By sending a malformed LDAP password policy response during a password authentication request, the attacker can trigger an OutOfMemoryError. This causes the Keycloak Java Virtual Machine (JVM) to terminate, leading to a denial of service (DoS) for all realms on the affected node.