A flaw was found in Keycloak protocol mapper authorization and sessionless token identity resolution. A user holding manage-clients permission on an OIDC client can add hardcoded-claim protocol mappers that override the sub and preferredusername claims of that client service-account token. Because client-credentials tokens are sessionless by default (no sid), Keycloak reconstructs the authenticated identity from the post-mapper claims. If the sub claim is unresolvable, Keycloak falls back to the preferredusername claim and resolves the identity of a real realm administrator. Exploitation requires the attacker to have manage-clients permissions and knowledge of a realm administrator username or UUID. Successful exploitation allows the attacker to bypass the role-stripping defenses of CVE-2026-4629 by substituting the authenticated UserModel itself. An attacker can perform any action available to a realm administrator via the Admin REST API, including enumerating users, creating new users, and deleting users.

A flaw was found in Keycloak where the Dynamic Client Registration (DCR) policy Allowed Protocol Mapper Types fails to validate the configuration of protocol mappers, specifically the claim.name field. While the policy restricts the mapper types that can be used, it does not prevent an attacker from configuring allowed mappers (such as User Property or User Attribute mappers) to write to reserved identity claims. An attacker with a valid Initial Access Token (IAT) and a standard realm account can register a new client and configure mappers to map their own editable profile attributes to the sub and aud claims. When the attacker authenticates via this registered client, Keycloak issues access tokens, ID tokens, and UserInfo responses signed by the realm's active key where the sub claim contains an arbitrary user's UUID and the aud claim contains an arbitrary audience value. This allows the attacker to forge identity tokens that pass standard relying-party validation, leading to potential impersonation and unauthorized access to resource servers. This is a residual gap in the fix for CVE-2026-16102.

A flaw was found in the SAML brokering component of Keycloak, an identity and access management solution. The issue occurs when Keycloak acts as an intermediary between an upstream identity provider and downstream services. Keycloak fails to respect specific security instructions called ProxyRestrictions in the login messages it receives. This allows a user to log into downstream services even when the original identity provider explicitly forbade further sharing of the login session. As a result, users can bypass security boundaries intended to limit where their identity can be used.

A flaw was found in the SAML 1.1 assertion parser of Keycloak, a tool used for identity and access management. The issue occurs when the parser handles a specific element called AuthorityBinding within an authentication statement. Due to an incomplete fix for a previous vulnerability, the parser can enter an infinite loop that consumes all available memory, causing the entire Keycloak service to crash and become unavailable to users.

A flaw was found in the Keycloak Organization identity-first login flow. The vulnerability is caused by a failure to clear the SSO re-authentication flag (SSOAUTH note) when a flow transition occurs, such as moving to the reset-credentials or registration path, even though the authenticated user is removed from the authentication session. An attacker with valid credentials in two or more organizations can exploit this by initiating an organization-scoped authorization request, triggering a flow transition, and then submitting a victim's username. The Organization authenticator incorrectly trusts the stale re-authentication flag as valid proof of identity for the new username. Successful exploitation allows a remote attacker with Low privileges to perform a full account takeover, obtaining the victim's authorization code, access tokens, and a valid SSO session usable against downstream applications.

A flaw was found in the authentication session handling of the keycloak-services component in Keycloak. The issue occurs because the system fails to verify if an authenticator is valid for the current authentication flow when switching between the standard authentication path and the reset credentials path. An authenticated attacker can exploit this by triggering a race condition during the credential reset process to associate their successful authentication state with another user's session. This can result in the attacker gaining full access to the victim's account and changing their password.

A flaw was found in Keycloak where an authenticated attacker with delegated client management permissions (manage-clients) can achieve arbitrary code execution. When a client is created with authorization services enabled and an authorizationSettings payload is provided in the same request, Keycloak sets an internal session attribute to allow the creation of a default policy but fails to clear it. This mechanism can be abused to supply an inline JavaScript policy during client import, bypassing the security control that normally disables script uploads. When the policy is subsequently evaluated during a User-Managed Access (UMA) authorization request, the injected JavaScript executes within the Keycloak server JVM process. This allows an attacker to escape the delegated administrator's realm boundary and perform actions such as reading sensitive host data, modifying configurations for other realms, or causing a complete system shutdown.

A flaw was found in the SAML HTTP-Redirect binding implementation of Keycloak. The issue occurs because the server processes percent-encoded parameter names (like %53AMLResponse) while the signature verification logic only checks literal parameter names. An attacker can use this discrepancy to provide a crafted, unsigned SAML message that the server processes instead of a legitimately signed one, leading to full account takeover of federated users.

