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. 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. 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.

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 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 Keycloaks Pushed Authorization Request PAR implementation. The single-use enforcement for PAR request URIs, as required by RFC 9126 section 4, is bypassed when using the silent authentication path prompt=none. When an existing SSO session is present, the authorization endpoint short-circuits directly to the successful-flow redirect handler. In this specific code path, the PAR consumption logic is never triggered, meaning the pushed request object is not removed from storage after use. Exploitation requires that the realm has PAR enabled, the attacker has valid client credentials to push an authorization request, and an active SSO session exists for the target user. A successful attacker can replay the requesturi multiple times to mint distinct, fully redeemable authorization codes for the same user without requiring the resource owner to re-authenticate. This allows for unauthorized token generation and violates the single-use guarantee required for FAPI-2 and RFC 9126 compliant deployments.

A flaw was found in the Micrometer user-event metrics listener of Keycloak, a solution for integrated identity and access management. The issue occurs when the listener is configured to include the idp tag. An unauthenticated attacker can send requests to the identity broker login endpoint using arbitrary provider aliases, causing the system to create an unlimited number of metric time series. This can lead to excessive memory consumption and degrade the performance of both the server and its monitoring tools.

A flaw was found in the user update mechanism of the Keycloak Admin REST API. When Fine-Grained Admin Permissions are enabled, the system fails to check for specific password reset authorizations during a general user profile update. This allows a delegated administrator, who should be restricted from resetting passwords, to change a user's credentials and take over their account.

A flaw was found in the authentication session management of Keycloak, an identity and access management solution. The issue occurs when an administrator enforces a stronger authentication flow, such as mandatory two-factor authentication (2FA) setup, through a client policy. A user can bypass this requirement by manually visiting a specific session restart web link during the login process. This action clears the internal markers that track the required security steps, allowing the user to log in with only a password and gain access without completing the mandated 2FA setup.

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 flaw was found in Keycloak. By setting a verification policy to 'ALL', the trust store certificate verification is skipped, which is unintended.

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 Missing Authorization vulnerability was discovered in Keycloaks Admin REST API. The flaw exists in the way the API resolves client resources using the per-request in-memory cache in the org.keycloak.models.cache.infinispan component. The cache is keyed by client UUID alone and does not perform a realm ownership validation when a resource is retrieved. An authenticated attacker with the create-realm role in the master realm can exploit this by creating a new realm and then addressing a master realm client using its UUID through the attacker-controlled realms API path. If the master realm client is present in the per-request cache, the system returns or updates the master client instead of enforcing realm boundaries. Successful exploitation allows an attacker to: Read client details, including credentials of confidential clients in the master realm.

Overwrite client configurations, such as injecting arbitrary redirect URIs into built-in master clients like admin-cli or security-admin-console.

Turn the master authorization endpoint into an open redirect.

Potentially affect other resource types that utilize the same per-request cache pattern.

A Missing Authorization flaw was found in the Keycloak Admin REST API. The endpoint for deleting user credentials (DELETE /admin/realms/{realm}/users/{id}/credentials/{credentialId}) only verifies generic user management permissions (requireManage) and fails to enforce fine-grained reset-password authorization (requireResetPassword). This issue affects deployments where Fine-Grained Admin Permissions (FGAP) are enabled. An attacker with delegated administrator privileges, who is granted manage permissions but explicitly denied reset-password authority via a negative policy, can bypass this restriction. By invoking the credential deletion endpoint, the attacker can successfully delete stored password credentials for managed users. The concrete impact includes: Deleting a user's primary authentication credentials.

Causing account lockout for the victim user.

Performing a targeted denial of service against managed users.

A flaw was found in the SAML Redirect Binding implementation of Keycloak, an open-source identity and access management solution. The issue occurs because the custom DEFLATE compression and decompression helpers fail to release native zlib memory after use. An unauthenticated attacker can exploit this by sending repeated malformed SAML requests, leading to native memory exhaustion and a denial of service.

A flaw was found in Keycloak. A user holding only the impersonation realm-management client role can impersonate any enabled, non-service-account user in the realm, including full realm administrators. The impersonation endpoint restricts service accounts as targets but performs no privilege-level check on the target user. After impersonating an administrator, the attacker obtains a valid SSO session and can exchange it for a fully signed access token via a standard OIDC authorization-code flow, gaining complete administrative control over the realm (read/write all users, clients, roles, password resets). The impersonation role is designed as a lesser delegation for support staff, and this flaw defeats that separation.

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 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 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 where the theme localization endpoints (/resources/master/common/{locale} and /admin/{realm}/console/messages.json) fail to validate or limit the locale tags provided in the request. Each unique locale tag results in a new entry being created in an unbounded in-memory cache within the theme message system. An unauthenticated remote attacker can exploit this by sending a high volume of HTTP GET requests containing unique BCP 47 locale tags. Because the cache is permanent and has no size limit, this leads to continuous heap memory consumption. Successful exploitation allows an attacker to exhaust the JVM heap memory, leading to an OutOfMemoryError and causing the Keycloak service to terminate, resulting in a complete denial of service.

A flaw was found in Keycloak. A user holding only the impersonation realm-management client role can impersonate any enabled, non-service-account user in the realm, including full realm administrators. The impersonation endpoint restricts service accounts as targets but performs no privilege-level check on the target user. After impersonating an administrator, the attacker obtains a valid SSO session and can exchange it for a fully signed access token via a standard OIDC authorization-code flow, gaining complete administrative control over the realm (read/write all users, clients, roles, password resets). The impersonation role is designed as a lesser delegation for support staff, and this flaw defeats that separation.

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 Keycloak's Device Authorization Grant (RFC 8628) flow. The token redemption path in the DeviceGrantType class verifies the user.isEnabled status but fails to consult the BruteForceProtector to check for temporary lockouts. Because Keycloak's brute-force mechanism does not set the enabled flag to false during a temporary lockout, a locked user successfully passes the check. An attacker who possesses a surviving SSO browser session for a target account (established before the lockout) can complete the device verification and consent flow without being prompted for re-authentication. Consequently, the token endpoint issues a valid access token and refresh token while the account remains in a brute-force-locked state. This vulnerability represents a failure to include the Device Authorization Grant path in the fixes previously implemented for CIBA (CVE-2026-9798 and CVE-2026-16103).

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 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 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 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.