A security flaw in the IdentityBrokerService.performLogin endpoint of Keycloak allows authentication to proceed using an Identity Provider (IdP) even after it has been disabled by an administrator. An attacker who knows the IdP alias can reuse a previously generated login request to bypass the administrative restriction. This undermines access control enforcement and may allow unauthorized authentication through a disabled external provider.

A flaw was found in Keycloak's URL validation logic during redirect operations. By crafting a malicious request, an attacker could bypass validation to redirect users to unauthorized URLs, potentially leading to the exposure of sensitive information within the domain or facilitating further attacks. This vulnerability specifically affects Keycloak clients configured with a wildcard () in the "Valid Redirect URIs" field and requires user interaction to be successfully exploited.

The issue stems from a discrepancy in how Keycloak and the underlying Java URI implementation handle the user-info component of a URL. If a malicious redirect URL is constructed using multiple @ characters in the user-info section, Java's URI parser fails to extract the user-info, leaving only the raw authority field. Consequently, Keycloak's validation check fails to detect the malformed user-info, falls back to a wildcard comparison, and incorrectly permits the malicious redirect.

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 Keycloak. An administrator with manage-clients permission can exploit a misconfiguration where this permission is equivalent to manage-permissions. This allows the administrator to escalate privileges and gain control over roles, users, or other administrative functions within the realm. This privilege escalation can occur when admin permissions are enabled at the realm level.

Vulnerability in org.keycloak/keycloak-services

A business logic vulnerability exists in the Token Exchange implementation within the keycloak-services component. When a privileged client invokes the token exchange flow, Keycloak correctly validates the client but fails to validate whether the target “requestedsubject” user is enabled. This omission allows issuance of access and refresh tokens for users whose accounts have been explicitly disabled. An internal client with the impersonation permission can therefore resurrect “zombie accounts,” obtaining tokens for former employees or banned users despite account deactivation. This flaw enables unauthorized use of previously revoked privileges and relies solely on the presence of an internal high-privileged client, requiring no user interaction or direct authentication by the disabled user.

When Keycloak is started with --features-disabled=account,account-api, the Account REST API is only partially disabled. Five endpoints under the versioned path /account/v1alpha1 remain fully functional — including both read and write operations — because they lack the checkAccountApiEnabled() gate that correctly blocks four other endpoints in the same REST service class. The user needs to have permissions to use the API.

A flaw was found in Keycloak. An administrator with manage-users permission can bypass the "Only administrators can view" setting for unmanaged attributes, allowing them to modify these attributes. This improper access control can lead to unauthorized changes to user profiles, even when the system is configured to restrict such modifications.

A flaw was found in Keycloak. An authenticated user can bypass configured WebAuthn policies during credential registration by manipulating client-side JavaScript. This occurs because the server-side processAction() fails to validate that the newly created credential's parameters, such as public key algorithms, match the realm's configured WebAuthn policies. This could lead to the creation of credentials that do not adhere to administrative security requirements, potentially weakening the overall security posture of the system by allowing non-compliant authentication methods.

Summary

When the Unmanaged Attributes is set to Only administrators can view, the administrator that has manage-users permission can anyway edit the unmanaged attributes. For example using curl or kcsdm.sh:

./kcadm.sh update users/b0df9d35-3319-4e87-81ea-9a906372fa1f -r sample -s "attributes.lala=lala"

Requirements to exploit

The realm should be configured unmanaged attributes to Only administrators can view and the admin should have permissions to edit users.

Component affected:

org.keycloak:keycloak-services Version affected: <26.4.0

Patch available: no

CVSS: (Based on

https://nvd.nist.gov/vuln-metrics/cvss/v3-calculator

) Initially i would say medium:

Vector:

CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:H/A:N Base Score: 4.9 (Medium)

Embargo: no, if you consider it's moderate too.

Acknowledgement

Steps to reproduce

Create a new realm and configure in realm settings -> Genaral tab -> unmanaged attributes to Only administrators can view.

Use kcadm (for example to edit the user with an admin that has manage-users permission using the presented command.

The user is updated and toy can see the new attribute in the console.

The operation should an error or attributes skipped.

A flaw was identified in the Docker v2 authentication endpoint of Keycloak, where tokens continue to be issued even after a Docker registry client has been administratively disabled. This means that turning the client “Enabled” setting to OFF does not fully prevent access. As a result, previously valid credentials can still be used to obtain authentication tokens. This weakens administrative controls and could allow unintended access to container registry resources.

A flaw was found in Keycloak's SAML brokering functionality. When Keycloak is configured as a client in a Security Assertion Markup Language (SAML) setup, it fails to validate the NotOnOrAfter timestamp within the SubjectConfirmationData. This allows an attacker to delay the expiration of SAML responses, potentially extending the time a response is considered valid and leading to unexpected session durations or resource consumption.

A flaw was found in Keycloak’s WebAuthn registration component. This vulnerability allows an attacker to bypass the configured attestation policy and register untrusted or forged authenticators via submission of an attestation object with fmt: "none", even when the realm is configured to require direct attestation. This can lead to weakened authentication integrity and unauthorized authenticator registration.