A flaw was found in Keycloak where an authenticated attacker with delegated client management permissions (manage-clients) can achieve arbitrary code execution. When a client is created with authorization services enabled and an authorizationSettings payload is provided in the same request, Keycloak sets an internal session attribute to allow the creation of a default policy but fails to clear it. This mechanism can be abused to supply an inline JavaScript policy during client import, bypassing the security control that normally disables script uploads. When the policy is subsequently evaluated during a User-Managed Access (UMA) authorization request, the injected JavaScript executes within the Keycloak server JVM process. This allows an attacker to escape the delegated administrator's realm boundary and perform actions such as reading sensitive host data, modifying configurations for other realms, or causing a complete system shutdown.

A flaw was found in the UserManagedPermissionService of the Keycloak authorization server. The UMA Protection API, which manages user permissions, fails to validate the resourceType field when a user creates a new policy. This allows an attacker to create a policy that applies to resources owned by other users, potentially leading to unauthorized access or modification of sensitive data across the entire realm.

A flaw was found in Keycloak's SAML 1.1 XML parsing logic within the keycloak-saml-core component. When parsing the ds:KeyInfo element in SAML 1.1 assertions, the StAX-based parser loops over child elements but only contains logic to handle specific expected tags such as ds:EncryptedKey, ds:X509Data, and ds:KeyValue. The parser lacks a fallback branch to consume or reject other valid child elements like ds:KeyName. Consequently, the parser repeatedly peeks at the unhandled element without advancing, causing the processing thread to enter an infinite loop spinning at 100% CPU. An unauthenticated remote attacker can exploit this by sending crafted SAML requests to Keycloak's SAML endpoints (e.g., /realms/{realm}/protocol/saml). By sending multiple concurrent requests, an attacker can exhaust the worker thread pool, resulting in a permanent denial of service until the server is manually restarted.

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 Keycloak's administrative services (org.keycloak.services.resources.admin). A highly privileged attacker, authenticated with a 'manage-clients' role, could exploit this vulnerability through several methods, including manipulating client JSON Web Key Sets (JWKS), swapping client authenticator types and resetting secrets, or downloading legitimate signing keys. Successful exploitation allows the attacker to obtain a token with 'realm-admin' role assignments, leading to privilege escalation and potential unauthorized access to sensitive resources.

A flaw was found in Keycloaks token sanitization mechanism, which was originally implemented to prevent role forgery. The sanitizer responsible for removing unauthorized resource access claims from tokens only performs a type check for java.util.Map. When a protocol mapper is configured with jsonType=JSON, the resulting value is a Jackson ObjectNode, which bypasses this specific type check. An attacker with client registration privileges or a valid Initial Access Token can exploit this by registering a client with a protocol mapper targeting the resource access claim. By setting the mapper to use the JSON type, the attacker can inject arbitrary client roles into the issued tokens. Successful exploitation allows an attacker to forge administrative roles, which are then accepted by resource servers or relying parties that perform authorization based on the resource access claim.

A flaw was found in Keycloak's stateless token validation mechanism within the TokenManager.lookupUserFromStatelessToken function. When a sessionless access token is presented and the user ID in the sub claim is no longer found in the database, the system falls back to resolving the user via the preferredusername claim. Because service-account usernames are deterministic (service-account-clientId), deleting and recreating a client with the same client ID results in a new service account with a different internal ID but the same username. An attacker who possesses a valid, unexpired stateless token from the original client can present it after the client has been recreated. Keycloak will resolve the token to the new service account identity and issue a new token reflecting the new account's roles and permissions. In delegation scenarios involving the mayact claim, this can also result in a delegated token being issued for the new service account identity. Successful exploitation allows an attacker to impersonate the new service account and perform any actions or access any data authorized for that account.

A flaw was found in Keycloak Dynamic Client Registration (DCR) within the org.keycloak.services.clientregistration.policy package. The client registration policy validates allowed mapper types but fails to restrict the claim.name value during the registration process. An attacker possessing a valid Initial Access Token (IAT) can register a new client configured with an oidc-usermodel-attribute-mapper that maps a user-editable profile field, such as firstName, directly to the realmaccess.roles claim. When a user subsequently authenticates through this client, the mapper injects the attacker-controlled field value into the realmaccess.roles claim of the issued token. This allows an attacker to forge or corrupt the realm roles claim in tokens provided to external relying parties. While Keycloak internal authorization and the Admin REST API are unaffected because they evaluate the user role model directly, external applications relying on the realmaccess.roles claim for access control are vulnerable to privilege escalation.

A flaw was found in the Admin REST API of Keycloak, an identity and access management solution. The Admin API fails to verify the intended audience of bearer tokens during authentication. This issue allows an attacker who operates a client within a realm to capture an administrator's access token and reuse it to perform unauthorized administrative actions, potentially leading to full realm compromise.

