A vulnerability has been identified in Keycloak that could lead to unauthorized information disclosure. While it requires an already authenticated user, the /admin/serverinfo endpoint can inadvertently provide sensitive environment information.

A flaw was found in Keycloak. When the configuration uses JWT tokens for authentication, the tokens are cached until expiration. If a client uses JWT tokens with an excessively long expiration time, for example, 24 or 48 hours, the cache can grow indefinitely, leading to an OutOfMemoryError. This issue could result in a denial of service condition, preventing legitimate users from accessing the system.

A flaw was found in Keycloak. By setting a verification policy to 'ALL', the trust store certificate verification is skipped, which is unintended.

A denial of service vulnerability was found in Keycloak that could allow an administrative user with the right to change realm settings to disrupt the service. This action is done by modifying any of the security headers and inserting newlines, which causes the Keycloak server to write to a request that has already been terminated, leading to the failure of said request.

A vulnerability was found in Keycloak. Admin users may have to access sensitive server environment variables and system properties through user-configurable URLs. When configuring backchannel logout URLs or admin URLs, admin users can include placeholders like ${env.VARNAME} or ${PROPNAME}. The server replaces these placeholders with the actual values of environment variables or system properties during URL processing.

A vulnerability was found in Keycloak. This issue may allow a privileged attacker to use a malicious payload as the permission while creating items (Resource and Permissions) from the admin console, leading to a stored cross-site scripting (XSS) attack.

A flaw was found in Keycloak that occurs from an error in the re-authentication mechanism within org.keycloak.authentication. This flaw allows hijacking an active Keycloak session by triggering a new authentication process with the query parameter "prompt=login," prompting the user to re-enter their credentials. If the user cancels this re-authentication by selecting "Restart login," an account takeover may occur, as the new session, with a different SUB, will possess the same SID as the previous session.

An open redirect vulnerability was found in Keycloak. A specially crafted URL can be constructed where the referrer and referrer_uri parameters are made to trick a user to visit a malicious webpage. A trusted URL can trick users and automation into believing that the URL is safe, when, in fact, it redirects to a malicious server. This issue can result in a victim inadvertently trusting the destination of the redirect, potentially leading to a successful phishing attack or other types of attacks. Once a crafted URL is made, it can be sent to a Keycloak admin via email for example. This will trigger this vulnerability when the user visits the page and clicks the link. A malicious actor can use this to target users they know are Keycloak admins for further attacks. It may also be possible to bypass other domain-related security checks, such as supplying this as a OAuth redirect uri. The malicious actor can further obfuscate the redirect_uri using URL encoding, to hide the text of the actual malicious website domain.

A flaw was found in Keycloak, where it does not correctly validate its client step-up authentication in org.keycloak.authentication. This flaw allows a remote user authenticated with a password to register a false second authentication factor along with an existing one and bypass authentication.

A vulnerability was found in the Keycloak Server. The Keycloak Server is vulnerable to a denial of service (DoS) attack due to improper handling of proxy headers. When Keycloak is configured to accept incoming proxy headers, it may accept non-IP values, such as obfuscated identifiers, without proper validation. This issue can lead to costly DNS resolution operations, which an attacker could exploit to tie up IO threads and potentially cause a denial of service. The attacker must have access to send requests to a Keycloak instance that is configured to accept proxy headers, specifically when reverse proxies do not overwrite incoming headers, and Keycloak is configured to trust these headers.