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.
Important: Red Hat build of Keycloak 26.0.11 Images Update
A bug exists in Keycloak 7.x where the user federation LDAP bind type is "none" (LDAP anonymous bind), any password, invalid or valid will be accepted
Mitigation: If the LDAP service supports "simple" use that method instead
An open redirection vulnerability (open redirect) exists in keycloak auth endpoint. URL can be mentioned as the value of redirecturi query parameter and it successfully redirects to it.
References:
https://github.com/syedsohaibkarim/OpenRedirect-Keycloak18.0.0
Important: Red Hat build of Keycloak 22.0.7 images enhancement and security update
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 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 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.
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.
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.
Moderate: Red Hat build of Keycloak 26.0.10 Update
Moderate: Red Hat build of Keycloak 26.0.10 Images Update
A flaw was found in Keycloak 3.4.3.Final, 4.0.0.Beta2, 4.3.0.Final. When using "responsemode=formpost" it is possible to inject arbitrary Javascript-Code via the "state"-parameter in the authentication URL. This allows an XSS-Attack upon succesfully login.
Anyone can register a new device when there is no device registered for passwordless login for any user.
https://issues.redhat.com/browse/KEYCLOAK-18500
In some scenarios we mentioned that a user still has access to a resource after changing the role mappings in Keycloak and after expiration of the previous access token.
Upstream Issue:
https://issues.jboss.org/browse/KEYCLOAK-11145
A vulnerability was found in keycloak, where on using lower case HTTP headers (via cURL) we can bypass our Gatekeeper. Lower case headers are also accepted by some webservers (e.g. Jetty). This means there is no protection when we put a Gatekeeper in front of a Jetty server and use lowercase headers.
References: https://issues.jboss.org/browse/KEYCLOAK-14090
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.
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.
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.
Depending on the webserver configuration, a malicious user can supply an expired certificate and it would be accepted by Keycloak direct-grant authenticator. This is because Keycloak does not trigger the appropriate timestamp validation.
X509 Direct Grant: https://github.com/keycloak/keycloak/blob/4f330f4a57cbfcf6202b60546518261c66e59a35/services/src/main/java/org/keycloak/authentication/authenticators/x509/ValidateX509CertificateUsername.java#L74-L76
It would seem like PR https://github.com/keycloak/keycloak/pull/6330 missed a spot in adding the validateTimestamps call.
https://issues.redhat.com/browse/KEYCLOAK-16450
Keycloak does not properly sanitize inputs in certain UI fields in client registration. A malicious authenticated user with administrative privileges could use this flaw to conduct cross-site scripting attacks and possibly gain access to user-sensitive information.
The logout endpoint /oauth/logout?redirect=url can be abused to redirect logged in users to arbitrary web pages. This vulnerability could be used in phishing attacks.
Upstream Issue:
https://issues.jboss.org/browse/KEYCLOAK-11318
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.
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: 3/4/2024, Latest version: 23.0.7
End of life: 3/4/2024, Latest version: 23.0.7
End of life: 5/6/2021, Latest version: 12.0.4
End of life: 5/6/2021, Latest version: 12.0.4
End of life: 6/10/2024, Latest version: 24.0.5
End of life: 6/10/2024, Latest version: 24.0.5