An analysis of the Keycloak authentication system

Earlier this year, we carried out a source-assisted application and architecture assessment for a client who was using Keycloak to implement single sign-on on their applications. The purpose of the assessment was not to audit Keycloak itself. However, being it at the core of the authentication system, we took a look at it.

Keycloak is described as a solution for “Open Source Identity and Access Management. Add authentication to applications and secure services with minimum effort. No need to deal with storing users or authenticating users. Keycloak provides user federation, strong authentication, user management, fine-grained authorization, and more.”

The relationship between Keycloak and Red Hat is not entirely clear to me, but the former is definitely supported by the latter:

During our analysis we identified some security issues and, therefore, we looked into how to report them to the developers:

Pasted image 20240820165225.png

Let’s see what vulnerabilities we have discovered and reported.

OTP bypass

In the step-up-flow guide, a mechanism is described for defining different levels of security depending on the level of authentication (LOA), allowing for applications to use a first level (only username + password) or a second level (username + password + OTP). An administrator who follows this guide is led to make the “step-up flow” the default flow for the “browser flow” so that it is used for all applications.

The security issue is caused by the fact that the default “account” and “account-console” applications are considered as LOA1, therefore access is possible with only a username and a password, also if all other applications require an OTP (LOA2). This allows an attacker to completely bypass the OTP request with only a username and a password, as follows:

The attacker tries to access one of the applications configured to login with Keycloak in LOA2.
The application redirects to Keycloak for authentication.
The attacker provides the correct username and password. At this point, Keycloak requests the OTP.
The attacker does not provide the OTP and instead goes to https://keycloak_url/realms/myrealm/account (the URL of the “account” default application, which requires username and password). Here the attacker can add a new OTP method without even being asked for a currently configured OTP, even if it’s present.
At this point, the attacker can return to the application and will know both the credentials and the OTP, thus being able to access it.

Essentially, it is possible to completely bypass the second factor of authentication with only a username and a password.

The communication timeline follows:

28/03/2024 – First communication sent with all details and a proposed fix.
10/04/2024 – Request for a follow-up with additional details about the proposed fix.
17/04/2024 – Advisory published.
21/04/2024 – Request of a follow-up.
22/04/2024 – First response: Apologies for the lack of communication on our side. The discussion moved internally to the Keycloak team as this might be a duplicate of a CVE that was already reported and a fix was implemented and released. You can now find it as CVE-2023-3597 (see https://github.com/keycloak/keycloak/security/advisories/GHSA-4f53-xh3v-g8x4).

Further details are available at:

In hindsight, by analyzing the details available at https://bugzilla.redhat.com/show_bug.cgi?id=2221760, it is possible to see how the vulnerability was known to the developers since July 2023 and the fix therefore took 10 months.

Pasted image 20240820170144.png

Multiple security issues in authentication and authorization

Multiple issues have been identified regarding the authentication and authorization of certain endpoints in the Keycloak software.

It has been observed that certain functionalities within Keycloak, specifically the /metrics and /health endpoints, are accessible without proper authentication. Even though those endpoints do not provide sensitive information, it is preferable that they are accessible only to authenticated individuals with the correct privileges.

Additionally, users with low privileges could access administrative functionalities in the 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. The affected endpoints are:

/admin/realms/myrealm/client-registration-policy/providers
/admin/myrealm/console/whoami
/admin/realms/myrealm/testLDAPConnection

In particular, the last functionality (testLDAPConnection), in the event that an AD authentication system has been configured, allows to modify application data, enabling the submission of an LDAP request (and consequently LDAP access credentials) to a malicious endpoint that can steal the credentials.

An attacker with access to a non-administrative user account can invoke the “testLDAPConnection functionality by modifying the connectionUrl parameter with an arbitrary value, and the LDAP credentials will be sent to the attacker-controller server. To successfully execute this attack, it’s also necessary to know the componentId related to the domain authentication, which is retrievable in the cookies KEYCLOAK_SESSION, KEYCLOAK_SESSION_LEGACY, and in the responses returned by the /admin/myrealm/console/whoami endpoint.

The communication timeline follows:

04/04/2024 – First communication sent with all details.
09/04/2024 – Response with request of clarifications.
09/04/2024 – More details sent.
09/04/2024 – Second reply.
09/04/2024 – Proposed fix for the first issue.
10/04/2024 – Multiple emails about the first issue.
02/05/2024 – Request for information about the second issue (which is more severe).
09/05/2024 – Response with assigned CVE-2024-3656 and request not to release any details: For the moment there is no estimated keycloak version to include the fix
27/05/2024 – Request for an update and a timeline for the fix.
11/06/2024 – Advisory published without any notification.

Further details are available at:

Multiple race conditions in anti-brute force mechanism

Keycloak implements an anti-brute force mechanism (which is not enabled by default) which should limit the attack attempts by locking out user accounts after a configured number of incorrect login attempts.

Based on our analysis, the software didn’t implement mechanisms to prevent concurrent access to security-critical resources, such as the number of failed authentication attempts. Therefore, it’s possible to send multiple requests that are processed simultaneously by different threads, allowing the attacker to perform many more login attempts than allowed, and consequently partially bypassing the anti-brute-force mechanism. Furthermore, when the account is locked out, active sessions are not invalidated.

The issue has been verified both on the username and password-based login and on the OTP request. No checks have been performed on the “Quick Login Check Milliseconds” functionality, but we expect it to be affected by the same issue. The configuration used for testing was set to lockout accounts after 3 incorrect login attempts.

The communication timeline follows:

18/04/2024 – First communication with details.
18/04/2024 – Response: we can’t see the details.
18/04/2024 – Send details again as an attachment.
02/05/2024 – Request for a follow-up.
09/05/2024 – Response: CVE-2024-4629 assigned, fix in backlog.
24/05/2024 – Request for a roadmap of the fix.
22/08/2024 – Request for a follow-up.
26/08/2024 – Response: Already fixed and published as a public issue.
03/09/2024 – CVE-2024-4629 is published.

Further details on the technique used are available at:

Some final considerations

Authentication is one of the fundamental mechanisms to ensure the security of applications and Keycloak is considered to be one of the standard open source software on which many organizations rely for their authentication needs.

I am a strong proponent of open source. However, I believe that those who develop important projects should carefully consider the impact that their work can have. I think that for a centralized authentication system, a bypass of the two-factor authentication should be solved or at least mitigated in a timely manner: 10 months is a lot of time to fix a core feature of a security product.

Furthermore, communication with security researchers and, crucially, product users should be as clear and explicit as possible. Keycloak’s advisories are very generic and do not allow users to understand what the actual impacts of the vulnerabilities are. Attackers can easily look at the code, understand it, and exploit any vulnerability, but the poor system administrator who needs to figure out if it’s important to quickly update certainly will not do that…

Advisories with full details are downloadable at: