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 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 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 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 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 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 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 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 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 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 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 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. When the JSON Web Token (JWT) authorization grant preview feature is enabled and a user account is disabled, Keycloak fails to validate the user’s disabled status during JWT authorization grant processing. A remote attacker with low privileges can exploit this improper access control vulnerability by presenting a valid assertion token from an external identity provider to obtain a JWT for a disabled user. This allows unauthorized access to sensitive resources.
A flaw was found in Keycloak. When the JSON Web Token (JWT) authorization grant preview feature is enabled and a user account is disabled, Keycloak fails to validate the user’s disabled status during JWT authorization grant processing. A remote attacker with low privileges can exploit this improper access control vulnerability by presenting a valid assertion token from an external identity provider to obtain a JWT for a disabled user. This allows unauthorized access to sensitive resources.
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 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 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 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 vulnerability was found in 3Scale when using with Keycloak 15 (or RHSSO 7.5.0) and superiors. When the authtype is use3scaleoidcissuerendpoint, Token Introspection policy discovers the Token Introspection endpoint from the tokenintrospectionendpoint field, but the field was removed on RH-SSO 7.5. As the result, the policy doesn't inspect tokens; it determines that all tokens are valid.
Using an alternate authtype: authtype: clientid+clientsecret. Disabling the policy entirely might be a temporary solution if the alternate {{authtype is not feasible for some reason. The only purpose the token introspection endpoint serves is for sessions which are revoked in RH SSO before the standard TTL expires via the exp claim.
Description A flaw was found in Keycloak. This JWT algorithm confusion vulnerability in the JWT Authorization Grant flow allows an attacker with valid client credentials to bypass signature verification. By forging an assertion, the attacker can create unauthorized access tokens. This enables the attacker to impersonate any federated user linked to the affected Identity Provider, leading to unauthorized access and potential privilege escalation.
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.
Description A flaw was found in Keycloak. A remote attacker with administrative privileges, specifically those with manage-client permission or access to client registration endpoints, could bypass client Uniform Resource Identifier (URI) validation. This is achieved by registering a malicious client with a specially crafted redirect URI using a case-insensitive javascript: or data: scheme. This Cross-Site Scripting (XSS) vulnerability allows for arbitrary code execution in the Keycloak origin when a victim clicks the crafted link, such as in the logout flow or the Admin Console.
Description A flaw was found in Keycloak. A realm administrator with the "manage-realm" role can exploit this vulnerability by submitting an arbitrary filesystem path as a keystore parameter when creating a key provider component. This allows the administrator to probe arbitrary filesystem paths, determining which files exist and are readable by the Keycloak process. This information disclosure could be used to identify high-value targets for follow-on attacks.
Description A flaw was found in Keycloak's client registration service. A remote attacker, possessing a previously issued Registration Access Token (RAT), could exploit this vulnerability to re-enable a client that an administrator had explicitly disabled. This bypasses security controls, allowing the attacker to reset the client's secret and potentially regain privileged API access. The primary impact includes unauthorized information disclosure and potential integrity compromise.
A flaw was found in Keycloak. This authentication vulnerability allows a remote attacker to replay ExecuteActionsActionToken tokens within Keycloak's WebAuthn (Web Authentication) flow. By intercepting an execute-actions email link, an attacker can register their own authenticator to a victim's account. This leads to unauthorized enrollment of a hardware-backed credential, enabling persistent account takeover.