Full Report
Keycloak is an open source IAM solution with user management and SSO. They decided to tackle some race conditions within the system relating to user management. From reading the James Kettle post on race conditions, the authors were curious about race conditions in the registration process of users. While reading the source code, they noticed that the requirement for the email verification was added in a later step after creating the user. So, their thought was making a login request AFTER the user was created but BEFORE the restriction was added. While digging into this, they noticed that the ORM used in the program used database transactions. This means that the database writes are grouped together, making the race condition impossible to hit. Regardless, it was interesting seeing their methodology for finding these multi-step types of bugs. They found a classic limit overrun race condition within the rate limiting for API key creation but no multi-step issues. I felt like the post overhyped some of the issues tbh. But, I enjoyed the race condition discussions on it.
Analysis Summary
# Vulnerability: Keycloak API Rate Limiting Race Condition
## CVE Details
- **CVE ID:** CVE-2024-1722
- **CVSS Score:** 5.3 (Medium)
- **CWE:** CWE-362 (Race Condition), CWE-770 (Allocation of Resources Without Limits or Throttling)
## Affected Systems
- **Products:** Keycloak (Open-source Identity and Access Management)
- **Versions:** Versions prior to 24.0.0
- **Configurations:** Systems utilizing API key creation and default rate-limiting configurations.
## Vulnerability Description
The vulnerability is a classic "limit overrun" race condition located within Keycloak's API key creation process. While Keycloak employs an ORM with database transactions that effectively prevents race conditions in multi-step user registration (by grouping writes together), the rate-limiting mechanism for API key generation failed to account for concurrent requests.
An attacker can send multiple simultaneous requests to create API keys. Because the check for the current count of keys and the incrementing of that count do not happen atomically across concurrent threads, the system may allow the creation of more keys than the defined policy intends.
## Exploitation
- **Status:** PoC available (discussed in research blog and presented at security conferences).
- **Complexity:** Medium (Requires synchronized network requests).
- **Attack Vector:** Network.
## Impact
- **Confidentiality:** None.
- **Integrity:** None.
- **Availability:** Low (Resource exhaustion or bypass of administrative limits/quotas).
## Remediation
### Patches
- Keycloak has addressed this issue in **version 24.0.0**. It is recommended to upgrade to the latest stable release.
### Workarounds
- Implement rate limiting at the Infrastructure/Reverse Proxy level (e.g., Nginx, HAProxy, or a Web Application Firewall) to limit the frequency of requests to sensitive API endpoints.
- Monitor for high-frequency bursts of activity directed at credential-generation endpoints.
## Detection
- **Indicators of Compromise:** Multiple API keys or credentials created for a single user/client within the same millisecond timestamp.
- **Detection methods and tools:** Audit log analysis focused on `CREATE` events for API keys or service accounts originating from the same source in near-simultaneous bursts.
## References
- Vendor Advisory: [https://nvd.nist.gov/vuln/detail/CVE-2024-1722](https://nvd.nist.gov/vuln/detail/CVE-2024-1722)
- Technical Analysis: [https://www.cyberark.com/resources/threat-research-blog/you-cant-always-win-racing-the-keycloak](https://www.cyberark.com/resources/threat-research-blog/you-cant-always-win-racing-the-keycloak)
- Research Presentation: [https://github.com/m2a2/Research/blob/main/presentations/2025/BlueHatIL_2025_Lets_Be_Authentik_v39_Final_FullPage.pdf](https://github.com/m2a2/Research/blob/main/presentations/2025/BlueHatIL_2025_Lets_Be_Authentik_v39_Final_FullPage.pdf)