See how keycloak compares to other vendors in security performance
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 vulnerability exists in Keycloak's server distribution where enabling debug mode (--debug <port>) insecurely defaults to binding the Java Debug Wire Protocol (JDWP) port to all network interfaces (0.0.0.0). This exposes the debug port to the local network, allowing an attacker on the same network segment to attach a remote debugger and achieve remote code execution within the Keycloak Java virtual machine.
A flaw was found in Keycloak. The Dynamic Client Registration (DCR) endpoint does not properly validate authorization when processing the deprecated defaultRoles field. An authenticated attacker with client creation privileges or an Initial Access Token (IAT) can inject excessive roles into the realm's default roles configuration. This causes clients across the realm to generate bloated access tokens, resulting in performance and memory degradation that can lead to a Denial of Service (DoS).
A flaw was found in the org.keycloak.services package of Keycloak. When an authentication flow is initiated through the login-actions/reset-credentials entry point, the resulting authorization session fails to evaluate and apply client-level mandatory PKCE settings. If a user subsequently navigates back to the standard login form and completes authentication, Keycloak issues an authorization code that lacks associated code challenge metadata. Because the token endpoint validates PKCE based on the presence of metadata in the code rather than the client configuration, the code can be redeemed for tokens without a codeverifier. An attacker who intercepts this authorization code can perform a code injection attack to obtain access and refresh tokens, allowing them to impersonate the victim and access or modify protected data.
A flaw was found in the token exchange mechanism of Keycloak. When using Standard Token Exchange V2, the system issues new tokens with a fresh lifetime based on the requester clients configuration instead of limiting it to the original tokens expiration. This issue allows an authenticated requester to indefinitely extend access for service accounts by repeatedly exchanging tokens, even if the original client has been disabled by an administrator.
A flaw was found in the idp-auto-link authenticator of the keycloak-services component, which handles user identity federation. The issue occurs when Keycloak automatically links an incoming identity from an external provider to an existing local account based on an email address without verifying if the provider has validated that email. This can allow an attacker to take over a victim's account by using a matching unverified email address at a brokered provider.
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.
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 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 CPU-based Denial of Service vulnerability was found in Keycloak within the org.keycloak.saml component. The flaw exists in the way SAML XML dateTime and duration strings are parsed. When an XML document containing an excessively long string for these specific types is processed, the parser enters a resource-intensive state, consuming significant CPU cycles. An unauthenticated remote attacker can exploit this by sending crafted SAML XML payloads via HTTP POST to endpoints such as /realms/{realm}/protocol/saml, /realms/{realm}/broker/saml/endpoint, or /realms/{realm}/protocol/saml/resolve. Successful exploitation does not require valid client registration, credentials, or valid SAML signatures. The concrete impact is a sustained high CPU load on the Keycloak server, leading to service unresponsiveness and a total denial of service for authentication and authorization flows.
A flaw was found in the SAML implementation of Keycloak, an open-source identity and access management solution. The SAML Artifact Resolution and ECP SOAP endpoints do not properly limit the size or complexity of incoming XML requests. An unauthenticated remote attacker can exploit this by sending specially crafted, large XML messages that cause the server to consume excessive memory. This leads to the application running out of memory and crashing, resulting in a denial of service for all users.
A flaw was found in the Keycloak SAML adapter, specifically within the assertion validation logic in the org.keycloak.adapters.saml.profile package. The adapter accepts signed SAML Responses and Assertions without verifying that the Issuer field matches the configured identity provider entity ID. In environments where a single signing key is shared across multiple SAML issuers or tenants, an attacker who controls a sibling issuer can generate a SAML assertion signed with the shared key. By addressing this assertion to the victim application's audience and consumer service, the attacker can bypass authentication. Successful exploitation allows an attacker to impersonate any principal within the application, gain unauthorized administrative access by including specific roles in the assertion, and access or modify sensitive data and configurations within the protected application. Exploitation requires that the application trusts a signing key used by more than one issuer and that the attacker has the ability to produce assertions signed with that key.
A flaw was found in the Admin REST API of Keycloak, an open-source identity and access management solution. The endpoint used for deleting user credentials does not correctly check for fine-grained reset-password permissions. This allows a delegated administrator, who should be restricted from resetting passwords, to delete a user's password credentials, resulting in the user being unable to log in.
A flaw was found in Keycloak's Account REST API session binding mechanism. The issue exists because the sid session ID claim is not included in the blocked claim list for Dynamic Client Registration DCR protocol mappers. A malicious DCR client owner can configure mappers to substitute the azp authorized party and sid claims in their access token with values derived from user-controlled profile fields. When the Account REST API processes this manipulated token, the identity token verification resolves the user session based on the provided sid without verifying that the subject sub claim in the token matches the user associated with that session. Consequently, the API returns the victim's session data. An attacker with low privileges can exploit this to read and write a victim's account profile, change the recovery email, and perform a full account takeover via password reset.
A flaw was found in the OIDC protocol implementation of Keycloak, an open-source identity and access management solution. The issue occurs during the token refresh process when the server restores requested audiences from stored client IDs. Keycloak fails to verify if the target audience client is still enabled before issuing a new access token. This allows an application with an existing refresh token to continue obtaining valid access tokens for a disabled client, potentially bypassing administrative access controls for resource servers that rely on offline JWT validation.
A flaw was found in the Admin REST API of Keycloak, an open-source identity and access management solution. The issue occurs in the group-membership endpoints where the system fails to check if a group grants administrative privileges before allowing a user to be added. This allows a delegated administrator with limited permissions to add themselves to a high-privilege group, potentially gaining full control over the entire realm.
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 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 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 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 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.
A flaw was found in the Keycloak keycloak-services component, which handles the management of identity providers. The issue occurs when a delegated administrator updates an OIDC identity provider using a masked client secret sentinel value. Due to improper validation, Keycloak reuses the existing real secret even if security-sensitive fields like the token URL have been changed, allowing an attacker to redirect and capture the secret.
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 Identity Provider (IdP) mapper component of Keycloak, which is used to manage how user information from external services is mapped to Keycloak users. An administrator with limited permissions to manage identity providers can exploit this flaw by creating a "Hardcoded Role" mapper that assigns high-level administrative roles (like realm-admin) to themselves or others. This allows a restricted administrator to bypass security checks and gain full control over the entire realm.
A Cleartext Transmission of Sensitive Information vulnerability was found in the keycloak-services component. The issue exists in the SMTP configuration handling where setting starttls=true results in opportunistic TLS rather than mandatory TLS. An active Man-in-the-Middle attacker can strip the STARTTLS capability from the SMTP server response during the EHLO exchange. Because Keycloak does not enforce the upgrade to TLS, it proceeds to fall back to an unencrypted plaintext connection. This allows the attacker to capture SMTP authentication credentials and the full content of email messages transmitted by the server.
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 Keycloak authorization token endpoint. The vulnerability is a logic error in how UMA permission tickets are processed when multiple resources share the same name across different owners. When a requester submits a permission ticket, the endpoint performs a lookup based on the resource name and the requester identity. However, it fails to properly isolate resources by their specific owner, leading to a scope merge where permissions from all matching resource names are aggregated into a single Requesting Party Token (RPT). An authenticated attacker with low privileges can exploit this by creating a resource with the same name as a victim's resource and sharing it with themselves. This triggers the merge mechanism, allowing the attacker to obtain an RPT containing scopes belonging to the victim's resource. This bypasses the standard policy engine evaluation for the victim's resource. Successful exploitation requires that the victim has previously shared their resource.
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 Authorization Services component of Keycloak, an open-source identity and access management solution. The issue occurs in the policy evaluation endpoint, which is used by administrators to test how access policies apply to specific users. Due to missing authorization checks, a delegated administrator with limited viewing privileges can access the full profile and role information of any user in the realm, even if they are not permitted to view user details. This could lead to the exposure of sensitive information such as email addresses and assigned security roles.
A flaw was found in the Admin REST API of Keycloak, an open-source identity and access management solution. The issue occurs because the API uses a per-request in-memory cache to resolve clients by their unique identifier without verifying if the client belongs to the realm specified in the request path. This allows an administrator with limited privileges to read or modify sensitive client configurations in the master realm by accessing them through a realm they control. Successful exploitation could lead to the exposure of client credentials or the redirection of administrative login attempts to malicious sites.