CVE-2024-4629 Overview
A flaw in Red Hat Keycloak allows attackers to bypass brute force protection by exploiting a timing weakness in the login attempt handler. Attackers can submit multiple authentication requests simultaneously, allowing failed attempts to exceed the configured lockout threshold before the account is locked. This race-like condition undermines a core account-security control designed to slow credential guessing.
The vulnerability affects Red Hat Keycloak, Red Hat Build of Keycloak, and Red Hat Single Sign-On deployments across Red Hat Enterprise Linux and OpenShift Container Platform variants. Red Hat classifies the flaw under [CWE-837] (Improper Enforcement of a Single, Unique Action).
Critical Impact
Attackers can perform password guessing well beyond configured failure limits, increasing the likelihood of account compromise on Keycloak-protected identity systems.
Affected Products
- Red Hat Keycloak and Red Hat Build of Keycloak
- Red Hat Single Sign-On on Red Hat Enterprise Linux 7, 8, and 9
- Red Hat OpenShift Container Platform (including editions for LinuxONE, Power, and IBM Z)
Discovery Timeline
- 2024-09-03 - CVE-2024-4629 published to the National Vulnerability Database
- 2024-09-03 - Red Hat releases security advisories RHSA-2024:6493 through RHSA-2024:6501
- 2026-06-17 - Last updated in NVD database
Technical Details for CVE-2024-4629
Vulnerability Analysis
Keycloak's brute force protection module tracks failed login attempts per user and locks the account after a configurable threshold. The flaw lies in how the counter is evaluated and updated. When multiple authentication requests target the same account in parallel, each request reads the failure counter before any of them has finished incrementing it. Every concurrent request therefore sees a value below the lockout threshold and is allowed to proceed with password verification.
This behavior maps to [CWE-837] (Improper Enforcement of a Single, Unique Action). The protection acts as a soft limit rather than an atomic gate. An attacker who submits a burst of N parallel login attempts can effectively try N additional passwords for each check window before the lockout state finally propagates.
The attack requires only network access to the Keycloak authentication endpoint and no prior privileges. Successful exploitation increases the practical entropy an attacker can search, weakening password-only accounts and any account whose second factor is not enforced.
Root Cause
The root cause is the non-atomic check-then-act sequence between reading the failed-attempt counter and updating it. Concurrent requests race against the shared state, and the lockout decision is made against stale data.
Attack Vector
An attacker sends a high volume of concurrent authentication requests for a target username using different candidate passwords. Because each request evaluates the lockout counter independently before the counter is persisted, more guesses are processed than the configured limit permits. The attacker repeats the process across accounts to enumerate valid credentials.
No verified public exploit code is available. Technical background is documented in the HNS Security vulnerability report and the Humanitas analysis of the Keycloak authentication system.
Detection Methods for CVE-2024-4629
Indicators of Compromise
- Bursts of authentication requests targeting a single username within a very short time window from one or a small set of source IPs.
- Keycloak event logs showing multiple LOGIN_ERROR events for the same user with near-identical timestamps.
- Successful LOGIN events immediately preceded by a large volume of failed attempts that did not trigger a USER_DISABLED_BY_PERMANENT_LOCKOUT or temporary lockout event.
- Unusual spikes in requests to the /realms/{realm}/protocol/openid-connect/token or /login-actions/authenticate endpoints.
Detection Strategies
- Correlate Keycloak event logs by userId and time bucket to identify parallel authentication attempts that exceed the configured failureFactor.
- Baseline normal login concurrency per user and alert on statistical outliers.
- Compare the count of LOGIN_ERROR events to lockout events; a large gap suggests the protection was bypassed.
Monitoring Recommendations
- Forward Keycloak admin and login events to a centralized logging or SIEM platform for correlation.
- Enable request-rate metrics on the reverse proxy or ingress fronting Keycloak and alert on concurrent authentications per user.
- Track failed authentication trends per realm and per client and review changes after applying vendor patches.
How to Mitigate CVE-2024-4629
Immediate Actions Required
- Apply the Red Hat updates referenced in advisories RHSA-2024:6493, RHSA-2024:6494, RHSA-2024:6495, RHSA-2024:6497, RHSA-2024:6499, RHSA-2024:6500, and RHSA-2024:6501.
- Enforce multi-factor authentication for all interactive user accounts to limit the value of any single password guess.
- Review recent authentication logs for signs of concurrent-request abuse and reset credentials for any accounts showing suspicious activity.
Patch Information
Red Hat has released fixed packages for Red Hat Build of Keycloak and Red Hat Single Sign-On. Refer to the Red Hat CVE-2024-4629 advisory and the corresponding RHSA-2024:6493 errata for version-specific package information. Upstream Keycloak users should upgrade to a release that incorporates the same fix.
Workarounds
- Place a rate-limiting reverse proxy or web application firewall in front of Keycloak to cap concurrent authentication requests per source IP and per username.
- Reduce the configured failureFactor and increase waitIncrementSeconds in the brute force detection settings to lower the practical guess budget.
- Require MFA on all realms so that a password-only bypass cannot lead directly to account takeover.
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
