A flaw was found in the group policy provider of Keycloak authorization services, which is used to manage fine-grained access control to resources. The issue occurs when the system evaluates group-based policies using tokens that only contain group names rather than full paths. If two groups in different parts of the organization share the same name, a user in the unauthorized group can be mistaken for a member of the authorized group. This can allow a user to gain unauthorized access to protected resources they should not be able to reach.

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 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 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 flaw was found in the TokenManager.NotBeforeCheck logic within keycloak-services. The vulnerability occurs when a realm has a nonzero not-before timestamp (e.g., from a previous global revocation or import) and an administrator subsequently sets a newer client-specific not-before timestamp to revoke tokens for a single client. Due to a logic error in how these policies are compared (incorrectly prioritizing the older realm-level value or failing to evaluate the newer client-level value), the client-level revocation is ignored. An authenticated attacker holding OIDC tokens (access or refresh) issued after the realm not-before but before the client not-before can continue to use these tokens. Specifically, an attacker can successfully perform token refresh requests, receive an active status from the introspection endpoint, and retrieve user claims from the UserInfo endpoint, bypassing the intended revocation. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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 HTTP Parameter Pollution vulnerability was discovered in Keycloak within the org.keycloak.protocol.saml package. The flaw exists because the SAML HTTP-Redirect binding response preserves the full query string provided in the initial authentication request. An attacker can craft an AuthnRequest with an AssertionConsumerServiceURL that already contains SAMLResponse and RelayState query parameters. If the SAML client is configured with a wildcard redirect URI and allows the attacker to control these parameters, Keycloak will append its own SAML binding parameters to the existing ones in the redirect response. This results in duplicate parameters where the attacker-controlled values appear first. An attacker can exploit this against service providers that only parse the first occurrence of a query parameter to perform login CSRF or session swapping, effectively forcing a victim to authenticate into an attacker-controlled session.

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 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 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 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 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 keycloak-services component of Keycloak, which handles OpenID Connect (OIDC) authentication flows. The issue occurs because the security check designed to prevent HTTP parameter pollution only inspects the query portion of a redirect URL and ignores the fragment portion. When a client is configured with a wildcard redirect URI, an attacker can use this to inject duplicate security parameters into the login response. If a client application is not configured correctly, it might trust the attacker's injected data instead of the real security information from Keycloak, leading to session fixation or account confusion.

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.

An information disclosure vulnerability was identified in Keycloaks OIDC token introspection endpoint. This flaw is an incomplete fix for CVE-2026-37979. While the original fix correctly enforced audience checks by marking out-of-audience tokens as inactive, it failed to sanitize the jwt field in the response when JWT introspection responses are enabled. The vulnerability exists in the keycloak-services component. When a confidential client with the client.introspection.response.allow.jwt.claim.enabled attribute set to true requests an application/jwt response, the server includes a signed JWT representation of the token even if the audience check fails. An attacker who controls a confidential client in the same realm and obtains a valid access token issued for a different client can exploit this to: Recover sensitive claims and attributes from lightweight or opaque tokens. Bypass audience-based access control mechanisms intended to restrict introspection metadata. Access internal identity information (roles, groups, user attributes) they are not authorized to view.

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 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 flaw was found in the role-users endpoint of the keycloak-services library, which is the core component of the Keycloak identity and access management solution. The issue occurs because the system fails to check if an administrator has permission to view individual users when listing members of a role. This allows a restricted administrator to see private information, such as names and email addresses, for users they should not be able to access.

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 flaw was found in the Keycloak Admin REST API, which is used to manage security realms and clients. The issue occurs when the system processes requests for rotated client secrets that are stored in a secure vault. Due to improper boundary enforcement, a delegated administrator with view-only permissions can retrieve the actual resolved secret instead of the vault placeholder, leading to the exposure of sensitive credentials.

A sensitive information disclosure flaw was found in the Keycloak Admin REST API. The vulnerability exists in the GET /admin/realms/{realm}/clients/{clientUuid}/client-secret/rotated endpoint. When a confidential client is configured to use a vault-backed rotated secret (e.g., using a placeholder like ${vault.rotated-secret}), the endpoint returns the resolved plaintext value from the vault instead of the placeholder string. This issue specifically affects the rotated secret and not the primary client secret. Exploitation requires the attacker to have high privileges, specifically the realm-management:view-clients role. A successful attack allows a delegated administrator to bypass vault security boundaries and obtain usable client credentials, which could be used to impersonate the affected client.

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.