A vulnerability was found in the Keycloak-services package. If untrusted data is passed to the SearchQueryUtils method, it could lead to a denial of service (DoS) scenario by exhausting system resources due to a Regex complexity.
Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-wq8x-cg39-8mrr. This link is maintained to preserve external references. Original Description A vulnerability was found in the Keycloak-services package. If untrusted data is passed to the SearchQueryUtils method, it could lead to a denial of service (DoS) scenario by exhausting system resources due to a Regex complexity.
A misconfiguration flaw was found in Keycloak. This issue can allow an attacker to redirect users to an arbitrary URL if a 'Valid Redirect URI' is set to http://localhost/ or http://127.0.0.1/, enabling sensitive information such as authorization codes to be exposed to the attacker, potentially leading to session hijacking.
A session fixation issue was discovered in the SAML adapters provided by Keycloak. The session ID and JSESSIONID cookie are not changed at login time, even when the turnOffChangeSessionIdOnLogin option is configured. This flaw allows an attacker who hijacks the current session before authentication to trigger session fixation.
A misconfiguration flaw was found in Keycloak. This issue can allow an attacker to redirect users to an arbitrary URL if a 'Valid Redirect URI' is set to http://localhost or http://127.0.0.1, enabling sensitive information such as authorization codes to be exposed to the attacker, potentially leading to session hijacking.
If an attacker launches many login attempts in parallel then the attacker can have more guesses at a password than the brute force protection configuration permits. This is due to the brute force check occurring before the brute force protector has locked the user. Acknowledgements: Special thanks to Maurizio Agazzini for reporting this issue and helping us improve our project.
A session fixation issue was discovered in the SAML adapters provided by Keycloak. The session ID and JSESSIONID cookie are not changed at login time, even when the turnOffChangeSessionIdOnLogin option is configured. This flaw allows an attacker who hijacks the current session before authentication to trigger session fixation.
Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-gc7q-jgjv-vjr2. This link is maintained to preserve external references. Original Description A vulnerability was found in Keycloak. This flaw allows attackers to bypass brute force protection by exploiting the timing of login attempts. By initiating multiple login requests simultaneously, attackers can exceed the configured limits for failed attempts before the system locks them out. This timing loophole …
Keycloak allows the use of email as a username and doesn't check that an account with this email already exists. That could lead to the unability to reset/login with email for the user. This is caused by usernames being evaluated before emails.
In any realm set with "User (Self) registration" a user that is registered with a username in email format can be "locked out" (denied from logging in) using his username.
Users with low privileges (just plain users in the realm) are able to utilize administrative functionalities within Keycloak admin interface. This issue presents a significant security risk as it allows unauthorized users to perform actions reserved for administrators, potentially leading to data breaches or system compromise. Acknowledgements: Special thanks to Maurizio Agazzini for reporting this issue and helping us improve our project.
A flaw was found in Keycloak in the OAuth 2.0 Pushed Authorization Requests (PAR). Client provided parameters were found to be included in plain text in the KC_RESTART cookie returned by the authorization server's HTTP response to a request_uri authorization request. This could lead to an information disclosure vulnerability.
A flaw was found in Keycloak in the OAuth 2.0 Pushed Authorization Requests (PAR). Client provided parameters were found to be included in plain text in the KC_RESTART cookie returned by the authorization server's HTTP response to a request_uri authorization request. This could lead to an information disclosure vulnerability.
Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-69fp-7c8p-crjr. This link is maintained to preserve external references. Original Description A flaw was found in Keycloak in OAuth 2.0 Pushed Authorization Requests (PAR). Client-provided parameters were found to be included in plain text in the KC_RESTART cookie returned by the authorization server's HTTP response to a request_uri authorization request, possibly leading to an information disclosure vulnerability.
A potential security flaw in the "checkLoginIframe" which allows unvalidated cross-origin messages, enabling potential DDoS attacks. By exploiting this vulnerability, attackers could coordinate to send millions of requests in seconds using simple code, significantly impacting the application's availability without proper origin validation for incoming messages.
A flaw was found in Keycloak. An active keycloak session can be hijacked by initiating a new authentication (having the query parameter prompt=login) and forcing the user to enter his credentials once again. If the user cancels this re-authentication by clicking Restart login, the account takeover could take place as the new session, with a different SUB, will have the same SID as the previous session.
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. Acknowledgements: Special thanks toTheresa Henze for reporting this issue and helping us improve our security.
Keycloak was found to not properly enforce token types when validating signatures locally. An authenticated attacker could use this flaw to exchange a logout token for an access token and possibly gain access to data outside of enforced permissions.
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.
An issue was found in the redirect_uri validation logic that allows for a bypass of otherwise explicitly allowed hosts.
A flaw was found in Keycloak, where it does not properly validate URLs included in a redirect. An attacker can use this flaw to construct a malicious request to bypass validation and access other URLs and potentially sensitive information within the domain or possibly conduct further attacks. This flaw affects any client that utilizes a wildcard in the Valid Redirect URIs field.
Keycloak allows arbitrary URLs as SAML Assertion Consumer Service POST Binding URL (ACS), including JavaScript URIs (javascript:). Allowing JavaScript URIs in combination with HTML forms leads to JavaScript evaluation in the context of the embedding origin on form submission.
Due to a permissive regular expression hardcoded for filtering allowed hosts to register a dynamic client, a malicious user with enough information about the environment could benefit and jeopardize an environment with this specific Dynamic Client Registration with TrustedDomain configuration previously unauthorized.
An issue was found in the redirect_uri validation logic that allows for a bypass of otherwise explicitly allowed hosts. The problem arises in the verifyRedirectUri method, which attempts to enforce rules on user-controllable input, but essentially causes a desynchronization in how Keycloak and browsers interpret URLs. Keycloak, for example, receives "www%2ekeycloak%2eorg%2fapp%2f:y@example.com" and thinks the authority to be keycloak.org when it is actually example.com. This happens because the validation logic is …