A flaw was found in the keycloak-services component of Keycloak, which is used for managing authentication and authorization flows. The issue occurs when a realm administrator configures client policies to enforce specific authentication requirements on confidential clients. Due to improper evaluation of the client state during an update operation, an attacker with client management permissions can bypass these security policies by first creating a public client and then updating it to a confidential client with weaker authentication. This can result in the persistence of clients that do not comply with the intended security hardening of the realm.
A flaw was found in the group search functionality of the Keycloak server's administrative API. When Fine-Grained Admin Permissions (FGAP) v2 is enabled, a delegated administrator can bypass access restrictions to view parent groups they are not authorized to see. By searching for a child group they have permission to view, the system incorrectly returns the full details of the parent group in the response, leading to the disclosure of sensitive group attributes and configuration.
The keycloak guides recommend to not expose /admin path to the outside in case the installation is using a proxy (see https://www.keycloak.org/server/reverseproxy#exposedpathrecommendations ). The problem is that, at least ha-proxy, can be tricked to using relative/non-normalized paths to access the /admin application path relative to /realms (which should be exposed). For example:
curl --path-as-is http://localhost:7080/realms/../admin/master/console/#/master/info <http://localhost:7080/admin/master/console/#/master/info>
The admin path requires authentication but, in the end, the final customer is exposing a path that he thinks is not accessible. Also note that this is more an issue in ha-proxy than keycloak. Keycloak does not even document how to configure ha-proxy or any other proxy, it just recommends to not expose the /admin app. For example mod-proxy correctly manages non-normalized URLs, because it normalizes the path before to be sure it's inside the prefix-path.
Nevertheless we have reached the conclusion that keycloak should return an error by default for non-normalized URLs.
The installation should use a proxy configuration with ha-proxy with the common configuration.
A flaw was found in the keycloak-services component, specifically within the legacy client-initiated account-linking endpoint (/realms/{realm}/broker/{provider}/link). The endpoint validates a CSRF protection hash computed as SHA-256(nonce + userSessionId + clientId + providerAlias). The root cause is that all four inputs to this hash are accessible to a registered OIDC client: nonce is chosen by the attacker.
userSessionId is leaked as the sessionstate parameter in standard OIDC authorization responses (handled by OIDCLoginProtocol.java).
clientId and providerAlias are known to the client.
By obtaining the victim's sessionstate during a normal login flow, a malicious client can compute the required hash and generate a valid account-linking URL. If the client has the manage-account-links role (granted by default via fullScopeAllowed=true), the attacker can silently link their own upstream Identity Provider (IdP) identity to the victim's Keycloak account. Concrete Impact: Account Takeover: Attacker gains full access to the victim's account by logging in via the newly linked IdP.
Unauthorized Identity Linking: Attacker can link multiple malicious identities to a single victim account.
Data Exfiltration: Attacker can access all applications and data the victim is authorized to see.
A flaw was found in Keycloak's Dynamic Client Registration (DCR) security policy management. The "Allowed Protocol Mapper Types" policy, which restricts which types of data mappers a client can use, fails to re-validate the mapper type during a client update if the mapper's configuration remains unchanged. An attacker with client registration privileges can exploit this by first registering an allowed mapper type with a malicious configuration and then swapping it for a restricted, high-privilege mapper type (such as one that hardcodes administrative roles). This allows the attacker to gain full administrative access to the Keycloak realm.
A flaw was found in the keycloak-services component of Keycloak. The vulnerability exists in the OIDC backchannel logout endpoint located at /realms/realm/protocol/openid-connect/logout/backchannel-logout. When an OIDC identity provider is configured with validateSignature set to false, the endpoint fails to enforce cryptographic signature requirements for logout tokens, accepting tokens with the alg=none header. An unauthenticated remote attacker who knows the provider issuer, the broker client ID, and a brokered user's upstream subject or session ID can craft and send a forged, unsigned logout token. Successful exploitation allows the attacker to force-logout targeted brokered users or revoke their offline sessions. This behavior violates the OIDC Back-Channel Logout specification which mandates signatures and prohibits the use of the none algorithm.
A flaw was found in Keycloak. The Keycloak Authorization header parser is overly permissive regarding the formatting of the "Bearer" authentication scheme. It accepts non-standard characters (such as tabs) as separators and tolerates case variations that deviate from RFC 6750 specifications.
Keycloak does not correctly validate its client step-up authentication. A password-authed attacker could use this flaw to register a false second auth factor, alongside the existing one, to a targeted account. The second factor then permits step-up authentication.
Important: Red Hat build of Keycloak 26.0.11 Images Update
Moderate: Red Hat build of Keycloak 26.0.10 Update
Moderate: Red Hat build of Keycloak 26.0.10 Images Update
End of life: 4/11/2025, Latest version: 26.1.5
End of life: 1/15/2025, Latest version: 26.0.8
End of life: 1/15/2025, Latest version: 26.0.8
A flaw was discovered in keycloak-httpd-client-install version 0.6-2. The --log-file option in keycloakcli.py insecurely passes the script name for the log file creation.
A CSRF flaw was found in Keycloak. This issue occurs due to the lack of a unique token sent during the authentication POST request, /login-actions/authenticate. An attacker could craft a malicious login page and trick a legitimate user of an application into authenticating with an attacker controlled account instead of their own.
End of life: 10/4/2024, Latest version: 25.0.6
End of life: 10/4/2024, Latest version: 25.0.6
A flaw was found in keycloak 22.0.5. Errors in browser client during setup/auth with "Security Key login" (WebAuthn) are written into the form, send to Keycloak and logged without escaping allowing log injection.
End of life: 6/10/2024, Latest version: 24.0.5
End of life: 6/10/2024, Latest version: 24.0.5
Keycloak's device authorization grant does not correctly validate the device code and client ID. An attacker client could abuse the missing validation to spoof a client consent request and trick an authed admin into granting consent to a malicious OAuth client, or possible unauthorized access to an existing OAuth client.
Important: Red Hat build of Keycloak 22.0.7 images enhancement and security update
End of life: 3/4/2024, Latest version: 23.0.7
End of life: 3/4/2024, Latest version: 23.0.7
End of life: 11/23/2023, Latest version: 22.0.5
End of life: 11/23/2023, Latest version: 22.0.5
If a JBoss Keycloak application has configured as a permitted web origin in the Keycloak administrative console, crafted requests to the login-status-iframe.html endpoint can inject arbitrary Javascript into the generated HTML code via the "origin" query parameter, leading to a cross-site scripting vulnerability.
End of life: 7/11/2023, Latest version: 21.1.2
End of life: 7/11/2023, Latest version: 21.1.2