A flaw was found in the theme resource endpoint of Keycloak, an open-source identity and access management solution. The issue occurs because the server fails to validate theme names before using them as keys for an on-disk gzip cache. An unauthenticated attacker can exploit this by sending many requests with unique, fabricated theme names, leading to persistent disk space exhaustion that survives server restarts and causes service disruptions.

A flaw was found in the keycloak-services component. A copy-paste error in the OIDC Dynamic Client Registration response serialization prevents the backchannellogoutrevokeofflinetokens setting from being included in GET responses. When an authorized user or client performs a standard read-modify-write update (GET followed by PUT), the missing field is interpreted as false, silently disabling the revocation of offline tokens. An attacker with manage-clients or registration access can exploit this to ensure offline tokens survive backchannel logout events, maintaining unauthorized access after a session should have been terminated. Additionally, this bug causes the backchannellogoutsessionrequired status to be incorrectly overwritten.

A flaw was found in the login theme rendering component of Keycloak. The issue occurs because the security filter responsible for cleaning user input can be bypassed, allowing a realm administrator to store malicious scripts in display fields. This could result in unauthorized JavaScript execution in the browsers of users visiting the login page, potentially leading to data exposure or session interference.

A flaw was found in the OIDC implementation of Keycloak, specifically within the Device Authorization Grant flow. This component allows devices with limited input capabilities to obtain security tokens. The issue occurs because the flow fails to check the minimum authentication level required by a client configuration. This allows an attacker who has stolen a user's password to bypass mandatory multi-factor authentication and gain unauthorized access to the Keycloak Admin REST API.

A flaw was found in the X.509 client certificate authenticator of Keycloak. When CRL Distribution Point checking is enabled, the server fails to properly validate the file paths provided in a client certificate. An attacker can provide a specially crafted certificate that causes the server to attempt to read sensitive files from the local system or exhaust memory by loading extremely large files, potentially leading to information disclosure or a system crash.

A flaw was found in the Client-Initiated Backchannel Authentication (CIBA) implementation of Keycloak. The CIBA endpoint fails to properly validate the sub parameter, allowing it to be stored as an additional request parameter. During the token issuance process, this injected value overwrites the legitimate subject identifier. This allows an attacker to authenticate as themselves but receive security tokens belonging to a different victim user, leading to unauthorized account access.

A vulnerability was found in Keycloak where the Standard Token Exchange V2 grant path fails to enforce mTLS holder-of-key token binding. When a confidential client is configured with tls.client.certificate.bound.access.tokens set to true, Keycloak correctly rejects standard token grants if no client certificate is provided. However, an attacker who possesses the client credentials and a valid subject token can use the Standard Token Exchange V2 endpoint to obtain an active Bearer access token without presenting a TLS client certificate. The resulting token lacks the cnf.x5t#S256 claim, effectively bypassing the configured sender-constraint and allowing unauthorized access to protected resources.

A flaw was found in the Admin REST API of Keycloak, an identity and access management solution. The endpoints used to retrieve groups associated with a specific role do not properly check for individual group visibility permissions. This allows a delegated administrator with basic search privileges to view detailed information about all groups assigned to a role, bypassing intended security restrictions that should limit their view to specific groups.

A flaw was found in the Kerberos federation provider of Keycloak, an open-source identity and access management solution. When Kerberos password authentication is used without SPNEGO, the system fails to verify the identity of the Key Distribution Center (KDC) by requesting a server ticket. This allows an attacker on the same network to spoof the KDC and bypass the authentication process, potentially gaining unauthorized access to user accounts.

A flaw was found in the Conditional OTP authenticator of Keycloak, an identity and access management solution. The issue occurs when the system evaluates specific HTTP headers to determine if a one-time password (OTP) should be skipped, but fails to verify if those headers came from a trusted source. This could allow an attacker who already has a user's password to bypass the second-factor authentication by providing a specially crafted header in their request.

A flaw was found in the Fine-Grained Admin Permissions (FGAP v2) feature of Keycloak, an identity and access management solution. The issue occurs when the system checks if a delegated administrator has permission to assign a specific role to a user. Because the check does not look inside composite roles to see what other permissions they contain, an administrator with limited rights can assign a role that secretly includes full administrative control. This allows the attacker to gain complete management access over the entire realm.

A flaw was found in org.keycloak.broker.saml. When a disabled Security Assertion Markup Language (SAML) client is configured as an Identity Provider (IdP)-initiated broker landing target, it can still complete the login process and establish a Single Sign-On (SSO) session. This allows a remote attacker to gain unauthorized access to other enabled clients without re-authentication, effectively bypassing security restrictions.

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.