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 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 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 client registration component of Keycloak, an open-source identity and access management solution. When a vault provider is used to store sensitive information, an authenticated client owner can use a specially crafted reference to trick the system into revealing secrets. By updating a client secret to point to a vault entry and then requesting the client configuration, the owner can see the secret value in plain text. This could lead to the exposure of sensitive credentials that the user should not be able to access.

A vulnerability was found in Keycloak where the JWT Authorization Grant (RFC 7523) fails to enforce login restrictions configured on OIDC or Google identity providers. Specifically, restrictions such as Filtered by claims or Hosted Domain are bypassed when the grant is processed. An authenticated confidential client with the JWT Authorization Grant enabled can submit a signed assertion for an existing federated user and receive realm tokens, even if the assertion contains claims that violate the identity provider's security policies. An attacker with client credentials and a validly signed assertion can bypass intended access controls to obtain unauthorized realm access for federated users.

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 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 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 org.keycloak.protocol.oidc package of Keycloak. The OAuth 2.0 Device Authorization Grant flow does not correctly enforce the per-client minimum.acr.value setting. While the standard Authorization Code flow properly requires multi-factor authentication (MFA) when this setting is present, the Device Authorization flow allows authentication to complete at a lower Level of Assurance (LoA 1, password only). The root cause is a missing validation step in the device grant code path to ensure the resulting authentication context class reference (ACR) meets the client's configured minimum. An attacker with knowledge of a user's primary credentials can exploit this to bypass MFA requirements. Successful exploitation allows the attacker to obtain a valid access token with the client's scoped roles and use it to perform unauthorized actions via the Keycloak Admin REST API, such as managing users or modifying realm configurations.

A Blind Server-Side Request Forgery (SSRF) vulnerability was discovered in Keycloak within the org.keycloak.services.x509 component. When the X.509 client-certificate authenticator is enabled with CRL Distribution Point (CRLDP) or OCSP revocation checking, Keycloak attempts to fetch the CRL and OCSP responder URLs embedded in the presented client certificate before performing trust revalidation. An unauthenticated attacker can exploit this by presenting a crafted certificate containing attacker-controlled URLs in the CRL-DP or OCSP Authority Information Access (AIA) extensions. This induces the Keycloak server to initiate outbound HTTP GET or POST requests to arbitrary internal or external endpoints. A secondary exploitation vector exists when a proxy-header cert-lookup provider is configured with proxy-trusted-addresses unset, allowing the attack to be performed via plain HTTP headers without a valid TLS connection. Successful exploitation allows an attacker to probe internal network resources or interact with internal services that are otherwise unreachable from the outside.

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 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 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 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 vulnerability was found in Keycloaks Standard Token Exchange V2 implementation within the org.keycloak.protocol.oidc.tokenexchange package. The root cause is that exchanged tokens are issued with a new access-token lifetime derived from the requester clients configuration, failing to bound the new tokens expiration by the subject tokens original expiration time. For service accounts which lack a session ID, this creates a chain where a requester client can indefinitely refresh access by performing a new exchange before the current token expires. The vulnerability persists even if an administrator disables the origin client, as Keycloak continues to accept exchanges of previously exchanged tokens associated with the requester client. An attacker with a valid service-account token and the requester clients credentials can maintain persistent, unauthorized access to resources beyond the intended security lifecycle.

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

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

An information disclosure vulnerability was discovered in Keycloak within the Authorization Services policy evaluation endpoint. The flaw exists in the org.keycloak.services.resources.admin.fgap package, specifically where the endpoint processes policy evaluation requests. The root cause is a failure to verify the callers permissions before resolving a user identity. When a delegated administrator with authorization viewing privileges (such as the view-authorization role) sends a request to the policy evaluation endpoint with a specific userId, the system constructs an identity token (RPT) for that user. This token, which includes the users email, full name, and effective role mappings, is returned in the response field. Exploitation requires the attacker to have administrative access to a resource server but lacks the view-users permission. A successful attack allows the administrator to bypass intended access controls to read sensitive profile data and role assignments for any user within the target realm.

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 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 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 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 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 org.keycloak.broker.saml package of Keycloak. The SAML identity broker incorrectly handles signed assertions that contain only a holder-of-key SubjectConfirmation. When a bearer confirmation is absent, the broker skips the necessary subject-confirmation validation instead of enforcing proof of possession for the bound key. Exploitation requires that Keycloak is configured as a SAML broker with a trusted upstream provider that issues holder-of-key assertions. An attacker must obtain a valid signed assertion issued for a victim. No authentication or user interaction is required for the replay attack. Successful exploitation allows an attacker to bypass authentication mechanisms, impersonate any victim for whom they have a valid assertion, gain full access to the victim account and downstream applications, and issue new downstream assertions for the victim identity.

A flaw was found in the first broker login flow of Keycloak. When a user confirms an account-linking request from a different browser, a temporary proof is created to validate the link. However, this proof is not properly cleared after the link is established or when the user later manually removes the link. An attacker who controls the external identity can exploit this leftover proof to silently re-establish the link and gain unauthorized access to the victims account without any further confirmation.