A flaw was found in Keycloak Policy Enforcer. This vulnerability allows any authenticated user to bypass all authorization policies, including role, scope, and User-Managed Access (UMA) permission checks. By including the configured access-denied page path within a request URL, either as a path segment or a query parameter, an attacker can gain unauthorized access to protected resources.
A vulnerability was found in Undertow where the ProxyProtocolReadListener reuses the same StringBuilder instance across multiple requests. This issue occurs when the parseProxyProtocolV1 method processes multiple requests on the same HTTP connection. As a result, different requests may share the same StringBuilder instance, potentially leading to information leakage between requests or responses. In some cases, a value from a previous request or response may be erroneously reused, which could lead to unintended data exposure. This issue primarily results in errors and connection termination but creates a risk of data leakage in multi-request environments.
A flaw was found in Keycloak. An unauthenticated remote attacker can trigger an application level Denial of Service (DoS) by sending a highly compressed SAMLRequest through the SAML Redirect Binding. The server fails to enforce size limits during DEFLATE decompression, leading to an OutOfMemoryError (OOM) and subsequent process termination. This vulnerability allows an attacker to disrupt the availability of the service.
A session fixation vulnerability in Keycloak's login-actions endpoints allows an unauthenticated attacker to pre-create an authentication session, deliver a crafted link to a victim, and claim the resulting required-action form without the victim entering any credentials. A separate endpoint, /login-actions/restart, accepts the session handle with no CSRF token or cookie ownership check, enabling the attacker to reset flow state so that SSO fires silently when the victim clicks the link. The demonstrated impact on the default Keycloak deployment is full takeover of the master-realm admin account.
A flaw was found in Keycloak. An unauthenticated attacker can exploit this vulnerability by sending a specially crafted POST request with an excessively long scope parameter to the OpenID Connect (OIDC) token endpoint. This leads to high resource consumption and prolonged processing times, ultimately resulting in a Denial of Service (DoS) for the Keycloak server.
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 flaw was found in Keycloak. Keycloak's Security Assertion Markup Language (SAML) broker endpoint does not properly validate encrypted assertions when the overall SAML response is not signed. An attacker with a valid signed SAML assertion can exploit this by crafting a malicious SAML response. This allows the attacker to inject an encrypted assertion for an arbitrary principal, leading to unauthorized access and potential information disclosure.
Description A flaw was found in Keycloak. The org.keycloak.authorization package may be vulnerable to circumventing required actions, allowing users to circumvent requirements such as setting up two-factor authentication.
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 TokenManager component of the Keycloak identity management service. When an administrator attempts to revoke tokens for a specific application (client) using a "not-before" policy, the revocation may be silently ignored if the overall security realm already has an older, non-zero revocation policy in place. This issue can allow previously issued tokens to remain valid for refreshing sessions and accessing user information even after an administrator has attempted to invalidate them. ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
A flaw was found in the Microsoft social identity provider in Keycloak. When a Microsoft identity provider is configured with a specific tenant ID, the restriction is correctly enforced for standard browser-based logins. However, the external access-token exchange endpoint fails to perform this validation. The root cause is that Keycloak calls the tenant-agnostic Microsoft Graph /me endpoint during the exchange process. It accepts the returned user profile and issues Keycloak tokens without verifying that the tenant associated with the original Microsoft token matches the configured tenant ID in the identity provider settings. An attacker with a valid Microsoft Graph access token from an arbitrary tenant can submit it to the Keycloak token exchange endpoint. Successful exploitation allows the attacker to bypass tenant restrictions, assume an identity within the Keycloak realm, and perform actions with the privileges of that identity, such as accessing protected resources or modifying user data.
A flaw was found in the keycloak-services component of Keycloak, which is used for managing authentication and authorization flows. The issue occurs when a realm administrator configures client policies to enforce specific authentication requirements on confidential clients. Due to improper evaluation of the client state during an update operation, an attacker with client management permissions can bypass these security policies by first creating a public client and then updating it to a confidential client with weaker authentication. This can result in the persistence of clients that do not comply with the intended security hardening of the realm.
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 flaw was found in the full-scope-disabled client-policy executor within the keycloak-services component. This component is responsible for enforcing security policies during client registration and configuration in Red Hat Build of Keycloak. The issue occurs because the executor only validates the fullScopeAllowed field when it is explicitly provided in a request. By omitting this field, a delegated user can bypass the policy, resulting in a client created with full scope access. This allows the client to obtain tokens with unauthorized role mappings.
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 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 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 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 keycloak-services component of Red Hat Build of Keycloak. The issue occurs because OAuth 2.0 authorization codes are not properly bound to the client that originally requested them. An attacker who can intercept an authorization code can modify it to be redeemed by their own client, potentially allowing them to obtain access tokens for a victim's identity.
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 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 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 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 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 the group search functionality of the Keycloak server's administrative API. When Fine-Grained Admin Permissions (FGAP) v2 is enabled, a delegated administrator can bypass access restrictions to view parent groups they are not authorized to see. By searching for a child group they have permission to view, the system incorrectly returns the full details of the parent group in the response, leading to the disclosure of sensitive group attributes and configuration.
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 security flaw in the IdentityBrokerService.performLogin endpoint of Keycloak allows authentication to proceed using an Identity Provider (IdP) even after it has been disabled by an administrator. An attacker who knows the IdP alias can reuse a previously generated login request to bypass the administrative restriction. This undermines access control enforcement and may allow unauthorized authentication through a disabled external provider.
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 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.